Re: ISO 27001 mapping to PCI

["exzactly" <exzactly () hotmail com>]

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