ISO 27k Endured: ISO 27001 and ISO 27002

Hold onto your socks for this one, dear Reader.

I am not sure why this week was a week of standards, but in a lot of ways it was that and a standard week in that I never know what the topic or theme of the week will be. This past week, the subject of 27k (or ISO 27001) Compliance came up. The first was a friend who wanted to know what it was, the second was work-related, and the third was in a casual discussion that started out about Armadillos, of all things. It moved to Platypuses (Pattypusi?) and looped back around to a more philosophical take on what a standard is (think again about Universals and Particulars and my previous posts that attempt to lend value to my Philosophy degree).

That said, it made sense to write a little about the 27k Standard or at least a portion of it, much like I have written about a portion or segment of PCI Compliance, 508 Compliance, and general human Compliance.

ISO was there when I worked construction. They made sure we all had hard hats on and nobody wore steel toe boots. That was easy. You saw them coming and you put a hard hat on if you could find one and it didn’t matter if it was flopping around on your head like a bobblehead doll. When it comes to technology and technical compliance, it is a little harder to slap something together although it is a little easier in some ways to comply, because there really is no litmus test aside from rather blatant and uninformed decisions like storing credit card numbers locally, not encrypting sensitive data, etc. 508 has things you need to do, things that you really should do, things you might do, and things that would make people really happy if you did them but nobody quite expects you do. Not so with PCI or 27k but again, even PCI and 27k Compliance are determined by formal audit and let’s just say that I have heard the auditing companies be accused of running a racket, of being for sale, and generally everything you might expect someone to say about a company they feared in some sense or had to pay a bunch of money to for them to essentially go through your underwear drawer. In this case however, it is only your drawer, and the underwear belongs to other people. This is a perversion we will overlook for the sake of the blog post although it is a metaphor I could carry for pages and pages.

The ISO 27001 Standard is in reference to Security Management. Notice it is not related only to Information Technology Security, because it gets into things like hiring practices (be sure not to hire any bad guys) and workplace safety (have hardhats handy). You have 27001 and 27002 but in reality they are just references to each other. 27001 is a bucket that somewhere around 130 items fall into, all detailed within 27002. I would have suspected that they would use dot notation for the sake of simplicity, and I have no idea why they would start with 27001 when it seems to me they could just call it “Security Management Standards” but I suppose ISO just might handle that many types of specifications. The purpose of 27001 is to serve as something that is audited through examination of 27002. That really, is all it is, as far as you will likely ever need to know. It is sometimes coupled with ISO 9001 (Quality Management Standards) and ISO 14001 (a voluntary Environmental Management Standard) just to give it that little something extra. A little spice to keep it from being boring, and indeed, mixing ISO Standards can be as delicious and exciting as a little “pow” in the kitchen. I guess. I mean, the addition of layers of compliance only serves to create a more robustly compliant System that pleases everyone with a tie and an appetite for things ISO.

ISO sleepy, but I will press on. That was a joke. Say it out loud. Ha, right?

There is an ISO 27002 (used to be ISO 17799 but you gotta keep ‘em on their toes) and it is more geared towards the organization than a product or data. There is also an ISO 27003 Standard which oversees an ISMS or Information Security Management System: something to wield against ISO 27002. You might guess there is an ISO 27004. You are right. It determines how effective your 27003 is. I hear you saying “a ha – so there must by an ISO 27005 that either details 27004 or provides a framework for 27004” but you are wrong. It made sense, but you were wrong. ISO disappointed in you. 27005 covers the Risk associated with information security and how to manage risk therein. What’s that? You are dying to know what 27006 is? All I know is what I read about this one and it apparently makes clear a specification for requirements listed in ISO 17021 which in turn evaluates organizations against ISO 9001 and ISO 14001. It stops there for the 27k line. Thank Goodness. I know.

So, ISO 27001 is really a guideline for auditors to look to in order to be told that they really want to be evaluating the system against ISO 27002. Everyone flips the page and looks at 27002 after noting that 27001 mentioned there are about 130 points of interest to be relished.

ISO 27002 is the one that you can act against, judge against, measure against (in some cases) and sink your teeth into like a big delicious steak with “pow”.

The cool kids call ISO 27001 and 27002 “ISO27k” so I will too, because I just want to fit in, really. Remembering that 27001 is like a Table of Contents and intended to be used for existing as well as incipient systems. It is beautifully robust in that fashion. It also employs the “Plan, Do, Check, Act” cycle which keeps a lot of people constantly working and coming back to make sure things are still as they are supposed to be when something goes live. To be fair, because I know I sound a little bit critical, this is all good stuff. ISO 27002 is something that you do not pass or fail outright, and it is broad enough to in some cases tell you exactly what you need to ensure and in other cases have you wondering how the heck that section applies to you. Let’s take a look at it.

