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