Do I have to change my Risk Assessment Methodology for ISO 27001:2013 ?

The first question that come to the mind while planning to upgrade the certification to 2013 version is on the Risk Assessment. It is true that the new version of the standard is transforming to a risk based approach, but at the same time there is a flexibility provided as well.

The 2013 version of the standard is not mentioning how to perform the risk assessment. The clause 6.1.2 of the standard mentions on the risk assessment to be performed & 6.1.3 mentions on the risk treatment.  The major changes to the risk Assessment in ISO 27001:2013 compared to ISO 27001:2005 are;

  1. You can define a methodology for risk assessment based on your choice, whereas in 2005, you had a definite mandate on how to perform the Risk Assessment
  2. In 2013 you need to identify the risk owner for each of the risk, whereas in 2005 there is no mention on the risk owner
  3. 2013 require the risk owner to accept the residual risk and approve the treatment options, 2005 requires management to accept the residual risk.
  4. Unlike 2005 , 2013 does not explicitly mention on risk treatment options like avoiding, accepting ,transferring the risk and implementing controls from Annexue A. You have the flexibility & freedom to choose your own option for risk treatment.
  5. 2005 required risk assessment to be established as a part of the ISMS Policy (Ref: 4.2.1 b), however 2013 requires a risk assessment approach to be defined, but not at ISMS Policy level.

ISO27001:2013 gives the freedom & flexibility to choose our own methodology & approach for risk assessment. If you feel that the current methodology holds good, you can always continue with it by incorporating points 2 & 3 mentioned above.


ISO/IEC 27001:2013 : Insight on Operations Security & Communications Security Domain


The most popular standard for information security management system, ISO/IEC 27001: 2005 is revised after eight years and officially released on October 1st 2013, replacing it with ISO/IEC 27001: 2013.

All the readers who have gone through the revised standard must be aware of the change in structure and the changes made to Annexure A of the standard. In this blog, I would like to provide insights on couple of controls in Annexure A of the revised standard.

To begin with, domain ‘A.10 Communications and operations management’ which was there in the earlier version of the standard has been divided into two separate domains in the 2013 version of the standard i.e. ‘A.12.Operations Security & A.13.Communications Security’. This separation of domains helps the organization to concentrate on & implement specific controls which are applicable to respective domains.

Now let us try to understand this intend for separation of domains:

A.12 Operations Security


A.13 Communications Security

A.12.1 Operational procedures and responsibilities


A.13.1 Network security management

A.12.2 Protection from malware


A.13.2 Information transfer

A.12.3 Backup



A.12.4 Logging and monitoring



A.12.5 Control of operational software



A.12.6 Technical vulnerability management



A.12.7 Information systems audit considerations




The objective of ‘A.12.Operations Security’ domain is to help the organizations to put in place appropriate controls to ensure that day to day operations of an organization are carried out in a controlled and a secure manner, which includes documenting operating procedures, ensuring changes to information assets are carried out efficiently, the information assets are protected from malware and other threats & vulnerabilities, controls to ensure backup is performed effectively to ensure timely availability of information, logging and monitoring of user activities and ensuring continuous improvement through Information systems audit & mitigations.

‘A.13.Communications Security’ domain stresses on security of the network and network services through controls such as segregation of networks, network service level agreements and other network controls which are applicable to the environment. Along with ensuring network security, the domain also guides the organization in safeguarding the information in transit through controls such as policies and procedures for information transfer, agreements to ensure secure transfer of information between the parties involved, controls specific to electronic messaging etc.

In a nutshell, A.12.Operations Security helps the organization to put in place those controls which are specific to Operations of an organization. A.13.Communications Security helps the organization to put in place the controls to ensure security of network and the information which is in transit.

The above abstract is documented as per my understanding of the revised standard, Request the readers to provide their inputs and views on the subject.

Documentation Requirements of the new standard (ISO/IEC 27001:2013)

The much awaited new standard ISO/IEC 27001:2013 has been released on 25th September. This is the first revised change that has been made to the standard in 8 years. The new standard is more focus and aligned to the organization objectives. As this buzz go on in the industry there is also much confusion over the implementation on this standard. I would like to put forth my comments on the documentation requirements from the perspective of the new standard released.

