ISO 17799 It's a control, not a standard

By Patrick Lamphere
April 29, 2007
Computerworld

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

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

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

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], BS 7799-3,
Tarot) to determine the risks that apply to your defined information
assets.

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.

Article Source : http://www.computerworld.com/action/article.do?command=viewArticleBasic&taxonomyName=security&articleId=9018158