Hey, this is the theme of the week. Next week will change. And I want to make it clear that just because it is called ISO 27001 it does not mean that there are 27000 Standards preceding it or that the ISO Standards Group is a monster. It is fuzzy and cuddly, like a baby bear.

ISO 27002 is outlined in 27001 and consists of 16 sections, although I am happy to see one section is called section “0”, like iteration 0 in development, but in a much more sensible way in that section zero is just an intro, not a whole boatload of things that someone has to do. The sections are:

0. Intro

This section tells you what the heck you are supposed to do with the rest of the sections.

1. Scope

This section gives general recommendations.

2. Terms and Definitions

Since this is all about information security, the document recognizes that the term can be construed in a wide variety of ways and gives you some context as to what ISO is intending. There is an ISO 27000 which seems to be slated to contain many of these definitions, which would make sense as the terms are used throughout the 27k guidelines.

3. Structure of the Standard

Yes, they do get a little carried away. You are looking at the structure of the standard, after all.

4. Risk Assessment and Treatment

But don’t we have another ISO Standard for Risk? Not quite the same, and not explicitly for Information Security. This section is short and lets the person doing the audit or building towards compliance the freedom to decide what the best method to control Risk in their given situation may be. This is hard to pass or fail, obviously, and I think it exists just to let you know there should be some Risk Management practices in place. Formal ones. Ones you can explain to the Auditors if they ask. Not just “well, Jimmy makes sure.”

5. Security Policy

They really want you to have a manual outlining your security practices, efforts, mandates, rules, exclusions, and anything you can think of or that they might think of for you. The end goal of this compliance effort is admirable. But so far it does, to some, seem like a lot of documentation that is not even clearly required or clearly not applicable. Having a Policy document makes it clear that someone in management recognizes this effort because if it is an official company policy, it needs support from those able to make company policy, and our buddy Jimmy is probably not the one to give their stamp of approval.

6. Organization of Information Security

Governance. How will it all be controlled and utilized?

This section happily includes dot notation:

6.1 Internal Organization

Roles, responsibilities, dictum, and how the organization will collaborate to give life and breath to what would otherwise be simply paper or digital assets and something people file away next to the company policy on what to do if you have a heroin addiction and need to talk to someone on an 800 number.

6.2 External Parties

You are not supposed to compromise security by bringing in shady third parties or, more formally, any interaction with a third party should be carefully evaluated and recognized as an extension of the System, with efforts surrounding Information Security cascading to the limb. To some extent, if you create software or a product that is fully compliant in every sense, someone who purchases it and has rights to do so may completely blow your efforts out of the water by linking up with a less than scrupulous, talented, informed, or able partner or system. Much like PCI, you may create a compliant system, but pack it’s lunch and send it off to school and no matter what you teach it at home someone in History class might convince them to do something risky and unmitigated or outright dangerous (like launch themselves from the swing when it is at its apex and lead to a bad sprain). All you can really do its try, in some situations, which is partly why 27001 points out that 27002 is contextual.

7. Asset Management

You need to, as an organization, keep your stuff secure. This is not software-specific, and easily could be one of those items that does not apply. You might not have any assets. Your assets might be inherently dangerous and wrapped in another set of ISO Standards for safety. Or, you might just plain not have anything worth stealing. More dot notation here. I enjoy dot notation.

7.1 Responsibility for Assets

Keep an inventory. Little stickers on everything. Someone keeps track of who has what and where it is. At all times there should be someone who’s job includes knowing where the last batch of laptops wound up and who has which one and what they are doing with it. Again, this could very easily not apply.

7.2 Information Classification

Some things are worth worrying about and some are not. The vending machine’s current Twinkie count is not something that would likely be relevant to security, but access to a database that stores information regarding purchasing those Twinkies might be. How to classify? In a way that makes sense.

8. Human Resources Security

This is not about software, but more about the organization, obviously. This is not even about Information Security until you look at the happily dot notated children of section 8 describe.

8.1 Prior to Employment

You do not want to hire people who are going to compromise security. More or less.

8.2 During Employment

Make sure people get a copy of the Policy and understand how they fit into it. The standard also calls for some form of reprimand, or spanking, if someone gets out of line

8.3 Termination or Change of Employment