Even though there are some of the mandatory documents required as per the new standard ISO/IEC 27001:2013 such as (IS Policy, IS Scope, etc.) nothing much has changed pertaining to the old standards document requirements. One needs to maintain all the IS procedure documents and records of implementation as evidence. Hence i have mentioned a list of documents which I feel is required for an organisation to have to implement Information Security. Also please note that this list should not be limited to the only documents required, and the organization should maintain other documents as per the environment of information security implementation.

1)     IS Policy

2)     IS Scope

3)     IS Objective

4)     Risk Assessment Process

5)     Risk Treatment Process

6)     Risk Assessment & Treatment Reports

7)     Statement of Applicability

8)     Internal Audit Procedure

9)     Corrective Action Procedure

10)   Information Security Metrics

11)   Document Control Procedure

12)   ISMS Operating Procedures

13)   Communication Procedure

14)   Contractual & Regulatory Requirements

15)   Security Incident Management Procedure

16)   Acceptable Usage Policy

17)   Information Classification & Handling Procedure

18)   Documented Records

19)   Security Roles, Responsibility & Competency document

20)   Management Review Records

Probability & Likelihood in Risk Assessment

There was a concern raised in one of the Audit that ‘Probability’ keyword should not be used in the Risk Assessment because it is a mathematical term and if we use the term, then the value should be between 0 & 1. To elaborate further, if we use the term ‘Threat Probability’ then the value has to be based on the mathematical term.

However, ISO 27005:2008 clearly states (Section 3. Term & Definitions, sub-section 3.5 .risk estimation – Note 2) that ‘likelihood’ is used instead of ‘probability’ in the standard. This gives a clear indication that for the standard, probability & likelihood is the same and we may not worry about the mathematical meaning.

So what about your risk assessment methodology?, are you using the word ‘Probability’ or ‘Likelihood’. In my viewpoint both can be used as the standard clearly says that they are the same, hence we should look at the English meaning rather than the mathematical meaning while using this in the risk assessment.

Is RPO (Recovery Point Objective) specific to data?

Terms such as RTO, RPO and MTPD are thrown up during any discussions around Business Continuity management (BCM) and in general about Risk management.  I often wondered how well the term RPO is understood and agreed in terms of the definition and context.

Let me narrate a unique experience of mine that could prove to be of immense use to at least some of the readers:


My quest for understanding RPO in a logical, contextual and consistent fashion started few months ago. During one of our internal ‘brainstorming’ sessions, a colleague pointed out that:

  • RPO is not or should not be specific to, and limited to data alone and
  • itshould be applied to various other aspects like knowledge, process, and activity etc.

At that moment, I couldn’t agree with him. To be honest, I was a bit confused and what I have read, been taught and practiced all the while was being challenged.

I had been feeding my brain with the notion that RPO helps in determining “data loss tolerance“.  After this debate, somewhere in the back of my mind, I was skeptical that I may be (or rather what I understood so far might be) wrong.

My colleague’s thoughts and arguments prompted me to research further on the topic. I did a quick search on Google. Top 10 results including Wikipedia were in my favor. All these sites were voicing more or less the same opinion: i.e. RPO refers to “data recovery” or “data loss”.

But, I was not convinced, andcontinued my research to understand RPO better. With an open mind, I started going through definitions provided by global standards and guidelines such as BS 25999, ISO/IEC 22301:2012, BCI GPG 2013 and PAS 56 etc.

Examples of what I found:

Definition for RPOas per ISO/IEC 22301:2012:“point to which information used by an activity must be restored to enable the activity to operate on resumption”.

According to PAS 56, the definition for RPO: “The point in time to which work should be restored following a business continuity incident that interrupts or disrupts an organization”

Strangely, none of the above has referred anywhere that RPO is specific to data or rather sited any references to data. Slowly and surely, I reached a state where I had to correct my understanding of the definition of RPO.

This is what I learned:

ISO/IEC 22301:2012 definition of RPO do stress on “information used by an activity”. However, in my opinion, Information is a very broad term. Information can be in various forms such as data, knowledge, processes, activities and actions.

Hence, during RPO analysis it is important that we consider all forms of information, rather than limiting to data alone.

Let me site an interesting example, (which I have come across during my net research – with due credits where applicable) supporting my understanding of RPO, and conclude this discussion:

Let us assume that a Chef/Baker is preparing a cake.

He completes all the initial activities such as collecting of raw material, cleaning, measuring and mixing. His next activity is about to bake the mixed content in the oven for an hour.

At this instant, power fails for 4 hours.

