ISO 17799 -- it's a control, not a standard

ISO 17799 -- it's a control, not a standard
ISO 17799 -- it's a control, not a standard 

By Patrick Lamphere
April 29, 2007 

Im always interested when I learn that things arent the way I thought 
they were.  Mom put "Santa's" presents under the Christmas tree.  
Columbus didnt discover America.  Lee, Lifeson, and Peart arent equal to 
the Father, Son, and Holy Spirit. And, most recently, ISO 17799:2005 
shouldnt be used as a list of required controls for organizations to 

Dont get me wrong.  For something written by committee, the 
International Standards Organization and International Electrotechnical 
Commission - Code of Practice for Information Security Management 
Reference Number 17799:2005 (from here on out ISO 17799) isnt half bad.  
As anyone familiar with it knows, its a fairly exhaustive list of 
controls covering 11 major domains of information security (more on that 
later), from policy to compliance.

Its not perfect.  Aside from the Briticisms (it is their language, after 
all), there are some areas where it doesnt give enough depth or detail, 
others where it goes a little overboard, and some terminology that is 
just plain odd ("Threat Vulnerability Management," anyone?).  But these 
relatively minor shortcomings are outweighed by the overall benefits for 
those companies that turn to it for guidance.

If your company is adopting ISO 17799 as a "standard," however, youre 
missing the point. ISO 17799 is a list of controls -- nothing more, 
nothing less.  Notice the ample use of the word should throughout the 
document.  Nowhere are there any requirements that an organization do 
anything.  No shall or shall not, no do or do not -- ISO 17799 is a list 
of guidelines, not requirements.

This is a good thing.

ISO 17799 was originally British Standard 7799-1, and meant to be 
adopted along with the other parts of the 7799 series, namely 7799-2 
(Information Security Management Systems) and 7799-3 (Guidelines for 
Information Security Risk Management.  Further muddying the waters, BS 
7799-2 was recently adopted as ISO 27001.  BS 7799-1/ISO 17799 will 
eventually be renumbered as ISO 27002 (PDF format) [1].

So whats the point?  Thats where ISO 27001 comes in.  ISO 27001:2005 is 
a specification for an Information Security Management System (ISMS): 
These are things you must do to set up an ISMS.  But what is an ISMS?  
The ISMS is the framework you need to have in place to define, implement 
and monitor the controls needed to protect the information in your 

And here we get back to information security. ISOs 17799 and 27001 arent 
just concerned with the data sitting on your companys collection of hard 
drives. They cover how your company protects its information in all its 
forms, from bits on disks to black marks on dead trees and piles of 
sentient meat.

This is also a good thing.

Getting started ISO 27001-style

There are 5 main clauses of the ISO 27001 standard (8 total, but 1-3 are 
definitions and overview), plus an annex that maps directly to 
17799/27002.  Clause 4 is the meat of the standard.  It outlines the 
requirements for the ISMS.

First you establish the scope -- what is it going to cover?  Your entire 
organization?  A smaller portion (like a datacenter or subsidiary)?  
The scope is up to you, but needs to be reasonable -- if youre an online 
backup firm, for instance, excluding the servers used to perform those 
backups but leaving everything else in wouldnt make sense.

Once youve got scope defined, you create the policy to govern the ISMS.  
This includes the usual high-level policy stuff such as management 
support and alignment with the business; along with the interesting 
parts that make ISO 27001 unique and more useful than any of the other 
frameworks out there: contractual (PCI), business, legal and regulatory 
(eg., SOX or HIPAA) requirements; and the risk management context, 
including risk assessment and acceptance criteria.

After youve got your scope and policy, its time to get down to work 
figuring out what information assets you have, and doing a risk 
assessment of each of those assets.  The assets can be as granular as is 
reasonable for your business, though its easier to lump things together 
(for example, one asset type defined as employee personal information 
instead of separate categories for W-2, I-9, 1099, 401k, and so forth).  
Once the assets are figured out, you can then choose your favorite risk 
assessment methodology (OCTAVE, NIST 800-30 [PDF format] [2], BS 7799-3, 
Tarot) to determine the risks that apply to your defined information 

Suggestions, not requirements

Now that youve determined your risks, its time to pick controls.  And 
heres the best part: while you do need to address the control areas 
outlined in Annex A, the controls you select dont have to be as 
stringent as whats outlined in ISO 17799/27002. The controls in ISO 
17799/27002 are suggestions. Its up to you to pick the controls that 
provide an appropriate level of mitigation for your business.  Granted, 
you still need to take into account the realities of your regulatory 
environment (no 4 character passwords and ROT13 encryption for PCI), but 
the controls beyond that, as long as they are reasonable for the defined 
levels of risk, are entirely up to your business

A side note on risk -- as part of any risk assessment program, you 
should have guidelines for how risks are going to be handled -- 
mitigation (the application of controls), acknowledged and deferred (we 
know about that, we just cant afford to do anything about it right now, 
hold off until the next budget cycle), transferred (insurance), and 
acceptance (the level of risk that the business is able to live with).

The remainder of clauses 4-8 deal with the management acknowledgement 
and acceptance of any residual risk, ensuring that the ISMS is kept up 
to date through periodic management review, internal audit, and process 
improvement; and of course proper documentation (if its not on paper, it 
doesnt exist).

And the benefits?

So once youve gone through this long (18-30 months) and admittedly 
difficult-at-times process, whats the benefit?

Controls that align with the business.  No longer are your information 
security controls applied based on the whims of management and 
proclivities of your IT staff.  Risk is managed as a whole -- no more 
chasing down the rat-hole of SOX only to finally crawl back out again, 
bruised, bloodied, and battered, to repeat the experience with HIPAA, 
then with SB 1386, then PCI, USA PATRIOT (PDF format), FinCEN, OFAC, 
PIPEDA, ad infinitum.

Best of all? You can get your business certified to the fact that you 
have a functioning ISMS that incorporates the requirements of all the 
legal, contractual, and regulatory requirements that you have included 
in your scope. Its the closest thing out there to being certified 
compliant to HIPAA or SOX. And the cost of certification is surprisingly 
cheap -- $15K to $50K for three years, depending on the size and scope 
of your ISMS. And despite what the security community is more than 
willing to sell at the moment, you cant certify to ISO 17799/27002. The 
controls outlined in ISO 17799 are simply guidelines, not requirements.

This isnt to say that an organization cant decide to use those 
guidelines as the basis of their control framework, and then perform a 
gap analysis against those controls. Its just by deploying ISO 
17799/27002 and ignoring 27001, youre missing a fantastic opportunity to 
bring your Information Security and IT Departments to a level of 
maturity that is fully aligned with the realities your business faces.


Patrick Lamphere is a professional cynic, skeptic, and tubist who amuses 
himself working as an information security consultant. 


Subscribe to InfoSec News 

Site design & layout copyright © 1986-2015 CodeGods