Welcome to NBlog, the NoticeBored blog

I spy with my beady eye ...

Nov 18, 2019

NBlog Nov 18 - enough is enough

Keeping ISO27k Information Security Management Systems tight, constrained within narrow scopes, avoiding unnecessary elaboration, seems an admirable objective. The advantages of ISMS simplicity include having less to design, implement, monitor, manage, maintain, review and audit. There's less to go wrong. The ISMS is more focused, a valuable business tool with a specific purpose rather than a costly overhead. 

All good. However, that doesn't necessarily mean that it is better to have fewer ISMS documents. In practice, simplifying ISMS documentation generally means combining docs or dispensing with any that are deemed irrelevant. That may not be the best approach for every organization, especially if it goes a step too far.

Take information security policies for example. Separate, smaller policy docs are easier to generate and maintain, {re}authorize and {re}circulate individually than a thick monolithic “policy manual”. It’s easier for authors, authorisers and recipients to focus on the specific issue/s at hand. That's important from the governance, awareness and compliance perspective. At a basic level, what are the chances of people actually bothering to read the change management/version control/document history info then check out all the individual changes (many of which are relatively insignificant) when yet another updated policy manual update drops into their inbox? In practice, it aint gonna happen, much to the chagrin of QA experts!

On the other hand, individual policies are necessarily interlinked, forming a governance mesh: substantial changes in one part can have a ripple effect across the rest, which means someone has the unenviable task of updating and maintaining the entire suite, keeping everything reasonably consistent. Having all the policies in one big document makes maintenance easier for the author/maintainer, but harder for change managers, authorisers and the intended audiences/users.

As if that’s not challenging enough already, bear in mind that information risk and security is itself just part of corporate management, with obvious links to IT, risk management, HR, compliance and many other areas, some of which are more obscure or tenuous (e.g. health & safety is an information security issue in the sense that people are information assets worth protecting). The ripples go all the way, and flow both ways: changes in, say, IT or HR policies can have an effect on information risk and security, requiring policy updates there too.

Even within the ISMS, extending your policy management approach to take in the associated procedures plus awareness and training materials multiplies the problems. Extending it to include myriad other ISMS-related documentation makes it worse again. 

Alternative approaches include using a ‘document management system’ or ‘policy management system’ – essentially a database system used to manage and control the materials as a coherent set – and hybrid approaches such as Word’s “compound document” facility – with one master doc linking to all the subsidiary docs, one for each policy. Here again there are pros and cons, not least the costs involved plus the rigidity and red-tape they inevitably introduce.

Rationalising and simplifying the ISMS documentation to reduce the practical problems and costs clearly makes a lot of sense, but be careful: information risk and security is an inherently complex, far-reaching concept. There’s a lot to it. If for instance you drop a given policy from the ISMS suite on the basis that it is only marginally relevant, too narrow, too obscure or whatever, that leaves you without a stated policy in that area, which may have implications elsewhere, implications that may not be immediately obvious. Damn those ripples!

Bottom line: governing, structuring, managing and maintaining ISMS documentation is tougher than you may think. The trick is to find the best balance point for your organization, specifically, and the generic standards can only offer so much guidance on that.

Nov 15, 2019

NBlog Nov 15 - risky business

Physical penetration testing is a worthwhile extension to classical IT network pentests, since most technological controls can be negated by physical access to the IT equipment and storage media. In Iowa, a pentest incident that led to two professional pentesters being jailed and taken to court illustrates the importance of the legalities for such work. 

A badly-drafted pentest contract and 'get out of jail free' authorization letter led to genuine differences of opinion about whether the pentesters were or were not acting with due authority when they broke into a court building and were arrested. 

With the court case now pending against the pentesters, little errors and omissions, conflicts and doubts in the contract have taken on greater significance than either the pentest firm or its client appreciated, despite both parties appreciating the need for the contract. They thought they were doing the right thing by completing the formalities. Turns out maybe they hadn't.

I hope common sense will prevail and all parties will learn the lessons here, and so should other pentesters and clients. The contract must be air-tight (which includes, by the way, being certain that the client has the legal authority to authorize the testing as stated), and the pentesters must act entirely within the scope and terms as agreed (in doubt, stay out!).  Communications around the contract, the scope and nature of work, and the tests themselves, are all crucial, and I will just mention the little matter of ethics, trust and competence.

