Wednesday, 27 September 2017




Failure Points when building an ISMS.




What are the likely causes of an organisation failing in its quest for Certification, or the maintenance of an existing Certification, to ISO/IEC 27001:2013 [Information Security Management System (ISMS) – requirements]?

The International Standard, ISO/IEC 27001:2013, has an extraordinary amount of power; it simply needs a little bit of imagination and true desire to bring it together.

Yes, there are many benefits to Certification, not least of which would be providing an assurance (confidence) to prospective clients/customers that the organisation has put in place processes to manage the risk of a loss of confidentiality, integrity, and availability to information and data. 

In my opinion, I believe there to be a whole heap of confusion out there. This confusion is not necessarily appreciated as being such, but it is there. The march of the cyber-prefix has not helped the situation. As important as cyber security is, it is only a part of the whole picture. And it is the whole picture (within a given scope) that the Certification addresses.

It is this whole picture (within a defined scope) that I am addressing. This is not an exhaustive list.

  • One of the first failure points is the inability to interpret exactly what the standard is asking of us.
  • The second failure point is vacillating between placing the ISMS in either IT or compliance. Parts of it may sit in both of course, but then, perhaps it does not.  Cyber security may well sit within IT Security, but it is related to, wait for it, compliance. However, the real point the standard makes is about, competencies.
  • The next failure point and related to the second, is placing the implementation of the standard into hands with little or no experience of the information security environment.  To be frank, a three-day implementation course is not going to do the job either.
  • The next challenge, related to the first, falls under the simple heading, risk. Simple heading yes, but oh my, does it conjure up all sorts of weirdness. Perhaps it is worth pointing out, risk is not a mathematical equation (yet), but is the effect of uncertainty on objectives (ISO Guide 73:2009). This is not just risk, but information security risk management with the objective of managing the protection of information and data. The standard confirms this right from the off by stating that the organisation will manage: risk and opportunities to the intended outcome of the ISMS and; the risk to a loss of C/I/A of information (within the given scope).  Thinking seriously about that last statement what does it mean?  The organisation must know what information sits within the scope of its Certification. For those with GDPR on their minds (and who hasn’t) there is a requirement to know what PII is in play; how it flows, and to have knowledge of the varying likelihood and severity for the rights and freedoms of natural persons. The whole risk process, if undertaken anywhere close to the requirements of the standard, should now illuminate a vast field of interrelated dots. If not, those dots will remain invisible, and the bigger picture will be lost.
  • A statement of applicability (SoA), being an output of the entire risk process is a requirement that documents: all the necessary controls, determined through the risk process; justification for inclusion (modifying the risk), their status, and justification for any exclusions of a control (it may not be relevant, or perhaps your selection of a control, not outlined in Annex A, suites you better).  The bottom line is that getting information security risk management wrong, then your SoA will be a mess. And, if you have no information (asset) register then you have failed to manage their risk, in essence you have failed at the fundamental basics that the rest of the ISMS sits on and going forward you will fail with GDPR.

There is good news, of a sort. ISO produces a series of guidance documents that would enable any organisation to implement an effective, efficient ISMS. Documents that would enable you to truly understand and realise the benefits of having an ISMS.

N Landman
KanSecurity Ltd
contact@kansecurity.com

Wednesday, 18 January 2017

Compliance is not security; or is it?



Compliance is not security; or is it?

There is a widely-held (anecdotal) view that compliance is not security!

Within the context of Information Security (and Cyber security) the theory is that to meet the criteria of a 3rd party standard (PCI DSS, ISO/IEC 27001:2013 et al.) or, internal standards/specifications, the organisation will have successfully completed quite an arduous journey. To that end, and assuming a successful assessment against the criteria, the organisation is compliant (to whatever standard or indeed legislation) and thus security is likely to be in place. Of course, there will be residual challenges to consider.

On the other hand, if the thought of completing such an arduous journey puts organisations off, and the solution is to simply build a few folders full of paperwork with any assessment simply being a review of the management system to achieve compliance, then likely security is not in place.

