NoticeBored

NBlog July 20 - what is the ISMS for?

NoticeBored - Fri, 07/19/2019 - 4:25pm

Another interesting morning on the ISO27k Forum when a new member asked for help to address an ISMS internal audit finding relating to ISO/IEC 27001:2013 section 4.1: 
“The organization shall determine external and internal issues that are relevant to its purpose and that affect its ability to achieve the intended outcome(s) of its information security management system.”
To my beady eye, that succinct sentence (plus the rest of clause 4 and more besides) leads-in to a fairly diverse and creative set of activities relating to ‘establishing the context for the Information Security Management System’:
  1. Who are the stakeholders with an interest in the organization’s information and hence the associated risks and opportunities? What are their 'issues' - their interests, in fact? What matters to them? What are their priorities and concerns? What business is it of theirs? [Clause 4.2]
  2. Consider the organization’s purposes (business objectives/goals, strategies and other drivers and constraints) that in some way involve or drive information risk and security e.g. if “Being a trusted partner” is one of the corporate aims stated in the CEO and Board’s mission statement, that indicates a need to be a trustworthy organization, and hints at a desire to be recognized and appreciated and valued as such by business partners/outsiders. So what are the implications on how we do business, in particular how we handle information?  What should the ISMS be doing (or indeed avoiding) in support of "being a trusted partner"?
  3. Consider also how information risk and security concepts can/should support and enable the business. For instance, what is management’s position on privacy – not just the obvious legal and regulatory compliance aspects but privacy, personal space, personal choice and freedoms etc. as a more general concept? What about, say, the ‘integrity’ part of the CIA triad: in what ways is integrity relevant and potentially necessary or valuable to the business? And what about information risks: how will the ISMS help manage those? What will the ISMS bring to the game that couldn't be done as well without it?
  4. Elaborating on that concerning the ISMS itself, what is it expected to achieve for the organization? How will a [certified] ISMS earn its keep across all of those areas – how will it make that easier, better, cheaper etc., more than offsetting the costs involved in establishing, operating and maintaining the ISMS? What are the priorities? In hard-nosed business terms, where’s the financial value in going down the [certified] ISO27k ISMS route when there are many alternatives, some of which might not be possible or might be delayed if finite resources are allocated to the ISMS implementation? And what are the risks associated with the ISMS itself, plus the implementation project? What might derail this train?
  5. With all that in mind, then, what are the key elements and factors relating to the ISMS – including things such as: its main purposes or objectives, expectations etc.; its scope [clause 4.3]; the anticipated net value (ideally with enough details behind that to measure and demonstrate the value achieved); its integration with the rest of the organization including other management systems, functions, departments, initiatives etc.; its risks; and how will all that be governed, managed, directed and controlled?
