SOX requires controls to achieve the following;
Fraud Reduction (this may or may not be using IT)
Data integrity on financial systems
Data Accuracy on financial systems
Data Completeness for finance systems
Security is an issue to SOX as regards the above. It does not have any
requirements regarding disclosure (this is other laws).
So what makes an organisation in the US want to stop disclosure?
. Alien Tort Claims Act (ATCA) 1789 (United States of America)
. Foreign Intelligence Surveillance Act (FISA) (as codified in 50 U.S.C.
§§1801-1811, 1821-29, 1841-46, and 1861-62) 1978 (United States of America)
. Private Securities Litigation Reform Act 1995 (United States of America)
. Restatement and Uniform Trade Secrets Act 1985 (United States of
America)
. Telecommunications Act 1996 (United States of America)
. Trademark Act 1946 (United States of America)
. Restatement (Second) of Contracts, S 56 & The United States Framework
for Global Electronic Commerce (United States of America)
....
PCI-DSS is any system involved win the processing of Card data. It was stated "
PCI to systems that handle credit card data, but ultimately could rely on an
unsecured network for resources".
This assertion is false. All systems involved in the provision of services are
in scope for PCI. This is ALL time servers, DNS, etc. It is not just the
database with the card information, but the client host, the DNS used by the
servers and the clients on the Internet, the web server that is used to enter
data etc. The current last of understanding about PCI-DSS is easily remedied,
read the documents - all of them.
" I will conclude by stating that I have yet to see any two standards (SOX,
PCI, HIPPA, etc...) where there is a direct 1-1 mapping of policies/procedures.
There has always something that was applicable *only* to those machines that
were defined as being in the scope of the standard."
Correct. The issue that is overlooked most often is economics. We live in a
limited world.
"However, one can take a policy/standard/procedure for SOX/HIPPA/etc...and
ensure that it effectively covers the PCI requirements as well (take having a
security policy). Thus, hopefully having 1 policy/standard/procedure to
encompass everything."
Correct again for the most part. The issue is that you can not make a universal
one. You can create an ISMS to make a ISO 27001/2 compliant PCI system. What
you can not do is write a ISMS that will apply universally to all PCI systems.
Also, the ISMS for the PCI systems will not apply to other systems. The
controls required for PCI are far in excess of what most organisations will put
up with for most internal file servers.
SOX is a different beast. There is some overlap, but IT is a small component of
SOX. We like to think we are the be all and end all, but the fact is most
controls are about accounting processes, not IT ones. SOX is not a securi9ty
standard, it is a set of legislation designed to control financial fraud.
The economic effects come into play as there is always going to be a limited
budget for security. The secret is to maximise it. This means designing systems
based on risk. What are the threats, what is the potential loss etc. There are
some provisions that will come first. SOX is going to be one of these in most
cases for good reason, if you do not do it right, the management goes to gaol.
Management cares about this, they do not wish to go to gaol, this is the
principle of informed self interest - one of the key components of economic
theory.
Next there is a risk that a violation of a system will cost the company a large
amount of money. HIPAA, PCI-DSS and vicarious liability through contract and
tort all fall into this area. These make it likely that the company will suffer
a loss, this means that the management bonus and salary will be impacted. This
may be a significant impact. This means that this is a concern.
Other areas of security may have lower financial (and criminal) effects with
not being implemented. The consequence is that management (senior) will have
less of a concern about these. When you go to management of a major bank for
instance and state that the company may lose $800,000 k this year alone if they
do not put a system into play, this will be low on their radar.
Why? At the moment some of the larger banks are considering write-offs in the
100s of millions for interest rate variations and foreclosures. In this,
security of peripheral systems (those that do not lose a bonus or make them go
to gaol) are secondary and a SEP (somebody Else's Problem).
We all like to think that what we do is important, but for this to be so, we
need to align it to the needs of the organisation.
I helped setup the first licensed online casino in the 90's. They had a
comparatively large budget, but they still had limits and there was far more I
would have liked to do. The case in point though is that they are a business
first and business is about risk. No risk, no profit.
Regards,
Craig Wright (GSE-Compliance)
Craig Wright
Manager of Information Systems
Direct : +61 2 9286 5497
Craig.Wright@bdo.com.au
+61 417 683 914
BDO Kendalls (NSW)
Level 19, 2 Market Street Sydney NSW 2000
GPO BOX 2551 Sydney NSW 2001
Fax +61 2 9993 9497
http://www.bdo.com.au/
Liability limited by a scheme approved under Professional Standards Legislation
in respect of matters arising within those States and Territories of Australia
where such legislation exists.
The information in this email and any attachments is confidential. If you are
not the named addressee you must not read, print, copy, distribute, or use in
any way this transmission or any information it contains. If you have received
this message in error, please notify the sender by return email, destroy all
copies and delete it from your system.
Any views expressed in this message are those of the individual sender and not
necessarily endorsed by BDO Kendalls. You may not rely on this message as
advice unless subsequently confirmed by fax or letter signed by a Partner or
Director of BDO Kendalls. It is your responsibility to scan this communication
and any files attached for computer viruses and other defects. BDO Kendalls
does not accept liability for any loss or damage however caused which may
result from this communication or any files attached. A full version of the BDO
Kendalls disclaimer, and our Privacy statement, can be found on the BDO
Kendalls website at http://www.bdo.com.au/ or by emailing
mailto:administrator@bdo.com.au.
BDO Kendalls is a national association of separate partnerships and entities.
-----Original Message-----
From: Sheldon Malm [mailto:smalm@ncircle.com]
Sent: Thursday, 28 February 2008 8:49 AM
To: exzactly
Cc: security-basics@securityfocus.com; W. Lee Schexnaider; Craig Wright
Subject: RE: ISO 27001 mapping to PCI
Excellent point. PCI SSC has been very clear that their primary goal at this
phase is global adoption over security. SOX, on the other hand, is a
"financial reporting responsibility" act that has been extrapolated from its
original scope - in many cases by technology vendors to add a sense of
necessity to their particular solutions.
Sheldon Malm
Director
Security Research & Development
nCircle Network Security
Check out the VERT daily post
http://blog.ncircle.com/vert
-----Original Message-----
From: exzactly [mailto:exzactly@hotmail.com]
Sent: Wednesday, February 27, 2008 4:45 PM
To: W. Lee Schexnaider; Craig Wright
Cc: Sheldon Malm; security-basics@securityfocus.com
Subject: Re: ISO 27001 mapping to PCI
I guess what makes zero sense to me, is how any of these regulations are an
effective means to security. As a for instance SOX is only scoped to financial
systems, PCI to systems that handle credit card data, but ultimately could rely
on an unsecured network for resources. I believe that these regulations are
sometimes quite at odds with what Security Management is trying to achieve. I
have consultants for SOX, and on several occasions have held up security
initiatives that would make my network more secure, because the overhead of SOX
would be too much to expect on the team having to support them. On one hand I
look at them and say "Hey that's great, now people will at least talk about
security in an organization" on the other hand I say "Now all their focused on
is SOX compliance and real security initiatives get a back seat."
----- Original Message -----
From: "W. Lee Schexnaider" <l.schex@gmail.com>
To: "Craig Wright" <Craig.Wright@bdo.com.au>
Cc: "Sheldon Malm" <smalm@ncircle.com>; <security-basics@securityfocus.com>
Sent: Wednesday, February 27, 2008 7:43 AM
Subject: Re: ISO 27001 mapping to PCI
Hello,
Ok, Craig. I guess we'll just have to agree to disagree.
Lee
On Tue, Feb 26, 2008 at 10:51 PM, Craig Wright <Craig.Wright@bdo.com.au>
wrote:
No, the reason companies fail is that they seek to minimise what they
need and do not plan. They try to do too much at once and do not set small
manageable scopes.
While it is true that most of the quoted requirements are not in
opposition in some cases - these instances are rare and finding them takes
more effort then implementing controls correctly. What needs to occur is
that a scoping exercise needs to be completed,
As an external auditor, I have to state that your approach will fail. An
audit is conducted against a set of standards, one set of standards. You
do not run a PCI-DSS audit at the same time as a SOX audit. In fact you
can not validly do so.
The secret comes to setting the scope in the first place. There is no
need to have a ISO 27001 to PCI mapping. They are separate and all cases
that try to map these directly fail. As I have posted on a prior occasion,
http://www.unifiedcompliance.com/ is not accurate. Use this and you will
have failed both before you start.
The secret is easy. First for PCI-DSS - this includes all systems that
have card holder information. The scope is these systems and no more. Next
of there is a reason that you need to also have ISO27001/2 compliance, the
scope would be set to all other systems not covered under PCI.
Done - now you get to concentrate on each set of requirements. One at a
time. This is how you complete them.
As for the comment, "preparation for audits is very different than the
execution of audits", really? Gee thanks. I am glad that you let me know.
In either case it comes to scoping.
My current tally on audits is 1761 audits for 363 organisations over 22
years (I am a statistician as well as auditor). Of these audits I have the
following statistics (from large companies such as News Ltd, financial
organisations, credit unions, a stock exchange, government depts. and even
the to smaller firms).
No. Audits No. Organisations
Compliant with ALL
criminal 54 7
Provisions of
the law
Compliant with ALL
Tortious and 32 1 (and I
will not say who it is)
Contractual
requirements
Compliant with ALL
Regulatory 45 2
Provisions
The few (less then 0.1%) who made any way towards being compliant
achieved this by breaking down the scope and not trying to overlap.
In fact, the worst cases are those that try to "simplify" things doing
them all at once.
And the laws on evidence are that you need to hold all business records
that MAY in some future point (say 6 years in the future) possibly be
subject to a filing. That is not only existing legal action, but potential
action.
And you have added a whole pile of legislation that is not an issue, but
forgotten:
United Kingdom
. Anti-Terrorism, Crime & Security Act 2001 (UK).
. Communications Decency Act 1996 (UK).
. Computer Misuse Act 1990 (UK).
. Consumer Credit Act 1974, UK
. Consumer Protection Act 1987 (Product Liability) (Modification)
(UK)
. Criminal Justice (Terrorism and Conspiracy) Act 1998 (UK).
. Criminal Justice Act 1988 (UK).
. Criminal Justice and Public Order Act 1994 (UK).
. Data Protection Act 1998 (UK).
. Electronic Commerce (EC Directive) Regulations 2002 (UK).
. Electronic Communications Act 2000 (UK); Statutory Instrument
2000 No. 1798 (C. 46) ELECTRONIC COMMUNICATIONS Electronic Communications
Act 2000 (Commencement No. 1) Order 2000;
. Electronic Signatures Regulations 2002 (UK) (Statutory Instrument
2002 No. 318)
. Enterprise Act 2002 (UK)
. Human Rights Act 1998 (UK)
. Indecent Displays (Control) Act 1981 (UK).
. Interception of Communications (Lawful Business Practice)
Regulations 2000 (UK).
. Obscene Publications Act 1959 (UK).
. Obscene Publications Act 1964 (UK).
. Privacy & Electronic Communications (EC Directive) Regulations
2003 (UK).
. Protection of Children Act 1978 (UK).
. Public Order Act 1986 (UK).
. Regulation of Investigatory Powers Act 2000 (UK).
. Sale of Goods Act 1979, UK
. Sale of Goods (United Nations Convention) Act 1994 (UK)
. Sexual Offences (Conspiracy and Incitement) Act 1996 (UK).
. Sex Offenders Act 1997 (UK)
. Sexual Offences Act 1956 (UK).
. Telecommunications (Lawful Business Practice)(Interception of
Communications) Regulations 2000 (UK).
. Telecommunications Act 1984 (UK).
Australia
. Broadcasting Services Act 1992 (Cth, Australia)
. Copyright Act 1968 (Cth, Australia)
. Copyright Amendment Act 1984 (Cth, Australia)
. Copyright Amendment (Digital Agenda) Act 2000 (Cth, Australia)
. Copyright Amendment (Moral Rights) Act 2000 (Cth, Australia)
. Copyright Amendment (Parallel Importation) Bill 2001 (Cth,
Australia)
. Circuit Layouts Act 1989 (Cth, Australia)
. Corporations Act 2001 (Cth, Australia)
. Designs Act 1906 (Cth, Australia)
. Employees Liability Act (NSW) 1991 (Australia).
. Patents Act 1990 (Cth, Australia)
. Patents Amendment (Innovation Patents) Act 2000 (Cth, Australia)
. Privacy Act 1988 (Cth, Australia)
. Telecommunications Act 1997 (Cth, Australia)
. Trade Marks Act 1995 (Cth, Australia)
. Trade Practices Act 1974 (Cth, Australia)
United States of America
. Alien Tort Claims Act (ATCA) 1789 (United States of America)
. Communications Decency Act 1996 (CDA) (United States of America)
. Computer Fraud and Abuse Act (CFAA), (18 U.S.C. 1030) 1986
(United States of America)
. Computer Misuse Act 1990 (United States of America)
. Digital Millennium Copyright Act (known as DMCA 512 or the DMCA
1998) (United States of America) (Public Law No. 105-304, 112 Stat. 2860,
2877).
. Foreign Intelligence Surveillance Act (FISA) (as codified in 50
U.S.C. §§1801-1811, 1821-29, 1841-46, and 1861-62) 1978 (United States of
America)
. Online Copyright Infringement Liability Limitation Act (OCILLA)
1998 (United States of America)
. Patent Act 1790 (United States of America)
. Private Securities Litigation Reform Act 1995 (United States of
America)
. Restatement and Uniform Trade Secrets Act 1985 (United States of
America)
. Telecommunications Act 1996 (United States of America)
. Trademark Act 1946 (United States of America)
. Uniform Electronic Transactions Act 1999 (United States of
America)
. Restatement (Second) of Contracts, S 56 & The United States
Framework for Global Electronic Commerce (United States of America)
Other Legislation, Statues and Directives
. Copyright Act 1985 (Canada) (R.S., c. C-30, s. 1)
. Data Protection (Amendment) Act (2003) Ireland
. Data Protection Act (1998) Ireland
. Laki tietoyhteiskunnan palvelujen tarjoamisesta (458/2002)
Finland.
. Loi relative à l'économie numérique (2002) France
. UNCITRAL Model Law on Electronic Commerce with Guide to Enactment
(1996), with additional article 5 bis as adopted (United Nations Model Law
on Electronic Commerce (1996))
EU Directives
. European Union Directive 1999/93/EC of the European Parliament
and of the Council of 13 December 1999 on a Community framework for
electronic signatures
. European Union Directive 2000/31/EC on Electronic Commerce OJ
2000 L 178/1 and Council Directive 94/44/EC on Certain Aspects of the Sale
of Consumer Goods and Associated Guarantees OJ I 171 7.7.99
. European Union Directive 2000/31/EC (on Electronic Commerce OJ L
178 p1, 17 July 2000)
. European Union Directive 2002/58/EC (The E-Privacy Directive);
. European Union Directive 85/374/EEC (The Product Liability
Directive)
You got his one at least;
. European Union Directive 95/46/EC (Data Protection Directive);
Regards,
Dr Craig Wright (GSE-Compliance)
PS - audit manager in a chartered audit firm.
Craig Wright
Manager of Information Systems
Direct : +61 2 9286 5497
Craig.Wright@bdo.com.au
+61 417 683 914
BDO Kendalls (NSW)
Level 19, 2 Market Street Sydney NSW 2000
GPO BOX 2551 Sydney NSW 2001
Fax +61 2 9993 9497
http://www.bdo.com.au/
Liability limited by a scheme approved under Professional Standards
Legislation in respect of matters arising within those States and
Territories of Australia where such legislation exists.
The information in this email and any attachments is confidential. If you
are not the named addressee you must not read, print, copy, distribute, or
use in any way this transmission or any information it contains. If you
have received this message in error, please notify the sender by return
email, destroy all copies and delete it from your system.
Any views expressed in this message are those of the individual sender
and not necessarily endorsed by BDO Kendalls. You may not rely on this
message as advice unless subsequently confirmed by fax or letter signed by
a Partner or Director of BDO Kendalls. It is your responsibility to scan
this communication and any files attached for computer viruses and other
defects. BDO Kendalls does not accept liability for any loss or damage
however caused which may result from this communication or any files
attached. A full version of the BDO Kendalls disclaimer, and our Privacy
statement, can be found on the BDO Kendalls website at
http://www.bdo.com.au/ or by emailing mailto:administrator@bdo.com.au.
BDO Kendalls is a national association of separate partnerships and
entities.
-----Original Message-----
From: listbounce@securityfocus.com [mailto:listbounce@securityfocus.com]
On Behalf Of W. Lee Schexnaider
Sent: Wednesday, 27 February 2008 9:38 AM
To: Sheldon Malm
Cc: security-basics@securityfocus.com
Subject: Re: ISO 27001 mapping to PCI
Unsurprisingly, I agree with Sheldon.
The problem companies are having is that the number of regulations and
best practices that they have to conform to is exploding. Just think
if you are a public company in California that processes health care
information that has customers and partially-owned public subsidiaries
in Europe, Japan and Canada. So that organization and its
subsidiaries have to comply with SOX, CSOX, JSOX. EuroSOX (in the
future), HIPAA, California AB 1298 (health information data breach),
California SB 1386 (data breach), and European privacy laws. Then you
choose ITIL for service management and Cobit (or ISO) for your info
security framework. And that is not counting the new Federal Rules of
Civil Procedures changes for e-discovery, if you happened to be part
of several lawsuits at the same time. If a company had dedicated
internal audit teams and used different standards and processes for
each of these, the cost would be (and frequently is) enormous and
growing.
That is why having common controls mapped to these various items makes
sense for your internal audits to give proof of compliance to your
external auditors. You can also know if you have a control called
"password length" that one technical check can apply for many
different regulations and best practices so you don't have to tie up
your systems and networks by checking this multiple times for multiple
internal compliance groups.
W. Lee Schexnaider, CISSP
Sr. Engineer - Compliance Content Developer
Symantec Corporation
www.symantec.com
-----------------------------------------------------
Office: 713.561.4111
5151 San Felipe
Houston, Texas 77056
Email: lee_schexnaider@symantec.com
-----------------------------------------------------
On Tue, Feb 26, 2008 at 12:35 PM, Sheldon Malm <smalm@ncircle.com> wrote:
> I'm not going to get into a debate with you on this - simply stating
> that the preparation for audits is very different than the execution
of
> audits. For the record, my working for a vendor in this space has
> nothing to do with my opinion. I spent nearly a decade with a Fortune
> 500, and used the same approach very effectively on the customer side.
>
> There is sufficient overlap in the preparation stages for different
> standards that it makes sense to tag atomic items (controls) if they
are
> included in multiple standards for reuse. This is really no different
> than a platform like .NET making reusable services available to
multiple
> programs. Where the controls are identical, it makes no sense to do
> them separately and at multiple times by multiple people simply
because
> they fall into different, higher-order standards.
>
> Cheers.
>
>
>
> Sheldon Malm
> Director
> Security Research & Development
> nCircle Network Security
>
> Check out the VERT daily post
> http://blog.ncircle.com/vert
>
>
>
> -----Original Message-----
>
> From: Craig Wright [mailto:Craig.Wright@bdo.com.au]
> Sent: Tuesday, February 26, 2008 1:14 PM
> To: Sheldon Malm; Craig Wright; PCSC Information Services; p1g; Jason
P.
> Rusch
>
> Cc: security-basics@securityfocus.com
>
>
> Subject: RE: ISO 27001 mapping to PCI
>
> Well you are marketing a product So I would expect Such a response.
>
> The reality is that this approach is BS. Any organisation that I have
> seen doing this Fails @ least one if not both.
>
> Different systems have Separate requirements. You Can make an ISO
> 27001/2 ISMS for a PCI system -but it will not apply elsewhere and is
> more work then Completing each one at a time.
>
> Craig (GSE-Compliance,G7799,GPCI...)
>
>
