Thursday, 9 August 2018



ISO 27001:2013. Compliance, Accredited?

If you say ISO 27001:20013 is about compliance or, you are accredited to the standard then something is amiss.

ISO/IEC 27001:2013 is not about compliance. It most certainly helps towards your compliance obligations (legal/regulatory/contractual), but not to the requirements set down by ISO/IEC (JTC1/SC27/WG1 – https://www.iso.org/committee/45306.html).
  • References:
    • ISO 9000:2015 defines in 3.6.11 the word, conformity.  Conformance, being synonymous with conformity was deprecated, and thus is not used (note 1 to 3.6.11).  The French word, conformit√© meaning compliance (in English) was also deprecated (note 1 to 3.6.11);
    • ISO/IEC 27000:2018 uses in 3.11 the definition for, conformity;
    • ISO/IEC 27001:2013 identifies in section 2 a single normative reference this being, ISO/IEC 27000 (and all amendments) and thus points to 3.11 in the 2018.  It also states in section 3 that the terms and definitions of ISO/IEC 27000 (and all amendments) are to be used.
Thus far not a single mention of, compliance (apart from the French/English translation).
  • ISO/IEC 27007:2017 identifies:
    •  in section 2 normative references;
      •  ISO 19011:2011,
        • Defines in 3.18 the word, conformity; giving as its source, ISO 9000:2005 (3.6.1).
        • ISO/IEC 27000,
        • ISO/IEC 27001:2013,
    • In section 3, terms and definitions, the definitions are referenced to;
      • ISO 19011:2011 and ISO/IEC 27000.
So then, nothing on that word, compliance.  ISO/IEC 27001:2013 is not a compliance standard, but it is one that your ISMS can be assessed against to determine if it conforms to stated requirements.

Now that your ISMS has successfully weathered the audit/assessment (Stage1, Stage 2) storm by an external Certifying Body (CB, and one that is ideally accredited by UKAS), it does not mean the ISMS is accredited! Not at all; your ISMS since it conforms to the requirements set down by ISO/IEC, is now certified.
  • References:
    • See, https://www.iso.org/certification.html.
      • "Certification – the provision by an independent body of written assurance (a certificate) that the product, service or system in question meets specific requirements.
      • Accreditation – the formal recognition by an independent body, generally known as an accreditation body, that a certification body operates according to international standards.”
  • Meaning:
    • Certification;
      • Independent body (CB) provides the written assurance that the ISMS conforms to the requirements of ISO/IEC 27001:2013; thus Certified.
    • Accreditation;
      • independent body, the accreditation body, (UKAS in UK) formally (through an extensive audit process) recognises that a CB is operating (performing 3rd party audits etc.) to international standards. Thus, the CB is accredited.
  • See, https://www.iso.org/casco.html:
    •  CASCO being the, Committee on Conformity Assessment;
      • ISO 17000:2004 definitions;
        • 2.4, Third party conformity assessment body (i.e. CB),
        • 2.5, Conformity assessment body (i.e. CB),
        • 2.6, Accreditation body (i.e. UKAS in UK),
        • 5.5, Certification (third party (CB) attestation related to system, (i.e. the ISMS.), products or services etc.,
        • 5.6, Accreditation (third party (UKAS in UK) attestation related to conformity assessment body (CB) and its competence to carry out conformity assessments.


Nigel Landman
KanSecurity Ltd


Tuesday, 31 July 2018

Troubles with your ISMS?


Are you implementing, thinking of implementing or maintaining an information security management system (ISMS) to the requirements ISO/IEC 27001:2013?

I appreciate the trendy thing to do these days is to list 10, 15 or 20 points on how to achieve stuff (irrespective of subject); you will not get that here.  Neither will you get any form of assurance that once successfully implemented, that you are now fully GDPR compliant. That is just not going to happen!

From a personal view point ISO/IEC 27001:2013 is a powerful piece of kit but, and this is most important, it doesn’t stand alone. Do not be under any illusion that simply purchasing and using this document will see your right; it won’t!  There are numerous resources available from ISO and other bodies that I would advocate using.  There is one resource that, in my opinion, is superb and it comes for ISACA’s German Chapter and their Information Security Expert Group entitled, Implementation Guideline ISO/IEC 27001:2013 (A practical guideline for implementing an ISMS…).

And what of the so-called Implementation Courses available to you from all and sundry?  This is usually a three-day course that takes an attendee through a basic understanding of the clauses within the standard, and of course Annex A, and if you are lucky a quick intro to the code of practice for information security controls (ISO/IEC 27002:2013).  This too is not necessarily going to cut it, especially if you are new to the game. You may well be better off purchasing additional documents from ISO.  And incidentally, why didn’t the course discuss the importance of; ISO/IEC 27003, 27004, 27005 et al?

Just because the title of the standard includes the phrase, ‘management system,’ it doesn’t mean you are building a simple compliance framework of policies and processes.  No, what you are building is an important framework that has the intention of protecting the interests of external and internal stakeholders, and ultimately the business itself by implementing policies and process to protect sensitive and or critical information and data.  It’s about: leadership and support; managing risk; competencies; resources; communication; conducting operational risk assessment; measuring performance; internal audit; continuous improvement, and unfortunately for all those ninjas and Jedi’s out there, documentation.

One thing ISO/IEC 27001:2013 is not is a process for building internal silos.  If you find this is happening, you’ve got it wrong. 

So, you have a Security Operations Centre (SOC) and a bunch of ninjas analysing all sorts of technical stuff.  Could this form part of your ISMS? Yep, of course it can. You have a bunch of Jedi masters who look for weaknesses, holes, exploitable stuff; could they form part of your ISMS; once again, of course they can.  Why? Managing risk; not building silos and so forth. It’s all about team work.

An assumption (bad) must be made.  The team (or person) building your ISMS to an agreed and approved scope will have knowledge of information and cyber security; or will they?  ISO/IEC 27021:2017 specifies the requirements of competence for ISMS professionals leading or involved in establishing, implementing, maintaining and continually improving one or more information security management system processes that conforms to ISO/IEC 27001. As a requirement this may make some sit-up and think, especially if the Certifying Body (CB) assessing your ISMS asks the right questions (which they won’t) during an audit/assessment on competencies.

Oh, and now that you successfully weathered the storm of the CB’s auditor/assessor and your shiny new ISO/IEC 27001:2013 Certificate is pinned to the wall (you are certified, NOT accredited), are you now GDPR/DPA18 compliant? No, not unless you have done a whole raft work relevant to the Regulation and the Act. Looking on the bright side however, your certification may well have had a positive input to the requirements.  



And for the ideal Information Security Management course to get you started – BCS, The Chartered Institute for IT, Certificate in Information Security Management Principles (BCS CISMP).  Flash to bang this is a 5-day course (plus exam) with a comprehensive run through of everything required of ISO/IEC 27001:2013 and many other frameworks. No prerequisites necessary for attendees, but at the end you will be ready to implement an ISMS and should you wish, move onto the next rung of the ladder of your information/cyber security career.

KanSecurity Ltd courses are in depth; full on; and far more cost effective than most offerings out there. Public schedule courses are running in Sep, Oct, and Nov.  In-house courses available as and when you need.

If you would like further details of our services, then please make contact: contact@kansecurity.com

Nigel Landman

KanSecurity Ltd is ....




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