When people leave, make sure they don’t injure the organization, make sure they return all their stuff (neatly organized as per section 7), and that they get a police escort out if they are prone to violence or you wish to humiliate them on a Friday afternoon without fear or an outburst. I saw this with a failed Sarbanes-Oxley audit. The guy didn’t even do anything wrong. They played him for a patsy, but gave him a police escort just to (in my opinion) make it appear as though he was potentially going to throw a fit. Meanwhile, he was one of the nicest guys I ever met. ISO 27002 helps you if you decide that you need a fall guy. If it is policy, it is policy, and the police are coming to show you the door.

9. Physical and Environmental Security

The question is often asked; “Is common sense all that common?”

9.1 Secure Areas

Sometimes, doors need locks.

9.2 Equipment Security

Extension cords that lay across puddles are a bad idea.

10. Communications and Operations Management

This is where things become a bit of a beast.

10.1 Operational Procedures and Responsibilities

Don’t let anyone have too much power or be the one person who knows everything. That proverbial bus that always hits the important people is coming down a pothole-pockmarked street someplace and who knows. Things happen.

10.2 Third Party Service Delivery Management

When you work with a third party (yes, we have been here before), make sure they are not putting you at risk in any way. And then do it again. And then again. You are going to have to hire someone to make sure you are doing it again and again, so document each time and have something written down and executed. Not shot, but signed. Shooting is not safe for people or for data. Bullets and NOCs do not mix.

10.3 System Planning and Acceptance

How to plan and deliver good stuff in line with this Standard.

10.4 Protection Against Malicious and Mobile Code

Hoo boy. This makes good enough sense, but if a new exploit is found and someone takes advantage despite best efforts to avoid that very thing, does that invalidate your checkmark next to this item? I don’t think it does. It is about protection, not hermetic sealants.

10.5 Back-up

Even Grandma does this. You should, too. But, you should do it in accordance with the framework set forth in ISO 27k. Grandma does not understand her role. I asked her. She offered me a scone. I took it as a bribe and reported her.

10.6 Network Security Management

This is what it sounds like. Keep your network secure from the cabling (nothing in a puddle, please) to your VPN and authentication schema.

10.7 Media Handling

If you have a floppy disk with something sensitive on it, make note of that and document how many pieces you cut it into, why on Earth you had it on a floppy disk, and what you did with the pieces as well as why you decided to cut it up, who gave you the instruction to, or anything at all that may be questioned. In some of these you have to assume the role of defendant and anticipate that everything you do will be questioned so document, CYA, or try to get someone else to document that they have accepted responsibility for it all.

10.8 Exchange of Information

While it is on the way, before it goes, after it lands, and while the exchange is being planned, everything should follow guidelines that ensure security. I would not email a list of credit card numbers from Gmail or send them in a message on Facebook. You might want to use PGP and an RSA key or something of that nature, handcuffing the briefcase to someone who is not on anyone’s hit list and can run really fast. This is not just in relation to electronic data, although that should be obvious. If you have sensitive information on a spreadsheet that is printed out and on your desk, get ready to start chewing and swallowing when the auditors come.

10.9 Electronic Commerce Services

Here, I would personally suggest leaning on PCI. That is really what it seems they are calling for. And, by leaning on PCI, you are keeping another whole group of consultants in work. If you are not using credit cards, the same principles apply.

10.10 Monitoring

Know who is on your network and system, who tried to get on but failed, have proper procedures in place for when a breech occurs, and make sure nobody gets their grubby little hands on anything besides a “connection refused” or similar message that is not supposed to. This can go very deep to role security monitoring if you want it to and even applies to things like making sure all server clocks are in sync

11. Access Control

Another beast of a section; the main takeaway is to control access to your system.

11.1 Business Requirement for Access Control

They want another Policy here, taking into account the specific business rules and requirements that may necessitate someone or some role being able to get to specific data of a security sensitivity level other than what the company logo looks like, in theory.  Those people who are responsible for a given task or for ensuring a specific procedure will be identified here (the who) along with the details of the why and the what as well as possibly then when and the when not.

 11.2 User Access Management

This sounds a lot like using a tool akin to Active Directory in a secure fashion to control who (individuals and roles) along with the details of the why and the what as well as possibly then when and the when not. As with most things in 27k and other Standards, there is the need to periodically review. Not surprisingly, there are a host of organizations who will be happy to bill you for help you with this task that is not cut and dry nor always completely relevant and in context.

11.3 User Responsibilities

RTFM. Read the Manual (or Policy) so you know what is expected of you and how to interact with the secure system

11.4 Network Access Control

It seems like we talked about this already and addressed it in 10.6, but because of the amorphous nature of this effort and because of reasons I am sure I do not understand today, this is here as well

11.5 Operating System Access Control