So, it is all about the journey the organisation is prepared to take to meet the criteria to become compliant. Therefore, the basic challenge the organisation must face is an acceptance that the journey they are going to take is going to be quite demanding, and full of ‘light-bulb’ moments.

Another challenge the organisation will face is a realisation that no one-part of the system stands in isolation. What the organisation will discover is that there are going to be links that join every single part of the system together, and that a change in one component is likely to have a consequence on others.

Now, there is considerable discussion in various forums that warn of the need to be compliant to the new EU Regulation, GDPR, by close of 2017 (ready for May 2018). What then will it take to become compliant to this Regulation? One of the components within the Regulation that should sound familiar is, risk. Within the recitals and articles of GDPR, risk is mentioned some 75 times, and that number does not include privacy impact.

Keeping GDPR and risk in mind, turn now to ISO/IEC 27001:2013. There is a set of criteria under clauses; 6.1.1 (Risk to ISMS), 6.1.2 (Information Risk Assessment), 6.1.3 (Information Security Treatment), 8.2 (Operational Information Security Risk Assessment) and 8.3 (Operational Information Security Risk Treatment), needing action by the organisation. To be compliant to the ISO, the organisation must prove that these criteria are being effectively met.

To achieve (in part at least) the requirements of the above criteria there should be knowledge of: all data and related information assets; owners of those assets; a classification for those assets; knowledge of all associated ICT and non-ICT assets; owners of the associated ICT assets; users of all assets (internal/external); and knowledge of where the data and information assets can be found.

Now join the dots, bearing in mind no-one part of compliance obligations stands in isolation. To be compliant to one element of GDPR there is a need for a risk and privacy impact processes including treatment, to be in place. To be compliant to the example (above) criteria of ISO/IEC 27001:2013 there needs to be risk processes and treatment to be in place. The GDPR focus is the protection (C-I-A) of personally identifiable information (PII) and or data (PID), and the focus of 27001:2013 is the protection of information, be that PII/PID, intellectual property or other sensitive/critical information and data.

Protection, or security, must be in place (at least as far as it can be) and that means the implementation of technical controls, physical controls, and managerial/administrative controls in response to the unacceptable levels of risk.

Join the dots again; the GDPR states that supervisory bodies (ICO) should be informed of a breach of PII within at least 72 hours (paraphrased). Within ISO/IEC 27001:2013 there are a set of criteria centred on incident management. Is there a relationship between the GDPR and 27001:2013?

It does not matter if you are a highly skilled analyst sitting in the SOC or you are tasked with implementing GDPR or ISO/IEC 27001:2013 or even PCI DSS; you are all joined at the hip with an objective to protect the sensitive and or critical data and information, and acting when things go wrong.

If you are compliant (to legislation, regulation, standards), and continuously trying to improve upon what has been achieved, then theoretically you have taken the journey with eyes and minds wide open, and given all that, security (with an understanding there will be residual) is likely to be in place.


So, is compliance security?

N Landman

Sources: ISO/IEC 27001:2013, ISO/IEC 27002:2013, ISO/IEC 27032:2012, GDPR

Friday, 6 January 2017

ISO/IEC 27000 Family



What value do the supplementary documents, within the ISO/IEC 27000 family, have when designing, developing, and implementing your formal ISMS with the aim of meet the criteria set out within ISO/IEC 27001:2013?

The answer depends upon the culture and attitude of the organisation. If this is simply a tick-box exercise your external auditor will no doubt find you out. If, on the other hand, the organisation is going to take the matter serio
usly, then the guidance and sector based documents found within the 27000 family (and elsewhere) will become an invaluable resource.

As per my earlier blogs treat the ISMS as being exactly what it is; a management system (one) that is focused on information security (two).

ISO/IEC 27001:2013 is split into two parts: the clauses – management system, and Annex A (statement of applicability/control objectives/controls – information security).


The table below shows some of the relationships between ISO/IEC 27001:2013 and its guidance and sector related documents:

Standard
Part
Guidance
Remarks
ISO/IEC 27001:2013
Clauses
ISO/IEC 27003:2016
Information security management system implementation guidance
ISO/IEC 27005:2011
Information security risk management
Annex A
ISO/IEC 27002:2013
Code of practice for information security controls
ISO/IEC 27010:2015
Information security management for inter-sector and inter-organizational communications
ISO/IEC 27004:2016
Information security management Monitoring, measurement, analysis, and evaluation
All
ISO/IEC 27000:2016
An overview and language used within ISO/IEC 27001:2013
ISO/IEC 27007:2011
Guidelines for information security management systems auditing
ISO/IEC 27009:2016
Sector-specific application of ISO/IEC 27001


Okay, the down side to the above will be the cost of these documents. But implementing an ISMS is a serious business and if done correctly it will take more than 30 days and a bunch of templates.  Why? The company is developing an assurance mechanism to say to its stakeholders that it is managing the risk to sensitive and or critical information and data and their associated information systems. 

In truth, the above table is only a starter as there are many other documents that will be of value when implementing controls and these tend to be sector specific such as Public Cloud service providers, financial sector, telecommunications sector and so on.

It does not end there. There is considerable discussion about EU Regulation 2016/679 aka, GDPR. Where does this sit in the great big scheme of things. It is about ‘risk’ (mentioned 75 times in the regulations). How about ‘encryption’ and that interesting topic called key management? What about incident management or even business continuity? Let us not forget asset management (something way too many organisations forget about or misinterpret) or indeed records management. Those suppliers must also be considered; how do they meet your security assurance expectations?

Simple example:
·    In ISO/IEC 27001:2013 A.13.1.3 there is an objective/control – segregation within the networks. This objective/control is expanded (code of practice and implementation guidance) in ISO/IEC 27002:2013, within 13.1.3.  This is further expanded in ISO/IEC 27004:2016 (monitoring, measurement, analysis.) at B.26 by asking you to look at firewall rules, especially those that are unused and how this detail should be reported and how often.  A firewall and its rules are a control that will have been implemented based upon the output of a risk assessment process. An independent (but internal) audit should be able to report objectively on whether the criteria are being met.

·    In the above example 5 documents were used:
  1. ISO/IEC 27001:2013 – Requirements;  
  2. ISO/IEC 27002:2013 – Code of practice;
  3. ISO/IEC 27004:2016 – Guidance;
  4. ISO/IEC 27005:2011 – Guidance;
  5. ISO/IEC 27007:2011 – Guidance.

I have said previously in other blogs that ISO/IEC 27001:2013 is a powerful beast and its power comes from its simplicity and generalisations, especially within Annex A. The down side to this simplicity is that many will fail to interpret exactly what is needed, and so this is when the supplementary documents come into their own and thus the eventual realisation of the power of ISO/IEC 27001:2013.

Nigel Landman


For further information:


























Wednesday, 30 November 2016

This is gonna be controversial



This is gonna be controversial

I apologise now! There are two areas of concern:
  1. Are "consultants" for ISO 27001:2013 actually experienced in the Information and Cyber Security domain or, are they really good at building a folder full of documents to satisfy the management system side of life?
  2. Are the auditors employed by Certifying Bodies (CB) well and truly up to speed with all the many challenges of current information and cyber security or, are they just pretty good at auditing the management system side of life?
I suppose the other area that should be questioned is; do I actually know what the heck I'm talking about when it comes to ISO 27001:2013?
To address the latter point; I know what ISO 27001:2013 is about.  In fact I have broken my own golden rule in calling the standard ISO 27001:2013 and not, ISO/IEC 27001:2013. 