The Chef would not just leave the cake to continue to cook after power is restored but would put fresh mix in the oven before continuing. So in simple terms his/her Recovery Point Objective was the ‘Beginning of baking’ and he need all the know-how, specific requirements for the cake, raw materials, the equipment’s etc to be recovered/restored, in order to continue with his ‘business’.

The same logic frequently applies to manufacturing processes such as producing food products and drugs.

And yes, I couldn’t find”data” in the above example? Did you?

Please share your thoughts.

Understand the domain and then use a framework or Standard:

Frameworks and standards are established to help improve specific domains. One needs to understand the context and specific aspects of the domain, in order to appreciate and usefully adopt frameworks and standards, and derive value out of them.

As an example, if anyone wants to really understand the role and value of ITIL®, one has to analyze the context as below:

  • Services are delivered by a provider and those services facilitate certain business outcome for customers, thus delivering valueService Management, ITSM and ITIL
  • How the service manages the lifecycle of each of the service delivered by them is the domain of service management. In other words, every service provider is doing Service management.
  • When the business outcome facilitated is through use of Information technology, the related services are called IT Services and the management of those services, IT Service management or ITSM.
  • To establish an IT Service management system and continually improve it – organizations can adopt frameworks such as ITIL or Standards such as ISO/IEC 20000.

Unfortunately most of the practitioners in the industry try to get into the domain understanding in just the reverse order:

  • Trying to understand IT Service management domain through ITIL® ( or through ISO/IEC 20000) and then
  • Trying to understand Service management domain through the lens of IT Service management.

The biggest drawback of this approach is: One is trying to analyze a larger area through a smaller eye piece with restricted view.

In fact, as the pyramid above shows, one who is in the ITSM domain has a larger portion of practices, best practices and knowledge available in the Service management domain; than a much smaller scope of ITIL®.

This in no way of taking away the value of ITIL® as a framework for ITSM:  ITIL® provides specific set of practices, presumably crystallized from the global practices of ITSM (and may be even adopted from generic service management). This specificity makes it easier to adopt into an organization’s IT Service Management.

When one looks at ITIL® as a best practice Body of Knowledge (BOK) with a generic grasp of Service management and IT Service management domain and context, the adoption becomes more rational, useful and beneficial to the organization.

As mentioned above: Service management, ITSM and ITIL are taken as examples here, to demonstrate a larger problem in adoption of frameworks and standards in the industry, more specifically visible IT Industry.

Similar bad practice approaches are visible in many areas such as: Continue reading

A Disgruntled Employee and A False Sense of Security !

It is a common conception within the information security community that an organization is more exposed to internal threats rather than threat from external sources. In fact, it is a truth which most of the organizations find hard to digest and invest a major share of the annual budget on securing the information assets of the organization, rather than educating and making the employees aware of the importance of best security practices that needs to be exercised in their day to day activity and paying more attention to the internal network security.

The real life incident explained below gives a clear picture on how a disgruntled employee can compromise the security of the information assets of an organization using easily available tools in the internet.

  • The user surfs the internet from a cyber café in search of Key Logger software and finds Key Logger software which is of limited size, so that it can be send over the E-mail.
  • The user renames the software as “Purchase Order” before sending it to his official mailbox, so that the spam filter configured in the mail server does not detect the attachment.
  • The user receives the software in his official mailbox, bypassing the security controls implemented in the E-mail Server and he downloads the Executable file on his desktop.
  • The antivirus installed on the system detects the malware and prevents the installation.
  • Since the user is part of a domain with limited rights, to install the software he logs out of the domain and he login as local administrator. Since the system is running on Windows XP, it doesn’t enforce mandatory password for local administrator account. The user disables the antivirus software and  installs the malware in the system by login as local administrator.
  • After successfully installing the software he login backs to the domain as a normal user and starts the key logging functionality of the software.
  • The user with the objective of obtaining the Domain administrator password gives a call to the systems support dept. on the pretext that he requires to install the java software.
  • The system support person copies the java installer on the user system and using the ‘run as administrator’ option, runs the executable file and installs the software in the user system.
  • The user opens the key logging software and to his delight the password of the domain administrator is displayed in clear text. Now this makes the normal user, the owner of the Windows Active Directory Domain.

What actions the user could have performed after obtaining the Domain Administrator password, I am leaving it to the reader’s imagination. This is not the case with all the organizations, most of the organizations don’t user domain administrator password to install the software.

How this incident could have been prevented ? Continue reading