PS  An article about the alleged shortage of pentesters casually mentions:
"The ideal pen tester also exhibits a healthy dose of deviancy. Some people are so bound by the rules of a system that they can’t think beyond it. They can’t fathom the failure modes of a system. Future penetration testers should have a natural inclination toward pushing the boundaries – especially when they are told, in no uncertain terms, not to do so."
Hmm. So pentesters are supposed to go beyond the boundaries in their testing, but remain strictly within the formally contracted scope, terms and conditions. 'Nuff said.

Nov 12, 2019

NBlog Nov 12 - on being a professional

While Googling for something else entirely, I chanced across this statement from Darren on a ten year old SceptikLawer forum thread:
"The essence of my job as an information security architect is to understand the balance between risk (legal, practical, and otherwise) and the need for an organization to conduct business efficiently. I think a lot of what I do really does boil down to seeing the other side of things; I know what the “most secure” way is, but I also have to understand that implementing it might mean debilitating restrictions on the way my employer does business. So what I have to do is see their point of view, clearly articulate mine, and propose a compromise that works. There’s a reason a lot of IT security folks become lawyers. "
Nicely put, Darren! While personally I'd be reluctant to claim that I 'know what the most secure way is', the point remains that an information security - or indeed any professional's job revolves around achieving workable compromises. For us, it's about helping or persuading clients and employers identify and reduce their information risks to 'reasonable' levels, then maintaining the status quo through ongoing risk management.

Some of our professional peers struggle with this, particularly inexperienced ones with IT backgrounds. They (well OK, we) can come across as assertive, sometimes to the point of being arrogant and pig-headed, obstinate or even rude. Things 'must' be done in a certain way - their way. They are trained professionals who have been taught the 'most secure way' and are unwilling to countenance any other/lesser approach. Situations appear black or white to them, with no shades of grey.

Along with with Darren, presumably, I view most situations as greys, sometimes multicoloured or even multidimensional due to inherent complexities and differing perspectives. There is almost always more to a situation than it first appears, and often more to it that I appreciate even after studying it hard. I embrace ambiguity. I value flexibility and open-mindedness, and strive to be flexible and open-minded in my work: for me, it's an integral part of 'being professional'. 

Such pragmatism is fine ... up to a point. However there are situations where it gets harder to back down and eventually I may stand my ground, refusing to compromise any further on my core values (particularly personal integrity). That, too, is a part of 'being professional'. 

There are behavioural clues that I'm approaching my sticking point, such as:

  • Doubling-down on the analysis, carefully reviewing and reconsidering the position, searching even harder for those 'workable compromises'
  • Openly acknowledging what I know about the situation, including other perspectives, ambiguities, the limits of my/our knowledge and (ideally) the pros and cons of the range of options available
  • Being explicit about my advice/recommendations, explaining myself as clearly as I can - generally in writing
  • Focusing on 'what's best for the organization' and 'the business' rather than me/us as individuals, or our professional judgement, or best practices, compliance obligations or whatever
  • Trying (not always successfully!) to distinguish the relationship, personal and more subjective or emotive issues from [what I believe to be] the objective situation and decisions at hand
  • Either negotiating the workable compromise, or playing my trump card - usually something along the lines of "They are your information risks, not mine. You are accountable for the risk management decisions you make, but I stand by my advice." That's my reasonably polite but hardly subtle version of take-it-or-leave-it, my-way-or-the-highway - and I mean it. I have literally walked away from untenable situations and don't regret it one bit.

Talking of which, I'm so busy now that I'm turning down new work because I don't the energy and time to do things 'properly'. Must dash, things to do. 

Nov 10, 2019

NBlog Nov 10 - strategic risk management

There's an old old joke about a passing stranger asking for directions to Limerick.  "Well," says the farmer, "If oi was you, oi wouldn't start from here".

So it is with infosec strategies. Regardless of where your organization may be headed, by definition you set out from a less than ideal starting point. If it was ideal, you wouldn't be heading somewhere else, would you? That naive perspective immediately suggests two alternatives:
  1. Bear in mind where you are today, planning your route accordingly.
  2. Regardless of where you are today, focus exclusively on the destination and how to get there.
Actually, those are just two of many possibilities. It's even possible to do both: strategic thinking generally includes a good measure of blue-sky idealist thinking, tempered by at least a modicum of reality and pragmatism. 'We are where we are'. We have a history and finite resources at our disposal ... including limited knowledge about our history, current situation and future direction. What's more, the world is a dynamic place and we don't exist in a vacuum, hence any sensible infosec strategy needs to take account of factors such as competitors, compliance and other challenges ahead - situational awareness plus conjecture about how the situation might conceivably change as we put our cunning strategy into practice (as in chess). 

