Welcome to NBlog, the NoticeBored blog

The blogging will continue until morale improves

Jul 13, 2019

NBlog July 13 - corporate infosec policy





















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.

  • 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.

Jul 11, 2019

NBlog July 11 - not playing by the rules

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.

Jul 9, 2019

NBlog July - playing by the rules

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.



ISO27k audit planning


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 might be 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!