RE: ISO 27001 mapping to PCI

["Sheldon Malm" <smalm () ncircle com>]

I still believe that we're looking at this from different logical levels.  You're addressing the scope of particular 
standards from an audit execution perspective, and I don't think anyone disagrees with you on that part.  
Oversimplification is bad, and no one on this list is advocating using ISO 27001 to meet all audit requirements.  

Lee and I are coming at it from the particular control perspective.  If n distinct standards all make reference to a 
particular "password complexity" control object, then it makes absolute sense for an organization to identify that 
control object and associate the single control object to the standards to which it applies.  This not only streamlines 
the audit preparation process but also highlights where standards may conflict or where the most strict guideline 
covers other standards that are not as strict.  

To use a hypothetical example:
- Standard A requires passwords to be a minimum of 8 characters; 
- Standard B requires passwords to be a minimum of 8 characters with alpha and a numeric enforcement; 
- Standard C requires passwords to be a minimum of 8 characters with mixed case; 
- Standard D requires passwords to be a minimum 6 characters, alpha-numeric, mixed case, and at least one "special 
character"

By mapping control objects to multiple standards, an organization can efficiently determine that their control object 
for password complexity should be set at a minimum of 8 characters, alpha-numeric, mixed case, and at least one special 
character.

This does *not* mean that a particular standard should be used to prove compliance with all standards (or even multiple 
standards).  It means that organizations can implement controls that meet or exceed each of the standards for which 
they must comply.  It also means that they can proactively assess their compliance for a standard that they may need to 
meet in the future (ie: preparing for an IPO, which brings SOX into play).

I would invite you to take a look at the work that mitre has done with CCE, OVAL and XCCDF.  CCE is about common 
configurations (ie: control objects), OVAL is about representing checks for these control objects in a common language, 
XCCDF is about representing these checks in a framework that adds context that can be applicable to different, specific 
standards.  

I'm with Lee on this - we'll have to agree to disagree.  For those on the list, I hope the discussion has been helpful.


Sheldon Malm
Director
Security Research & Development
nCircle Network Security

Check out the VERT daily post
http://blog.ncircle.com/vert



-----Original Message-----
From: listbounce () securityfocus com [mailto:listbounce () securityfocus com] On Behalf Of Craig Wright
Sent: Tuesday, February 26, 2008 11:51 PM
To: 'W. Lee Schexnaider'; Sheldon Malm
Cc: security-basics () securityfocus com
Subject: RE: ISO 27001 mapping to PCI


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...)