That’s how I personally would read and interpret clause 4. My interpretation goes way beyond what the standard literally says and formally requires, and there are some on the ISO27k Forum who would argue (with good cause) that – as usual - I’m blabbering on, making a mountain out of a molehill and over-complicating matters (yup, guilty as charged!). The KISS approach would involve doing the least amount possible in order to convince the certification auditors that we have done what is required in the standard: I understand that perspective, and appreciate that certification and simplicity are legitimate and valuable objectives in their own right … and yet I believe we can achieve even more value from ISO27k by going beyond the minimalist formalities, designing and building an ISMS that adds even more value to the business, which in turn will help ensure its longevity and deeper integration into the organization. There's reason to my madness.
Further reinforcing the broader perspective, ISO/IEC 27003:2017 (the very useful ISMS implementation guide) has a full two pages of explanation and guidance just on section 4.1. I'm not going to lay it out here though. Go read the standard!
In practice, the outcome of those competing pressures is generally something in the middle. At the time of certification, the ISMS has to be at or above the minimum formally required in ‘27001. The question is how far above should it be? In which respects is it worth going above and beyond?
Personally, I’m keen to explore the wider business objectives and possibilities (the business risks and opportunities associated with the ISMS - the stuff that clause 6.1 should have addressed if it hadn't fallen down the information risk rabbit hole) at the outset, in order to ensure that the ISMS is designed with those longer-term goals in mind, even if in the short-term it barely does what it has to do. It's about persuading management to invest in information risk and security management because that's the route to prosperity for the organization. Scoping, directing and launching the ISMS are the critical first steps on a long journey. So let's set off on the right foot, eh? Let's at least assemble the A-team to design the edifice and construct sound foundations using building materials that won't crumble if/when we decide to add a second storey. The ISMS needs integrity too.
Categories: NoticeBored

NBlog July 13 - corporate infosec policy

NoticeBored - Fri, 07/12/2019 - 2:39pm




















At the peak of the typical policy pyramid sits a ‘corporate information security policy’. In clause 5.2, ISO/IEC 27001 explicitly requires a high level policy, specifying related aspects such as demonstrable management commitment.
Our corporate information security policy template has:
  • The usual boilerplate for any formal policy e.g. summary, applicability, version and date up front, plus responsibilities and references at the back;
  • A short introduction, using the pyramid diagram to outline the entire information security policy structure;
  • A set of seven principles (objectives) driving information risk and security e.g. “Information is a valuable business asset that must be protected against inappropriate activities or harm, yet exploited appropriately for the benefit of the organization.  This includes our own information and that made available to us or placed in our care by third parties.”;
  • A set of 35 policy axioms (key policy statements) derived from the control objectives in ISO/IEC 27002 with some modifications and extensions to the wording to suit this purpose.
The principles fascinate me. They aren’t (yet!) stated in any of the ISO27k standards, and yet these are fundamental concepts underpinning the entire field such as 'least privilege' and 'personal accountability'. In researching and preparing our corporate infosec policy, I dug out a bunch of principles from various places and rationalized them down to the present set. I’d like to revisit that sometime, maybe even prepare a paper about the principles and then propose either a new ISO27k standard or an appendix to, say, the information security governance standard ISO/IEC 27014.
Categories: NoticeBored

NBlog July 11 - not playing by the rules

NoticeBored - Wed, 07/10/2019 - 7:40pm
According to the BBC, British Airways has been fined £183m for last year's breach of the General Data Protection Regulation, dwarfing the previous record fines of £½m under the previous Data Protection Act.  
Ouch. Privacy compliance is now A Thing - A Very Big Scary Thing with Sharp Teeth, Claws and a Bad Attitude.
The prosecution and fine broadcasts a clear message that organizations are going to be held to account under GDPR for failing to prevent privacy breaches. I guess privacy officers, information risk and security managers, CISOs, CROs, CCOs and execs generally are now scrambling to gain assurance that their organizations are not going to end up in the same mess. And management at organizations which have suffered privacy breaches since GDPR came into effect, especially if they are currently under investigation or being prosecuted, must be quaking in their hand-made Italian leather boots. 
At 366 times the previous record, the BA fine is deliberately shocking. No wonder BA is talking about appealing the decision ... but it could have been even worse. Reportedly the fine was 1.5% of BA's global turnover, while the maximum for specific penalties under GDPR is 4%: that would have been an eye-watering £488m, or about US$600m
Gulp.
Airline profits are unusually volatile thanks to intense competition and factors largely outside management's control, such as fuel prices and significant incidents that affect the global travel industry. BA might conceivably need to call on its parent company or the banks for assistance to settle the bill without taking a corporate nose-dive. Even cancelling executive bonuses seems unlikely to be enough.
Having said that, any well-run organization will have identified, evaluated and treated their privacy and other information risks, including making contingency and other business continuity arrangements just in case serious incidents such as this occur. Compliance is a good reason to manage information risks professionally, on top of the many good business and social reasons for taking it seriously.
Categories: NoticeBored

NBlog July - playing by the rules

NoticeBored - Mon, 07/08/2019 - 6:45pm
This month's NoticeBored information security awareness module concerns compliance - not just complying with laws and regulations, but with rules as a whole including corporate policies, contracts, agreements and ethical codes.
The materials explore the different types of obligation or expectation, and degrees of compliance. It's not a purely binary issue, despite what some may think: compliance to the very letter of the law is different to willing agreement to fulfill the spirit of the regulations.


Read more about the new module on the NoticeBored website.
Categories: NoticeBored

ISO27k audit planning

NoticeBored - Mon, 07/08/2019 - 6:32pm

A thread on the ISO27k Forum about how to go about auditing an organization's Public Key Infrastructure set me thinking this morning.
The thread started with a question from PS:"Could you please share some tips for auditing TLS/SSL arrangements within organisation?  Nessus will help us to identify weakness around configuration of crypto but if  I want to audit how sysadmins are creating self-signed certs and applying key management principles, how would I do that?"In response, Ahmed provided some background information about PKI, followed by a fairly detailed and specific list of 15 auditable items, describing them as 'essential points':
  1. Audit for Root Certificate: how its managed, should be stored over secure hardware module (HSM) FIPS 140-2, if not how its secured.
  2. Assess CA Signing certificate (CA Private key) : How it is managed, secured, validity and key length.
  3. Audit System documentation to audit: (mentioned above) specially key management policy and procedures.
  4. Audit roles and segregation of duties
  5. Audit certificate templates: Issuing compliant certificates, SSL-TLS and Digital identity if valid that your are using two certificate templates or only SSL-TLS
  6. Audit for certificate (key usage) for individual certificates (Mail signing, authentication, encryption, etc.)
  7. Audit access control to the CA (should be subject to dual control)
  8. Audit CA Public key and intermediate certificates distribution, to assure its trusted over all systems.
  9. Audit for clock sync over used system
  10. audit system database security
  11. audit system backup and restore (for CA server, Configurations, HSM, root certificate, database)
  12. Audit for CRL publishing or cashing over systems
  13. Audit validity of issued certificates and how renewals are managed, to avoid human error to forgot to renew a certificate may cause system malfunction
  14. Audit the process itself for certificate issuing, renewal and revocation. (should be subject to dual control as maker checker)
  15. Audit certificate formats and extensions (PKCS formats and extensions)


Those 15 items may be a useful prompt or reminder but may not be appropriate in any given situation. ‘The essential points’ for a given audit are best determined in practice by the auditor/s using risk analysis, followed by detailed planning and prioritizing the audit work given the available resources (audit timescale plus auditor man-hours and skills).

An audit must reflect the audit objectives and scope, usually determined up-front by discussion between the audit and client management when the assignment is initiated and agreed. So, for instance, if the primary objective is to audit compliance of an ISMS with ISO/IEC 27001, the PKI is probably just a small part of that. However, if the prime objective is to audit the PKI, specifically, then a list of items similar to the 15 suggested by Ahmed may flow out of the audit risk analysis – or not: it all depends on the information risks, just as the ISMS and the PKI are driven by the risks.
As a general rule, relative risks are a good basis for prioritization: in essence, the idea is to tackle the most significant risks first and deepest, leaving lower risk matters for later, shallower review. That way, if the priority stuff turns out to be more problematic or to take longer than anticipated and resources are exhausted, the assignment can end knowing that the high priority areas have been done.
With a nearly infinite amount of potential audit work for finite resources, there are things that simply can’t be done right now. So, it pays to prioritize ‘the essentials’ and de-prioritize or park the remainder for another time. Keep notes in the audit file for use in planning future audits, along with previous audit reports, fieldwork notes, an updated risk analysis and other information sources (e.g. management reviews, incident reports etc.). This is continuous improvement for auditing.
An alternative or complementary audit planning approach is to come up with a small number of 'areas of concern', then invest an appropriate amount of audit resources into each one. Determining those 'areas' again depends on circumstances: one approach to a PKI audit might distinguish technical/cybersecurity stuff from physical and procedural aspects, for instance. Another might follow the lifecycle of a digital certificate, or concentrate on the individual departments and teams associated with the PKI, or pick up on incidents and known troublespots as routes in to the analysis, or ... whatever. There's even something to be said for deliberately planning each successive audit on a different basis, in order to avoid covering the same ground from the same perspective and hence missing the same issues (blindspots).
It's always worth reserving some time to explore interesting/concerning stuff that comes up in the course of the audit. For example, if the audit fieldwork uncovers issues with, say, key-management, it mightbe worth delving more deeply into key management both to find out if there is anything substantial and reportable in that specific area, and also as a worked example for the more general aspects such as policies, procedures, technical controls or whatever.  The key-management focus may not have been apparent during the original audit planning, although sometimes there are nonspecific clues about potential problem areas that feed into the risk analysis and planning (the auditor’s nose sniffing out trouble spots!). 
This is an example of contingency management: the audit work that needs to be performed partly depends on the circumstances or situation that unfolds in the course of the assignment. It can't all be pre-plannned.
It cuts both ways too. If the initial audit work goes better than planned, that leaves more time for other, lower priority matters, and might even result in concluding the audit early with a glowing audit report. 
Yes, it does happen!  Been there, done that!
Categories: NoticeBored