Security Basics mailing list archives
RE: ISO 27001 mapping to PCI
From: Craig Wright <Craig.Wright () bdo com au>
Date: Thu, 28 Feb 2008 09:23:00 +1100
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...) > >
Current thread:
- RE: ISO 27001 mapping to PCI, (continued)
- RE: ISO 27001 mapping to PCI Sheldon Malm (Feb 26)
- RE: ISO 27001 mapping to PCI Palmer, Mark (Feb 26)
- Re: ISO 27001 mapping to PCI W. Lee Schexnaider (Feb 25)
- RE: ISO 27001 mapping to PCI Craig Wright (Feb 26)
- RE: ISO 27001 mapping to PCI Sheldon Malm (Feb 26)
- Re: ISO 27001 mapping to PCI W. Lee Schexnaider (Feb 26)
- RE: ISO 27001 mapping to PCI Craig Wright (Feb 27)
- Re: ISO 27001 mapping to PCI W. Lee Schexnaider (Feb 27)
- Re: ISO 27001 mapping to PCI exzactly (Feb 27)
- RE: ISO 27001 mapping to PCI Sheldon Malm (Feb 27)
- RE: ISO 27001 mapping to PCI Craig Wright (Feb 28)
- RE: ISO 27001 mapping to PCI Sheldon Malm (Feb 26)
- RE: ISO 27001 mapping to PCI Sheldon Malm (Feb 27)
- RE: RE: ISO 27001 mapping to PCI Sheldon Malm (Feb 27)
- Re: RE: ISO 27001 mapping to PCI W. Lee Schexnaider (Feb 28)