That's risk, information risk in fact, amenable to information risk management in the conventional, straightforward, systematic manner:
  • Identify and characterise the risk/s, both negative and positive (opportunities, the possibility that things might turn out even better than planned);
  • Quantify and evaluate the risk/s;
  • Decide what to do about them;
  • Do it! Finalise the strategy, negotiate its approval (with all that entails) and make it so;
  • Manage and monitor things as the strategy unfolds and changes inevitably happen;
  • Learn new stuff.
That final bullet is usually an implicit part of the process. We discover flaws in our strategy, things that don't quite go to plan, activities that take longer or go in different directions for all sorts of reasons. 'We are where we are' as a result of past and current strategies, successes and failures, and there's a load of learning points there if you think about it:
  • Do we often over- or under-estimate things? How much variation is there, and is it biased one way or the other?
  • Are we frequently blind-sided by unexpected events?
  • Is it always a struggle to get anywhere, with too little energy to overcome the organization's inertia?
  • Are we resource-constrained/ Which are the tightest? Is there any slack we might redeploy?
  • Do we almost always achieve what we set out to achieve? Are we pushing hard enough?
  • Are we creative? Are we early, middle or late adopters, ahead, within or behind the curve? Do we miss out on opportunities, and if so what kinds, typically? Compared to our peers and competitors, are we usually in the right place at the right time?
That's all in addition to learning about our strengths and weaknesses in information risk and security management, controls, threats, vulnerabilities, impacts, governance, compliance, assurance and so forth: I'm waffling on about gaining knowledge of the process of strategic risk management, figuring out why we ended up right here, lost, floundering about in a blog, looking for Limerick ...

Nov 7, 2019

NBlog Nov 7 - super management systems

ISO 22301, already an excellent standard on business continuity, has just been revised and republished. Advisera has a useful page of info about ISO 22301 here.

There’s quite a bit of common ground between business continuity and information risk and security, especially as most organizations are highly dependent on their information, IT systems and processes. The most significant risks are often the same, hence it makes sense to manage both aspects competently and consistently. The ISO ‘management system’ structured approach is effective from the governance and management perspective. 

Aligning/coordinating the infosec and business continuity management systems has several valuable benefits since they are complementary. 

Extending that thought, it occurs to me that most if not all other areas of management also have information risk and security implications:
  • Physical site security and facilities management (e.g. reliable power and cooling for the servers);
  • IT and information management (dataflows, information architecture, information systems and networks and processes, intellectual property, innovation, creativity);
  • Change management (ranging from version control through projects and initiatives up to strategic changes);
  • Incident management (see below);
  • Risk management (as a whole, not just information risks);
  • Privacy management;
  • Relationship management (relationships with suppliers of goods and services, business partners, customers and prospects, owners/investors, authorities and other stakeholders, communities);
  • Compliance management (laws and regs, contracts and agreements, corporate policies, ethics);
  • Health-and-safety plus HR management (people are invaluable information assets!  Corporate culture, change/initiatives, motivation and compliance);
  • Product and operations management (core business!);
  • Quality management (especially quality assurance);
  • Assurance (reviews, audits, testing and checking functions, both internal and external);
  • Financial and general commercial management. 
Your management might even consider developing a corporate strategy or policy to adopt ISO Management Systems where available, perhaps with an overarching ‘governance committee’, 'executive team', 'board' or similar to drive the alignment, exploit the common ground between them, and address any gaps, conflicts or other issues arising. You probably already have such a beast (commonly but ambiguously known as "senior management", the "C-suite" or "mahogany row"), although it may not consider itself to be operating a super-management-system.

You might even take this a step further, aiming to integrate rather than simply coordinate and align those management systems. An obvious example concerns incident management - even something as basic as having a single multi-function contact point (Help Line, Service Desk or whatever) to receive and assess incident reports, initiate the relevant activities and coordinate communications among those involved.

Or not. The ISO MS approach is not the only option, and there may well be something even better for your organization – other standard methods, ‘best of breed’ solutions, something home-grown or a patchwork. There may be sound business reasons for keeping various areas separate (e.g. if they are, or might be, contracted out). I’m simply suggesting that coordination, alignment and integration between management systems might be worth considering, if and when you and your management are in a position to do so (not necessarily right now … although this is peak season for strategising and planning!).

I'll end today's sermon with a pertinent quote from an interview with Marc Goodman:
"CIOs and CISOs will also have to work much more closely with the executives in charge of functions like HR, facilities, physical security, and loss prevention to close security gaps. The bad guys have repeatedly demonstrated their ability to slip through the gaps created when enterprises segment security across various functions within their organizations."
Marc describes himself as “a global strategist, author and consultant focused on the disruptive impact of advancing technologies on security, business and international affairs”. He holds the Chair for Policy and Law at Singularity University in silicon valley. So no slouch then.

