ISO 27001:2013 standard benefits, implementation tips and security controls

What are the key changes in the ISO 27001: 2013 revision, as well as the benefits?

The key benefit of this new ISO 27001 is that it can be more easily implemented in smaller companies – a greater degree of flexibility is allowed, and a smaller number of mandatory documents is needed. For instance, the risk assessment process is simplified, and there are no more requirements to document procedures like internal audit or corrective action.

What are the new security controls and how does the 2013 revision deal with new risks?

First of all, the number of suggested controls in the 2013 revision has actually decreased from 133 to 114 – therefore, it is easier now to find the controls that are really needed for a particular risk. The new controls are these: A.6.1.5 Information security in project management, A.14.2.1 Secure development policy, A.14.2.5 Secure system engineering principles, A.14.2.6 Secure development environment, A.14.2.8 System security testing, A.16.1.4 Assessment of and decision on information security events, and A.17.2.1 Availability of information processing facilities.

How much new mandatory documentation is there, and for certified companies is there lots of work involved in implementing these?

As I mentioned previously, there is actually less documentation required. If a company is already certified against the old 2005 revision of ISO 27001, only about 10-20% of the existing documents will need to be changed, and some of the documents may now be deleted. Therefore, the effort to make this transition to the 2013 revision won’t be too big.

How to make a transition from ISO 27001 2005 revision to 2013 revision

Transition steps

The easiest way to make the transition to the 2013 revision is by following these steps:

1) List all interested parties. You should list all your stakeholders (the persons and companies that can influence your information security or can be influenced by it), and their requirements. If you already listed all the statutory, regulatory and contractual requirements according to the old A.15.1.1 control, then you have already done half of your job.

2) Define interfaces in the ISMS scope. According to the 2013 revision, as part of your scope definition you need to identify the interfaces between the activities made by your organization and the activities that are performed by third parties.

3) Align ISMS objectives with the company’s strategy. 2013 requires you to determine whether the information security objectives are compatible with the strategic direction of the company.

4) Changes in the top-level policy. The top-level policy shouldn’t be called “ISMS policy” anymore, but rather “Information security policy.” It doesn’t have to include requirements like alignment with strategic risk management, nor the criteria for evaluation of risk.

5) Make changes to your risk assessment process. First, you need to identify risk owners for each of your risks; second, you don’t need to use the methodology based on identifying the assets, threats and vulnerabilities anymore, so if you wish you can identify your risks in some other (simpler) way; and lastly, you need to identify all the outsourced processes and decide on how to control them – this is best done during the risk assessment process. Accordingly, you need to change both your Risk assessment methodology, and your risk assessment results.

6) Identify status of controls in Statement of Applicability. This is a small change, but significant from an implementation point of view – in the SoA for each control you must indicate whether it has been implemented or not. Of course, you will need to change the structure of the controls in the SoA, as specified in step 11).

7) Obtain approval from risk owners. According to the new revision, you must ask the risk owners to approve your Risk treatment plan and accept your residual information security risks.

8) Plan the communication in a systematic way. You should determine a process for who will communicate to whom, what will be communicated and when. This includes both internal and external parties.

9) Decide what to do with your management procedures. The requirements for preventive actions do not exist anymore (preventive actions basically became a part of the risk assessment process), so you can decide whether to delete that procedure or not; there are no more requirements to keep the remaining management procedures (Document control, Internal audit, Corrective action) documented, so you if you wish you can delete those procedures as well, but you must maintain those 3 processes even though they are not documented.

10) Write new policies and procedures. If you haven’t already written the following documents, you will have to do so now because if you selected related controls as applicable, writing a document became mandatory: Secure system engineering principles (control A.14.2.5), Supplier security policy (control A.15.1.1), Incident management procedure (control A.16.1.5), and Business continuity procedures (control A.17.1.2).

11) Reorganize your controls. Annex A got mixed up quite a bit, but essentially most of the old controls remained, while only a handful of new ones appeared: A.6.1.5 Information security in project management, A.14.2.1 Secure development policy, A.14.2.5 Secure system engineering principles, A.14.2.6 Secure development environment, A.14.2.8 System security testing, A.16.1.4 Assessment of and decision on information security events, and A.17.2.1 Availability of information processing facilities.

12) Measurement and reporting. Requirements became much stricter in the 2013 revision: (1) the objectives should be set in a measurable way (if possible) in order to enable easier measurement (clause 6.2 b); (2) all activities to address risks and opportunities must be evaluated (6.1.1 e 2); (3) when planning how to achieve information security objectives, it must be defined how the results will be evaluated (6.2 j); (4) it must be determined what will be monitored and measured, when it will be done, who will do the measuring and who will evaluate the results (9.1); and (5) the responsibilities for the reporting of the ISMS performance must be clearly assigned (5.3 b).