They do not mean Access to Windows 2000 Server here. They mean the system that is operating to handle Access Control. You have to be sure it is used and used in a secure manner. This looks like a systems requirement, but it is really an organizational requirement.

11.6 Application and Information Access Control

Your Policy will touch on this if not detail it to 4 levels of dot notation, which is very sexy in my book. This calls for a deliberate and thoughtful protocol concerning who can use what and how. Seems like we were here before as well. Indeed, the entirety of section 11 is in some ways a retooling of other items within 27002. However, this is a one size fits all document and so context may render one item inapplicable when the need persists so you have a safety value in section 11.

11.7 Mobile Computing and Teleworking.

I think you can figure this out, but in case you cannot, this section asks that you have a policy towards how those who work remotely or will be sitting in the airport on their mobile phone and using the application are told that they cannot, for example, access the application, system, document, or entity while at the airport on their mobile device.

12. Information Systems Acquisition, Development, and Maintenance

Another lengthy one.

12.1 Security Requirements of Information Systems

Test what you are buying or ask to see an audit report that is as close to the morning of the acquisition as possible. If you are not buying it and are instead building it, build it in a secure fashion with “27k Makes my Day!” written on the development room wall.

12.2 Correct Processing in Application Systems

When you put things into the system, do it right. Better yet, prevent the ability of doing it wrong.

12.3 Cryptographic Controls

You will want to manage and define a good cryptography method and continually review it without calling attention to it or sharing it with more people than you need to because after all, this is Top Secret (Section 7.2) stuff we are dealing with here.

12.4 Security of System Files

Goodness gracious.

12.5 Security in Development and Support Processes

Make sure the people who are involved with doing all this stuff, and especially the ones developing it, are not building back doors for themselves or sending data to a mailbox in some far away land.

12.6 Technical Vulnerability Management

If an exploit or security flaw is identified, knock that sucker out. Then, find out who is responsible and have them escorted via law enforcement to the door at 4:55 on a Friday and pack their desk for them, leaving the box on their desk for a few days and then mailing it out to them at home.

13. Information Security Incident Management

Because things happen.

13.1 Reporting in Information Security Events and Weaknesses

You want something in place to rapidly ensure any reported “incident” is quietly screamed to the appropriate people, documented, and stored in a way that nobody can access, in accordance with 11.1 – just kidding, but yeah, that is what is going on here. Fix the problem through a predetermined manner that not only solves the problem but documents it, does a damage assessment if appropriate, and is weaved into the product or physical building’s structure. This is not always about code. It could be that people smoke and leave the back door propped open because it locks from the inside when closed. Make sure the door closes and make the smokers do it in a little circle painted far away from where they might damage someone’s lungs. Of course they will damage their own, but we accept this, and it is done in a controlled fashion

13.2 Management of Information Security Incidents and Improvements

Formalizing the practices that fall into place when 13.1 is kicked off, 13.2 will serve as a method to revisit and revisit and revisit and re-audit and re-audit and re-audit your 27k compliance statement.

14. Business Continuity Management

Be sure your organization can carry out all procedures denoted and do so on a regular basis, checking for gaps, holes, flaws, and changes. Applaud nobody, but berate those who have failed to do their job. You get no points for doing what you are supposed to do. That last sentence is not part of the Standard, but Mom used to say it to me so I get to say it to you now. I did not like it then and if you read this far, you are likely to think it is didactic. You would be right. You would also be someone I did not take quite seriously because if you read this far you must have something wrong with you. That, or be a true connoisseur of finely tuned prose.

15. Compliance

Say what? Wasn’t this whole thing about compliance? Let’s see:

15.1 Compliance with Legal Requirements

There are laws above and beyond your silly little handbook. You need to follow those as well. This, of course, does not apply to government agencies *wink* and *nod* to the Bush Administration (I really do not know enough about it to say anything, but I sometimes catch Fox News or the Saturday Night Live Weekend Update so I am a bit qualified to make political statements of fact).

15.2 Compliance with Security Policies and Standards and Technical Compliance

People who tell other people to do things or hire other people to do things should tell or hire smart and capable people to be sure their people are smart and capable and that their compliance effort is being adhered to. When the people doing this audit show up, they will be looking for people who are frantically shoving paper into their mouth, masticating it, and swallowing without the aid of water. Listen for the gags and follow the sound to locate weak links.

15.3 Information Systems Audit Considerations

When you do an audit, do not do it in a way that will affect the business negatively (unless it is affected negatively because of a miserable failure of an audit) and try to audit securely. Those who audit are able to open all doors and examine all assets, so make sure that they at least have a business card saying that they really work for an auditing company.

 J

 Hope you enjoyed.

 Best,

 Josh Milane