Nov 6, 2019

NBlog Nov 6 - insight into ISO27k editing

Today I find myself poring through ISO/IEC 27000:2018 looking for quotable snippets to use on our awareness posters in January. Although there’s plenty of good content, I can’t help but notice a few rough edges, such as this:
“Conducting a methodical assessment of the risks associated with the organization’s information assets involves analysing threats to information assets, vulnerabilities to and the likelihood of a threat materializing to information assets, and the potential impact of any information security incident on information assets. The expenditure on relevant controls is expected to be proportionate to the perceived business impact of the risk materializing.” [part of clause 4.5.2].

First off, here and elsewhere the ‘27000 text uses the term “information asset” which is no longer defined in the standard since the committee couldn’t reach consensus on that. Readers are left to figure out the meaning for themselves, with the possibility of differing interpretations that may affect the sense in places. The term is, or probably should be, deprecated.

Secondly, the first sentence is long and confusing – badly constructed and (perhaps) grammatically incorrect. “Vulnerabilities to” is incomplete: vulnerabilities to what? Shouldn’t that be “vulnerabilities in” anyway? Threats get mentioned twice for no obvious reason, overemphasizing that aspect. “Likelihood” is a vague and problematic word with no precise equivalent in some languages - it too should probably be deprecated. The final clause as worded could be interpreted to mean that the process is only concerned with potential impacts on information assets, whereas incidents can cause direct and/or indirect/consequential impacts on systems, organizations, business relationships, compliance status, reputations and brands, commercial prospects, profits, individuals, partners, society at large and so forth, not all of which are information assets (as commonly interpreted, anyway!). 

Thirdly, do “the organization’s information assets” include personal information? Some might argue that personal information belongs to the person concerned – the data subject – not the organization that holds it. My point is that it’s ambiguous and potentially misleading.

Lastly, I don’t entirely accept the premise of the second sentence. Sure, in business terms, the total cost of controls should normally be less than the total benefits but that’s not what the clause actually says – and anyway, information security is not entirely a matter of net value: some controls are mandated or imposed on the organization.  

If you think I’m being unreasonably critical or anal about this, fair enough: that’s the level of analysis typically used to justify changes to draft standards through JTC 1/SC 27. Now imagine the effort involved to review and comment on, say, ISO/IEC 27002, and to suggest changes (ideally explicitly proposing the replacement text in each case) and you’ll appreciate the time and effort involved as the international project team slogs its way laboriously through hundreds of pages of comments. It’s a wonder anything gets produced at all, let alone anything usable and as well respected as ISO27k!

The lawyers among us will probably appreciate the issue. The legal profession performs this painstaking analysis much more seriously and deeply. Even, punctuation, is ... of-concern. Each new law/regulation has to fit neatly into the existing body of legislation without causing conflicts. We’ve got it easy!

Nov 4, 2019

NBlog Nov 4 - social engineering awareness

December's awareness topic is one of our regular annual topics. Social engineering has been around for millennia - literally, in the sense that deliberate deception is a survival strategy adopted by many living beings, right back to primordial times.

So, what shall we cover this time around? 

In 2018, the NoticeBored awareness module took a deep dive into phishing, a modern-day scourge ... but definitely not the only form of social engineering, despite what those companies pushing their 'phishing solutions' would have us believe. We picked up on 'business email compromise' as well, another name for spear-phishing. 

In 2017, we explored 'frauds and scams' in the broad, producing a set of 'scam buster' leaflets explaining common attacks in straightforward terms, illustrated with genuine examples and offering pragmatic advice to avoid falling victim to similar tricks.

Back in 2016, the 'protecting people' module covered: social engineering attacks, scams and frauds, such as phishing, spear-phishing and whaling; exploitation of information and people via social media, social networks, social apps and social proofing e.g. fraudulent manipulation of brands and reputations through fake customer feedback, blog comments etc.; the use of pretexts, spoofs, masquerading, psychological manipulation and coercion, the social engineer’s tradecraft; and significant information risks involving blended or multimode attacks and insider threats.

Although we already have lots of content to draw upon and update, we always aim to cover current threats, which means this week our research phase draws to a close with a clearer idea of the scope of December's module, plus a bunch of recent incidents to illustrate the materials.

As to precisely what aspects of social engineering we'll be covering this time around, I'll drop a few more hints here on the blog as the module comes together.