Practical application of Semantic Web and build applications in your organisation

Semantic technologies allows your to provide meaning to data that is machine understandable. Semantic Web is very well suited for data integration tasks, and building smart data, which is an issue that a lot of big organizations face these days.

They can help you separate your business logic from your codebase by encoding it into an RDF graph; which can help non-programmers perform complex information processing tasks with the help of the computer, which can understand the semantics.

But, like anything else, Semantic technologies are not a silver bullet which will fix all your problems.

You might want to check out the W3C’s official use cases for semantic technologies. There are several good descriptions of projects there which should give you an idea of what other folks are doing with semantic technologies.
Generally, the “semantic web” is a buzzword and therefore is quite unspecific. The basic idea is, to not only connect documents (like you connect websites by using hyperlinks) but to connect semantic concepts. And not only to connect them, but to specify the kind of connections in a more specific way.

And how you do that is totally up to you. There are some technologies that are closely connected to the term “semantic web” like RDF and OWL. You also might to look for the freeware “Protege” which provides some tutorials (Pizza Tutorial). After you have done that, you will have a clearer impression of what you can do with it.

To get another impression what you can do with it, you might want to look at:

But to be honest: What you can actually do with it is still beeing researched. There are quite some interesting projects out there, but you are welcome to think of new applications.

There are several parts of the “Semantic Web” that are useful to distinguish:

  • RDF, RDF/S and related technologies
  • OWL and related technologies
  • Linked Data

RDF and RDF/S represent the core of the Semantic Web. It is relatively easy to understand and easy to use. RDF and RDF/S provide you with minimal semantics that you can use to describe concepts used by your organization. Perhaps about the only practical reason you would use it instead of traditional RDBMS is that you need to represent concepts that frequently change and/or evolve. That is, a RDBMS schema would be too rigid and constraining for your purposes; you need something more flexible but still with a schema (i.e. not a schema-less document store for example). For example, a bank where everything is standardized and all schemas are set in stone wouldn’t use RDF/S (or OWL). On the other hand, RDF/S is ideal for knowledge graphs such as DbPedia where the schema constantly evolves.

OWL is a different beast. It provides you with richer concept modelling facilities than RDF/S. It can be useful if you need to define a precise structure of concepts (an ontology) and if you need to verify that the structure is without contradictions. OWL is not so easy to use, and it’s not so easy to understand even for people relatively knowledgeable about the Semantic Web (RDF/S has it’s quirks too but not as much) – the problem is often that of your intended meaning vs. the actual meaning of the OWL expression you use. Also, Some people would say that using OWL is a bit like using blank shells in a gun because you cannot trust your gun to not to shoot yourself in the foot: OWL puts restrictions on what concepts you can express so that reasoners (guns) can deal with it reasonably (not to shoot you for example by never finishing computation). That may be a good thing but it hinders the ease of expression.

Linked Data could be characterized as a movement within the Semantic Web community to make the Semantic Web more practically useful. It shifts focus from knowledge representation (theoretical RDF, RDF/S, OWL) more to their actual applicability on the Web. It stresses the need for using dereferenceable URLs, links between different data sets, correct publishing.

All in all, if you model your data and publish it as Linked Data then thanks to RDF/S and OWL you have the opportunity to create clever applications that were not designed directly for the schema of your dataset but still are capable of using it usefully. A good example how this could be achieved is the Freebase Metaschema: for example your dataset could use properties such as (an actor) “actedIn” (a movie), (an author) “wrote” (a book) and both “actedIn” and “wrote” would be “marked” as some kind of specialization of the property “contributedTo”. So if your application knows how to handle “contributedTo” properties then it will be able to handle even newer datasets to which you add a new property such as “directorOf” and also “map it” to “contributedTo”. The whole Semantic Web machinery is basically aimed at making this possible and at making it general, expressive, and useful.

RDF 1.1 is a W3C Recommendation

World Wide Web Consortium (W3C) has announced that RDF 1.1 has become a “Recommendation.” RDF 1.0 was published in 2004.Over the years, the RDF Working Group has published a set of eight Resource Description Framework (RDF) Recommendations and four Working Group Notes.

Whats new in 1.1?

identifiers are now IRIs (“Internationalized Resource Identifieers” — they were “RDF URI references” before).
language-tagged literals now always have the rdf:langString datatype
simple literals, i.e., literals without datatype do not exist anymore
introduction of datasets (difference to SPARQL is that graph name can also be a blank node)
a couple of new XSD datatypes are now compatible with RDF, namely xsd:duration, xsd:dayTimeDuration, xsd:yearMonthDuration, xsd:dateTimeStamp
new rdf:HTML datatype.
semantics uses the notion of “recognized datatypes” instead of a “datatype map”.