The ISO 27000 is a generic way to call a set of ISO standards about security. In this article, I am going to describe how we did in one of my jobs to get the Certification for the Information Security Management System specified in ISO 27001 (and it is closely linked with ISO 27002).
First, we need to describe and make clear what is a Management System. According to ISO, a Management System is a set of procedures an organization needs to follow to meet its objectives. The use of a well-deployed Management System warrants that every request, incident, issue (or any name you want to put) will be processed always the same way with the same established quality. A Management System uses what is called the Deming Cycle which states a continuous improvement of all processes involved.
Another concept we need to establish before starting to tell this tale is what is a process. For me, a process is a sequence of interdependent and linked procedures which, at every stage, consume one or more resources (employee, time, energy, machines, money, etc) to convert inputs (data, material, parts, etc) into outputs. These outputs then serve as inputs for the next stage until a known goal or result is reached. I won't cover in this article how to document a process but don't lose the idea that you will need to document. The ISMS is all about documenting and keeping records, and not only the ISMS but any management system in general.
So, when you start defining your ISMS take in mind that you will need to back up all your statements. You will need the use of Security & Vulnerability Assessments or in the worst case a letter from the CEO accepting the involved risks. The CEO has the ultimate responsibility of the ISMS. We will talk about that later.
The asset is just another concept that comes to my mind. For me, an asset is anything that has value to the business. An asset has a value property that will play a crucial role in this process. I will talk about that later.
Ah! before I forget. If you are pursuing the ISO 27001 certification, you must know that certification is given to an organization with a specific business process. When you get an ISO 27k certification, the whole organization is not certified, only the specific process you applied for.
With these concepts, I will start telling what happened in those glory days.
The Guides from the ISO27k Forum
The following images are from the ISO27k forum. They are not mine. I remember we used them as our main guide to know what to do. We still read the ISOes, but a graphic flow saves time and gives a clear path of what we need to do.
The first image talks about the workflows and the second one is about the records an ISMS needs to output. It is a little difficult to talk about one without mentioning the other.
Steps to get the ISO 27001 Implementation
Getting Management Support
The first step is to get Management Support. This is a document signed by the CEO stating his/her full support for the implementation of the Information Security Management System. It doesn't need to be a long document, a one-page letter is enough. Some organization likes to back their decision with a business case document and it is highly recommended (you don't know how crazy an auditor could be). You will label it with a name such as Records of Management Decisions. As far as I remember, if you miss this document you will get a major fault in the audit. With a major fault, the certification is denied.
As this is your first record, you will need to state a Document Control Procedure. The DCP is not fully specified in the ISO 27000 series. You will need to read about it. In a few words, you need to document a process about how you will keep track of records. Some things you will need to do to do a good DCP are:
- Define a non-clashing nomenclature where you can know many things just by having the document ID
- Keep track of a document changelog with the author and dates of the changes
- A standardized template to use for your records
And I think that's all. By this step, you will output the following records:
- Business Case
- Records of Management Decisions
- Document Control Procedure
Define the ISMS Scope
As I was saying before, the ISMS is not over the whole organization. It is specific to a business process. So you will need to have a clear definition of the scope. As you know your business, this should be easy. For example, if you are an online shop, you could document the Online Selling process. You will need to document in a very clear way the chosen business process.
After knowing the ISMS Scope, you will need to start writing your ISMS policy. This is a big document stating all your security policies. You can use ISO 27002 as a guide, and indeed, I suggest you follow this by the book as auditors may ask and review this document. ISO 27002 won't tell you how to write, it will tell you what to write. You will need to cover those topics in your specific business policy document. Depending on the nature of your business, some domains won't apply. If that is the case, I remember an exception can be documented with a clear explanation of why.
At the end of this step, you will have two major records:
- ISMS Scope Document
- ISMS Policy Document
Do an Inventory of Information Assets
If you are familiar with ITIL or ISO 20000 this is going to be easy. The inventory (or a CMDB) is as the name suggests, a database. The ISO does not specify the media of this database. So it is up to you to make it digital or on paper. You will need to enumerate all the activities that have a role in the business process you are working on. When we did that, our first question was how far we needed to get on this asset list. Even the building of the organization could be considered an asset. There is no clear answer to this, and the problem is that audits are so subjective that an evident asset as the building for one auditor could not be for another. However, there is a trick. In our case, we documented everything, including the building and the electric backup plant.
You will need to link a value to each asset you identify. There are two ways: quantitative and qualitative. The quantitative way is very accurate but it is one of the hardest ways I know. You don't need to make this process harder than it is. The good news is that for audit requirements, a qualitative value is enough. You will need to document your criteria and give easy value labels such as low, medium, and high. Of course, you will have documented somewhere what a low value means. The auditor does not have the right to doubt the method you choose as it is the same applied to everything. Remember he is auditing the ISO implementation, not your security levels.
When you finish this step you will output these documents:
- Asset Inventory or CMDB
- Criteria to evaluate all related assets
Conduct Information Security Risk Assessment
If you were asking where is the security work be careful what you were asking for because here it is. After you get your long list of your assets you will need to perform a security risk assessment. The goal of this document is to show how sensible your business is to the loss of any of the identified assets. This document is the angular stone for all the taken decisions.
The first step is to define the method you will use to perform this risk assessment. Please note that you will need to perform a Vulnerability assessment as well. To make things clear, a vulnerability assessment is part of a risk assessment. I will try to explain this by stating first some definitions:
- A thread is an action that will happen. A thread is often a situation, such as blackmailing by a lawyer.
- A vulnerability is a weakness. Usually, you can define it as a noun, such as bad finances. A vulnerability is usually evaluated by measuring the impact, in other words, how much it hurts if it happens.
- A risk is the likelihood that a thread happens by taking advantage of a vulnerability. You can define a risk as a sentence, for example, the likelihood of being blackmailed by a lawyer because of bad finances is low. The risk value is often a number or a quantitative label such as low, medium, or high.
So you will need to perform a risk and vulnerability assessment. In our case, when we did that we downloaded a huge template of linked threads to assets. And we mapped the asset with the given thread. Later, we did a vulnerability assessment over each given asset-thread pair. Remember an asset has one or many threads. Each thread has one or many linked vulnerabilities.
When you finish the vulnerability assessment, you can start evaluating the risk. The risk is evaluated on each asset-thread vulnerability tuple. And as I was saying before, you can make it quantitative or qualitative. The only requirement is you document the methodology and the criteria you use to assign a value. As a quantitative approach was close to impossible, we decided to define the criteria for labels such as low, medium, and high.
At the end of this, you will output the following documents:
- Risk Assessment Methods
- Risk Assessment Report
Just to give you a guide. We did a grid like this for the risk assessment report:
| Asset | Value | Thread | Vulnerability | Impact | Risk |
| Server 1 | High | Lack of power | No backup power station | High | Medium |
| Web site | High | DoS | Excessive HTTP requests | High | High |
| Not optimized caching engine | High | Medium | |||
| Data Leak | SQL injection | Low | High |
This is going to be a huge document. I remember we used a whole server with 48 GB of RAM and 8 CPUs to load the final document.
Prepare the Statement of Applicability and the Risk Treatment Plan
When you get a very long table like the little example I just did, you will finish your risk assessment. So the next step is to decide what to do. Each risk (asset-thread-vulnerability tuple) has a risk value associated, you will need to decide what to do. Among the possible actions you can choose:
- Mitigate: any action that could lower the likelihood or the impact of the given risk
- Accept: you don't do anything, but you acknowledge the possibility of that and you accept the consequences.
- Deny: you ignore it.
The auditor does not have the authority to reject the certification because he might think your taken action is wrong. Again, all is about having records and documentation.
You will need to document in the Statement of Applicability document each one of the controls specified in the ISO 27002. You will need to declare if a control applies to you or not. And of course, you will need to back up your decision using the awesome risk assessment you just did.
The other document, the risk treatment plan, is just a document where you specify how are you going to respond to the given risk. To make things easy, you can add a column to the risk assessment specifying the control type and control implementation you will do.
When you finish this part, you will output two documents:
- State of Applicability document
- Risk Treatment Plan
Other Documents
Before you start running your first iteration, there are some documents that any management system needs, but they are not very clear when to do them. Many of them are inherited from the ISO 9000, so it would be a good idea to read it and take those documents from there. Some of them are:
- Internal Audit Procedure: you will need to run an audit, and document how the audit will be done. When you do this audit, you will need to save all the records.
- Preventive Action Procedure: in the common operation, if something is detected before anything happens, a preventive action procedure should be run. As far as I remember this was one of the documents taken from the ISO 9000.
- Information Security Metrics: This document talks about how are you going to measure the effectiveness and accuracy of your control. In other words, how are you going to calibrate a given control to be sure there are no false positives or false negatives?
- ISMS Operating Procedures: this set of procedures talks about how to operate the ISMS. The people, roles, operators, and what to do daily. It is not how to operate your business, there is a thin line and sometimes it is a little confusing. The idea is this is a manual where operators go to review how to react when a security breach happens. This document is very long, and some topics you may cover here are awareness, training, testing, reporting, etc.
- Records Control Procedure: this document is like the Document Control Procedure, but it applies to records instead of documents.
- Corrective Actions Procedure: after the first cycle, usually after the audit, the corrective action procedure indicates how are you going to deal with the topics the audit is showing.
Develop your ISMS Implementation Program
To get a certification for the first time, the auditor will ask you for records of your ISMS operation for at least 3 months if I remember for good. You will need to run at least one cycle of the PDCA cycle to generate the needed records. Among the many things you will need to do (depending on your environment), at least you need to:
- run an internal audit
- run your preventive action procedure
- run your corrective action procedure
- generate documents and records of all procedures you run
When you run your ISMS you will start generating records, these records and the way you apply the procedures you defined are the golden cow to get the certification. Adding this to the pile, you will generate:
- Security logs,
- Compliance and audit reports
- Records of awareness and training
Run for at least 3 months your ISMS, and you are ready for a visit from the auditor. I will talk later about my experience on the audit.
";