I know too that that the standard is a management system with a focus that is centred upon information (and to that end, data).  I'm also comfortable with the Annex SL directive from ISO. I'm also aware that ISO does NOT mean the International Standards Organisation but rather:
Because 'International Organization for Standardization' would have different acronyms in different languages (IOS in English, OIN in French for Organisation internationale de normalisation), our founders decided to give it the short form ISO. ISO is derived from the Greek isos, meaning equal. Whatever the country, whatever the language, we are always ISO. (http://www.iso.org/iso/home/about.htm)
 Another point that I'm only too well aware of is that the standard should NEVER be used in isolation.  To achieve what is required the supporting guidelines and sector based standards, and indeed many that do not originate from Sub-Committee 27 (SC27) and its Working Groups (WG), should be identified and considered when designing, developing, implementing and continuously improving a formal Information Security Management System (ISMS).

Having recently reached yet another milestone in my 6th decade, I am sufficiently grey haired enough to have become somewhat weary over the repeated cries of:

  1. The governing board need to take this more seriously;
  2. Insiders are one of the biggest threats;
    1. Middle management politics,
    2. Users (including the CEO) going clicky clicky on unknown links.
  3. Users need training;
  4. Why are breaches still happening, etc.  
This brings me nicely back to my original questions. A formal ISMS that is audited against the requirements set out in ISO/IEC 27001:2013 is NOT a simple exercise in ticking a box.  What it is, is a public statement of assurance that the organisation and all those who sail and are associated with her take the matter of risk to information and data seriously; that measures to manage the levels of risk have been put in place, and the means to continuously improve what is, has been, and will in the future be done, are also in place.

If any elements of the previous paragraph where in place, would the same repeated (ad nauseam) questions be asked; has the management system consultant understood the requirements of a formal ISMS and control objectives and finally; has the external auditor asked the technical questions pertinent to the technology and innovation of 2016 that sit within the control objectives of Annex A?

Hmmm...I do wonder!!

Final question: Many organisations have achieved Certification to ISO/IEC 27001:2013 - why then is that fact not sitting front and centre on the website?  How often do you have to search high and low on a website looking for the wretched thing? Hey organisations, you have gone through the pain of Certification why not let people know about it - it is part of an assurance mechanism after all.   Enough said.

NRL

contact@kansecurity.com

www.kansecurity.com





Thursday, 3 November 2016

I don’t understand why you don’t understand


In theory, a 3rd party auditor will be looking for evidence of Planning under clause 6 of ISO/IEC 27001:2013 that must address the following 2 points:
  1. Information security risks – in other words, those risks that are directly related to the loss of C-I-A of information (and processing facilities) within the identified scope of the ISMS, and
  2. Risks that relate directly to the intended outcome of the ISMS but that are NOT, information risks. 
What happens in practice however, is an entirely different matter. That said, an organisation should be able to prove compliance by showing that risk has been managed in two ways:
  • 6.1.1 - The intended outcome of the ISMS and for example;
    • Management engagement,
    • Opportunities – continual improvement of the ISMS, and
  • 6.1.2 – Information risk management (C-I-A)
    • Criteria for acceptance
    • Risk Identification, Analysis, Evaluation,
    • Treatment
    • Ownership 
So; does the evidence show that you are managing the risk to the ISMS as well as managing the risk to the information assets?

A simple case in point:
  • Is there likely to be an inventory of information assets, as well as the ICT assets that support the information assets?
    • If the answer is yes, then there is a likelihood (perhaps) that both 6.1.1 and 6.1.2 etc., are being met. On the other hand;
    • If the answer is no, or it is a work in progress (the usual story), then the likelihood is that the ISMS is at risk as well as there being weak management of information risk; all leading to non-conformance of the requirements to ISO/IEC 27001:2013. 
More importantly perhaps is this question; why does common sense not kick-in? An Information Security Management System has a focus that is the security of information. If there is neither a list of information (and indeed, data) assets then quite clearly understanding the size of the risk (6.1.2) and the follow-on treatment of those risks will always be an uphill struggle; incoherent, and inaccurate. 

Another case in point:
  • Is there demonstrable evidence of management engagement? Forcing this point; do those senior department heads actively engage in being accountable and responsible for managing the risk to their department's information and data? I know it is not the fun stuff, but nevertheless, it is important stuff and saying that, “I have a day job to do,” does not cut-it. 
  • In real terms this is one failure of 6.1.1 that may well lead onto failures at 6.1.2 etc.
Of course, 2016 has a different look and feel when it comes to the use of technology and innovation than it did some 10 or even 5 years ago. But, the basics still hold true. 

It does not matter if an organisation intends to roll out a DevSecOps policy to drive fast, clean, safe code with lots of contribution and collaboration; the question is, does it sit within the scope of the organisation’s ISO/IEC 27001:2013; if it does then put it in place. A failure to implement the policy will be a risk to the ISMS (6.1.1) and, a failure (probably) at 6.1.2.

This is not a battle between the realms of information security, cybersecurity, DevSecOps or anything else! 

The UK’s recent publication of its Cybersecurity Strategy 2016-2021, talks of Defend, Deter, and Develop; remembering that this is the UK Strategy to protect its economy and privacy of its citizens (quote). Also, remembering that none of this is new. The UK’s Department of Trade and Industry (DTI) back in the mid 90’s worked with the BSI to produce a set of standards related to managing the security of information (Code of Practice and a set of requirements). These documents have evolved into ISO/IEC 27001:2013 and ISO/IEC 27002:2013 and related guidance as well as sector based controls. Taken on balance and despite Gov. based strategies, in 2016 we are where we are through decades of abject failure at provider and consumer level to effectively manage and protect that which should have been protected. 

One of the many reasons for Certification to ISO/IEC 27001:2013 is to give an assurance to interested parties that the organisation is taking the matter of managing the risk to critical and sensitive information and data, and their processing facilities (whether on-premise or in the Cloud) seriously. 

Consider a provider of IT based remote industrial control systems who has failed to patch the primary servers for a few years and now finds, on reflection, that trying to patch the servers now will have considerable consequences, in terms of availability, to its client base. The client base has no assurance (and indeed, why has the client base not followed through with its due diligence?) and simply put, there has yet again been a complete failure to understand and manage the risk to, in this case to critical data and processing facilities. If this provider were Certified to ISO/IEC 27001:2013 (which they should not be), then this fails at 6.1.1 and 6.1.2.

To quote one learned gentleman, “I don’t understand why you don’t understand.”

NRL.

For further information: contact@kansecurity.com


Sunday, 25 September 2016

Information asset register and Information Risk





A difficult question to answer I suppose, but just why would any business actively building a formal information security management system (ISMS) to meet the requirements of ISO/IEC 27001:2013, not include the building of an information asset register?

The clue really is in the title – INFORMATION security, management system. 

It is fully appreciated that the emphasis over the last few years has been, and in all likelihood will continue to be, cybersecurity.  But, just how much thinking does it require to identify the correlation between information security and cybersecurity?

In what domain do the following sit: either information security or cybersecurity?
  1. A perimeter based firewall?
  2. An overarching information security policy?
  3. A SEIM system?
  4.  An information risk management process?
  5. A white box penetration test?
  6. A Privacy Impact Assessment (think UK DPA98 sort of, but definitely GDPR)?

I’m not going to provide answers, yet (to cheat, see end) but rather, I’m going to head off down a slightly different path:

  •  In recent days, a major tech company has revealed that criminals stole a copy of account details of some 500 million users, in 2014.  The details include: names, email addresses, telephone numbers, dates of birth, hashed passwords (the vast majority with bcrypt) and, in some cases, encrypted or encrypted security questions and answers (Yahoo Security Issue FAQ).
  • In recent days, 41 athletes from 13 countries have had some of their medical information stolen and made public, from the Rio 2016 Olympic Games account of WADA’s Anti-Doping Administration and Management System (ADAMS). The objective for this breach of their confidential information can, without too much imagination, be guessed at.  The key point, notwithstanding the motivation of the criminals, is that it was sensitive medical information.

What is the point of these two statements? 

I’m personally not too concerned, for the moment, about who the criminals were; my concern is related to, accountability and responsibility.

Who, in both of the cases above, were accountable and responsible for ensuring that ‘users’ details were kept, confidential?

  • In the first case, is it possible to identify anywhere on Yahoo’s websites their formal assurance (other than a bunch of words) that security measures are in place and that independent audits have been completed successfully?  I’m referring to a formal assurance such as ISO/IEC 27001:2013 or similar.
  • In the second case, ADAMS has ISPPPI 2009 – International Standard for the Protection of Privacy and Personal Information, Part 2 Standards for Handling Personal Information and P2.9 Maintaining Security of Personal Information. However, a search for the words, ‘audit’ or ‘assessment’ reveal nothing. Fascinatingly enough however, P2.9 has some magic words and phrases such as:
    • Anti-Doping Organizations shall apply security measures that take into account the sensitivity of the Personal Information being processed. (P2.9.3)
  • The word ‘measures’ in P2.9.3, implies a whole heap of different matters not least of which should be: information risk management and application; application of controls to reduce levels of risk; assessment and audit.  The only time the word risk appears in the entire standard is in the following sentence:
    • Anti-Doping Organizations shall apply a higher level of security to the Sensitive Personal Information that they Process, reflecting the correspondingly greater risk that the unlawful or unauthorized disclosure of such information presents to the Participant or person to whom the Personal Information relates (P2.9.3).

What has all this to do with an organisation knowing what critical and or sensitive data and information they process, transmit, store?  

If an organisation uses data and information as an integral part of their business objectives (and which one doesn't?) then any information risk based process should have as its primary focus, data and information.

What is going to happen if the primary focus is completely ignored (which, in a business sense, it usually is) and the concentration is entirely on the cybersecurity – what is going to be missed, and can an accurate report for those accountable and responsible, the governing board, be produced? In other words, is it really possible to fulfil due diligence obligations in all respects?

Information risk is a many-to-one process – many things to consider to ensure that one objective can be met – protecting the business and its objectives having, in the case of information security, data and information as the focus.

So in the final analysis; if data and information, that are critical and or sensitive, are the focus then make sure you know what you have (known as an information asset register), and then link those assets to all the supporting assets; because the data and information is dependent upon those supporting assets (and that’s where the vulnerabilities will be).

Surprisingly the number of businesses who have a formally Certified ISMS to ISO/IEC 27001:2013 without an information asset register is shockingly high.


When there is no information asset register and you focus entirely upon cybersecurity related components, you really are only doing half a job, Bob! 

And yes; the questions above were trick questions - they are all information security management related having, as a subset, cybersecurity (ISO/IEC27032)
  • If data and information needs to be protected - a question that can be asked is (silly context); do I need a firewall in place to ensure data and information is kept safe?  If having one reduces the level of risk what else must be done to ensure that the level of risk remains at an acceptable level.
    • What assurances does the manufacture of the firewall provide that states the product is sound?
    • The technician I hired, did I check her/his credentials and what about a background check;  
    • Who else can get physical access to this firewall, is it located in a secure area?
    • Everything the technician has done to configure the firewall has it been documented and is it based upon written specifications?
    • What happens if a change is required, is there some kind of process in place?
    • What happens if things go wrong; will I know and what processes are needed to assess and correct the problem?
    • What assurance is there that the business objectives are now protected; do I need an audit process, do I need pen test to provide the assurances?
    • Etc...
Contact@kansecurity.com

Sunday, 28 August 2016

ISO/IEC27001:2013 and Information Security Risk





Consistent with Certification to ISO/IEC 27001:2013, clause 6 informs us that there must be planning in place and in particular, planning to address the thorny subject of risk and opportunities related to the formal ISMS.

First advice is to get hold of copies of the following and in priority order:
  • ISO/IEC DIS 27003.2, Information security management system, Guidance
  • ISO/IEC 27005:2011, Information security risk management, and just for good measure
  • ISO 31000:2009, Risk management, Principles and guidelines

One has to agree that this is quite an investment and for small businesses possibly out of reach.

The definition of risk as described within ISO Guide 73:2009 is as follows:
  • The effect of uncertainty on objectives. Simple but yet does exactly what it states on the tin and can be as complex or as straightforward as the context and objectives dictate. 

The questions being asked are:
  • What are the objectives?
  • What could affect our ability to meet those objectives?

Consider the following complex objective: 
the provision of assurance, acceptable to the governing board and all other interested parties, that external criminal parties cannot, or at the least will have serious difficulty in gaining access to the company network whose is motivation is the compromise of sensitive and critical data and information for monetary gain.
What then could have an effect on meeting the above assurance provision?  The word ‘uncertainty’ now comes in to play because to understand the effect and its uncertainties requires knowledge and identification of all the various components within the objective and a means to measure those uncertainties in terms of likelihood and consequence.

In 2016 the objective described above is likely to be one of the toughest to achieve, but achieve it we must. The responsibility is on us to ensure that whatever is put in place to measure uncertainty is going to be workable and with an ability to achieve an output such that it enables sound decision making, and will eventually meet the assurance needs.

To help, or indeed hinder, there are a plethora of information risk methodologies including the use of the odd spreadsheet or two; but the for moment let’s keep it simple.

ISO 31000 provides insight into General Risk management; its companion, ISO 31010 provides insight into risk assessment.  No particular taxonomy is described within these standards, but related directly to them is, ISO/IEC 27005. Being a part of the ISMS Family of documents it is targeted at managing the risk to information and data.  The document is not a methodology, but does describe a process (if that’s not a contradiction) that can/could be adopted.

The objective (above) is to provide assurance and yes, it is complex and must take into account the strategic objectives of the business, tactical objectives to support strategic objectives and all the relevant operational level objectives.  The output is likely to be multiple levels of reporting probably aggregating upwards from operational levels.

So, just why is this assurance needed? Let’s suggest for example that there is a compliance need along with contractual obligations to keep sensitive and critical data and information safe; failure to do so likely ending as a negative consequence on the business and any interested parties.

We need to make some assumptions now – context, risk appetite, risk tolerance, criteria are in place. The scope of an initial assessment, especially at operational levels can be quite narrow – say a group of file servers.

Starting the process:
Identification – gathering information.
  • Identify the primary asset within scope – yes, the primary assets are data and information.  There should be an owner or owners (responsible and accountable for the risk to these assets). The sensitivity and criticality of these assets should also be identified. In fact, these should have been identified long ago because so much is dependent upon this knowledge – priorities (key lines of business?), classification, access controls, trust levels, DR requirements and so on.  As an aside, a laptop is not an information asset – it is a container, but is also likely to be a point of access to other primary assets.
  • Identify supporting assets within scope – what other assets are involved that enable us to process, store, transmit the primary assets.  These will be laptops, file servers, applications, processes, people and so.  Note: the primary asset can do nothing to protect themselves its all down to the holes in the supporting assets and what is done to fill those holes.  So the importance of linking primary assets to all supporting assets in scope becomes vital.
  • Identify the threat – the threat will come from different directions, internal and external. So now match threat sources and actors to the supporting assets. 
  • Identify the vulnerabilities – let’s be honest here and state there are more vulnerabilities in the supporting assets than enough. What is known is that the threat actors will exploit the vulnerabilities in our supporting assets to get access to the primary assets.
  • Identify the consequences – what is likely to happen to our objectives?  Has the external threat actor been able to exploit vulnerabilities within the infrastructure and gained access to the primary assets and if so, what is that likely to do to our business objectives?

Analysis – using the gathered information to understand the level of risk.
  • Usually a qualitative analysis (or semi-quantitative analysis to be purist about it) that gives us figure based upon a combination of likelihood and consequence (silly note: impact isn’t actually defined within ISO Guide 73:2009) for a loss of confidentiality, integrity and availability.  This now gives us an output.

Evaluation
  • Compare the level of risk with the predefined criteria to give us the exposure level the organisation is facing. This is often seen as the Red, Amber, Green process.  Is this exposure acceptable?  If not, then the risk must be treated. 

That’s the risk assessment completed we are now into the treatment phase. 
The objective being to treat the risk somehow – modify, retain, share, avoid or combinations of the same. Modify what?  The level of risk so that the organisation’s exposure is reduced to an acceptable level – and as agreed by all stakeholders.

By modifying the level of risk, controls will be implemented or improved. Now re-assess or in other words, go through the process to ensure that the level of risk has been modified and the exposure now at an acceptable level.  

Now what? Controls will be re-assessed, monitored, reviewed - this is a constantly moving world. If you have a pen-test done on parts of the network the knowledge gained from the report is valuable for reducing levels of risk. Vulnerability assessments, automated and on-going, can be used as part of the information gathering process.  Incident management can be used as part of the information gathering process (its called lessons learned) - its a never ending process. Why is it being done?  To protect the business.  

For further information:
Nigel Landman at