NoticeBored

NBlog Dec 13 - what is an "information asset"?

NoticeBored - Thu, 12/12/2019 - 2:00pm
ISO/IEC JTC 1/SC 27 tied itself in knots for years trying to answer that disarmingly simple and straightforward question, failing to reach consensus and eventually admitting defeat.
Back in 2014, ISO/IEC 27000 defined "Asset" very broadly as "anything that has value to the organization ... including: information; software, such as a computer program; physical, such as computer; services; people, and their qualifications, skills and experience; and intangibles, such as reputation and image."

To narrow it down a bit in the context of ISO27k, "Information asset" had also been explicitly defined in ISO/IEC 27000:2009 as "Knowledge or data that has value to the organization".
That definition still works quite well for me. "Information asset" refers to the intangible content - the meaning of information - rather than the vessels, media, equipment, facilities and human beings that house, process, communicate and use it.
The content is both valuable and vulnerable and hence needs to be protected or secured. That's what ISO27k does.
I appreciate that the tangible vessels, media, equipment, facilities and people are also assets that also require adequate protection, security and safety, but that's largely the domain of conventional physical risk and security measures such as vaults, locks and guards, plus health and safety. Other standards apply there.
At some point after the release of ISO/IEC 27000:2009 (I forget exactly when), SC 27 had become exhausted by the interminable arguments over the definition and called a halt to it. The definitions of "information asset" and then "asset" were summarily removed from ISO/IEC 27000. "Information asset" was systematically shortened throughout the ISO27k standards, usually to "asset" ... unfortunately as "information" would have been more appropriate in most cases.

"Asset" is currently defined in ISO/IEC 27032:2012 as "Anything that has value to an individual, an organization or a government. NOTE Adapted from ISO/IEC 27000 to make provision for individuals and the separation of governments from
organizations". According to the ISO browsing platform, "asset" is also defined in several other ISO standards e.g.:
  • "Plant, machinery, property, buildings, vehicles, ships, aircraft, conveyances and other items of infrastructure or plant and related systems that have a distinct and quantifiable business function or service - This definition includes any information system that is integral to the delivery of
  • "Security and the application of security management."
  • "Things that a user sees or hears, e.g., bitmap, audio, and text."
  • "Anything that has value to a stakeholder"
  • "Anything that has value to the organization"
  • "Anything an individual or a company owns which has value - In the container environment, an asset could be a container, the container’s contents, or information pertaining to the container"
  • "Things that a user sees or hears, e.g., bitmap, audio, text."
  • "Whole building or structure or unit of construction works, or a system or a component or part thereof"
  • "Manifestation, i.e. physical or digital embodiment of an Expression"
  • "item, thing or entity that has potential or actual value to an organization"
  • "Entities that the owner of the TOE presumably places value upon"
  • "Item, thing or entity that has potential or actual value to an organization - Value can be tangible or intangible, financial or non-financial, and includes consideration of risks and liabilities. It can be positive or negative at different stages of the asset life. - Physical assets usually refer to equipment, inventory and properties owned by the organization. Physical assets are the opposite of intangible assets, which are non-physical assets such as leases, brands, digital assets, use rights, licences, intellectual property rights, reputation or agreements. - A grouping of assets referred to as an asset system could also be considered as an asset."
'Something of value' is a general definition whereas the ISO27k standards are purely concerned with the management of information risk and security - not other assets such as land, property and machine tools. So, for example, in discussing an "Asset inventory" in the annex, ISO/IEC 27001 could be interpreted literally to mean "an inventory of anything of value" which is obviously way broader in scope that an inventory of information. It therefore had to explain in the text that the assets to be inventoried are those "associated with information and information processing facilities", another confusing phrase which implied that information itself is not an asset! That, in turn, was corrected by ISO/IEC 27001 corrigendum 1 in 2014:

The corrected version of that control still indicates that the inventory should include "other assets associated with information and information processing facilities", an open-ended scope that extends beyond the intangible information content, but despite the standard's use of "shall", Annex A is in fact discretionary or advisory, not mandatory.
But wait, there's more. ISO27k standards are applicable in the corporate context, so the value of assets is seen from the corporate perspective - primarily stuff that the organization owns. However, some information is only (in effect) loaned to the organization by third-parties, including people. Personal information on individual people belongs to those people, known as the "data subjects". People have legal and ethical rights over their own personal information, since it is valuable to them personally, as well as any business value to the organizations that make use of it. The same applies to intellectual property legally owned by third-parties - commercial software for instance, plus patented or trademarked designs and copyrighted material such as this very blog. "Information asset" turns out, once again, to be more complex that it seems.
I feel that SC 27 should really have bottomed out this issue since it is crucial to ISO27k, but a proper resolution to the discussion proved impossible within the constraints of the committee's formalized and tediously slow working practices.
So there we are. "Information asset" is undefined ... and unclear. Too bad.
Categories: NoticeBored

NBlog Dec 12 - a universal KPI

NoticeBored - Wed, 12/11/2019 - 2:00pm

For January's security awareness module on ISO27k, I'm developing a detailed checklist with which to assess, evaluate and score each of the information security controls recommended by ISO/IEC 27002 (as summarized in Annex A of ISO/IEC 27001)*.
The checklist/scoring format is one I invented years ago and have been using and refining ever since. It is a kind of maturity metric that has proven very valuable in practice, giving surprisingly consistent and useful results despite the subjective nature of the checks.
I am laying out 4 'indicators' for each control from '27002, specifying the kinds of things that would typically correspond to scores of 0% (exceptionally weak or missing controls) through 33% and 67% to 100% (exceptionally strong or cutting-edge controls). The 50% centre point on the scale divides 'inadequate' from 'adequate' controls, although that only really applies in the context of a mythical generic mid-sized organization with minimal information risks and hence security requirements. For many commercial organizations, 60% may be a more appropriate target, varying between organizations and controls - e.g. a financial services organization is likely to have more substantial information risks and hence needs stronger controls to ensure confidentiality, integrity and availability of information, than a typical manufacturing or retail business; an engineering design firm may value data integrity above all else, given the health and safety implications and liabilities if its output is inaccurate.   
Looking back over the draft checklist, I've noticed that the scores for most controls correlate with 'assurance' activities. At the top end, 100% scores often involve strong assurance measures such as thorough, independent audits by competent auditors. At the bottom end, assurance measures are conspicuously absent: if it's not painfully obvious already, even a cursory check would no doubt reveal that the controls are either completely absent or totally inadequate, but checking simply isn't performed at the 0% level - in fact, it probably doesn't even occur to those involved. 
In the middle ground, assurance activities either drive systematic improvements where necessary, or increase confidence that the controls in place are sufficient - fit for purpose, of decent quality, doing a good job.
Therefore, assurance appears to be a universal KPI, a Key Performance Indicator that would be applicable and valuable to almost any organization that seeks to measure and improve the quality and maturity of its approach to information risk and security management. 
Assurance is an over-arching control on a higher conceptual plane than most information security controls. The benefits of assurance include:
  • Checking to ensure that the right things are being done, and things are being done right;
  • Investigating and evaluating things, digging deeper than otherwise occurs and challenging the status quo;
  • Hopefully generating credible evidence to demonstrate or prove that, making it possible for the organization's management, owners and other internal or external stakeholders to increase their confidence and trust that the organization is soundly governed, managed, operated and controlled;
  • Generating insight such as improvement suggestions, as a result of the investigation, analysis and discussion arising;
  • Spreading good practices, especially if those performing assurance activities are highly experienced and competent across a broad range of industries, organizations and situations.
So, becoming good at assurance drives the organization to a better place.
Other universal KPIs might also be relevant to information risk and security, such as:
  • Oversight - the middle and junior management equivalent to assurance, watching over, guiding and monitoring activities in a more hands-on fashion;
  • Information risk management practices, especially within a systematic, structured framework such as ISO27k, SP800-53, COBIT or NIST CSF incorporating information security management, incident management, compliance management and business continuity management as well;
  • Measurement practices - the very act of focusing on stuff that is important enough to be worth measuring tends to achieve improvements, hence the importance of designing/selecting and implementing appropriate metrics (including sensible KPIs by the way!);
  • Formalization, for example policies, procedures, guidelines, awareness and training all being managed proactively as a coherent and coordinated suite of activities that business people find beneficial rather than sheer red tape;
  • Compliance - involving both reinforcement of required practices and enforcement of the rules, which implies the need for clearly defined rules and the associated checking and motivational activities (assurance again).

    * I'm aware that not all of the ISO/IEC 27002 controls may be applicable to any organization, and that other controls may be required - in fact, I'm using ISO 22301 as a guide to business continuity controls in place of '27002's pathetic section 17, and I may use CSF or other standards on cloud controls to supplement/extend '27002 section 15. The scoring checklist needs to be considered, adapted and applied sensibly according to the context ... but, trust me, it's much easier, quicker and more effective to start with this guidance than a blank sheet!  If you'd like the completed checklist, please get in touch.
    Categories: NoticeBored

    NBlog Dec 11 - risk treatments

    NoticeBored - Tue, 12/10/2019 - 2:00pm


    Yesterday I wrote about what the White Island eruption teaches us about risk management, in particular the way we decide how to deal with or "treat" identified risks. 
    ISO/IEC 27005 describes 4 risk treatment options:
    1. Avoid the risk by deliberately not getting ourselves into risky situations - not getting too close to a known active volcano for example;
    2. Modify the risk: typically we mitigate (reduce) the risk through the use of controls intended to reduce the threats or vulnerabilities and hence the probability, or to reduce the impacts;
    3. Retain the risk: this is the default - more on this below;
    4. Share the risk: previously known as "risk transfer", this involves getting the assistance of third parties to deal with our risks, through insurance for instance, or liability clauses in contracts, or consultants' advice.
    Risk management standards and advisories usually state or imply that these 'options' are exclusive, in other words alternatives from which we should choose just one treatment per risk. ISO/IEC 27005 says "Controls to reduce, retain, avoid, or share the risks should be selected". In fact, they are nonexclusive options since they all involve an element of risk retention. The sentence should perhaps read "Controls to reduce, retain, avoid, and share the risks should be selected".*
    Risk retention is inevitable because of the very nature of risk. We can never be totally certain of risk, up to the point that the probability reaches 1 when an incident occurs (which, arguably, means it is no longer a risk but a certainty!). We might have misunderstood it, or made mistakes in our analysis. Our risk treatments might not work out as expected, perhaps even failing spectacularly when we least expect it, or conversely working so well that the risk never eventuates. Our insurers and partners might renege on the deal, and consultants (including me, right now) might give bad advice. The threats, vulnerabilities and impacts are all dynamic, complex and partially unknown: geologists speak of 'eruption hazards' predicted to affect areas of varying size, but 'predict' is misleading. They can calculate the probability of various volcanic and seismic events occurring, but not with sufficient precision to be of short-term use in planning trips.
    The upshot is that a retained risk is still a risk: with a residual level of risk, we should bear in mind that incidents might still occur. 'Risk acceptance' is no longer the preferred term since it subtly implies that the risk has gone, whereas some is retained, whether knowingly or not. Whether the implications are truly understood when we make risk treatment decisions is uncertain ... and, yes, that means risk management itself is risky.
    * There are other problems with that sentence. In the information risk context, 'control' is generally used and understood to mean 'information security control' specifically: risk avoidance and especially retention would not normally be considered forms of control. Also, merely 'selecting' options achieves nothing: for all except risk retention, things need to be done subsequently if those decisions are to have any effect, and even retention generally ought to be documented, especially if the retained risks are significant - like, for instance, an adventure tourist signing to confirm their acknowledgement of the hazards ahead and clarify their personal accountability for the decision to proceed.
    Categories: NoticeBored

    NBlog Dec 10 - a brutal lesson in risk management

    NoticeBored - Mon, 12/09/2019 - 2:14pm
    Yesterday's volcanic eruption on White Island is headline news around the globe, a tragedy that sadly resulted in several deaths, currently estimated at 13.  
    Also, yesterday in NZ there were roughly 90 other deaths (as there are every day), roughly two thirds of which were caused by cardiovascular diseases or cancer:

     
    So, yesterday, the proportion of deaths in NZ caused by "Natural disasters" spiked from 0% to 13%. Today, it is likely to fall back to 0%. 
    "Natural disasters" will have caused roughly 0.04% of the ~33,500 deaths in NZ during 2019 ... but judging by the news media coverage today, you'd have thought NZ was a disaster zone, a lethal place - which indeed it is for ~33,500 of us every year. Very very few, though, expire under a hail of molten rock and cloud of noxious fumes, viewable in glorious Technicolor on social media.
    Those 13 tourists who perished yesterday chose to see NZ's most active volcano up close, real close. You may be thinking "Ah but if they'd known it would erupt, they wouldn't have gone" ... but they did know it was a possibility: for at least some of the 13, that was the very reason they went. It's euphemistically called "adventure tourism". The possibility of death or serious injury is, perversely, part of the attraction, the thrill of it. Recent warnings from geologists about the increased threat of eruption on White Island would, I'm sure, have been carefully considered by the tourist companies involved, plus I guess they may have noticed changes in the amount of steam and sulfur lingering in the air. Tourists are explicitly warned about the dangers and instructed on the safety aspects. I gather one of the dead was a local, an employee of the tourist company. Aside perhaps from the geologists, it's hard to think of anyone more aware of the risk.
    Having weighed-up the risks and rewards, the 13 enjoyed an amazing spectacle, doing the equivalent of 'clicking the go-away button' to dismiss computer security warnings despite facing, in their case, the ultimate impact. While I suspect their final moments would have been literally petrifying, hopefully the extra-special buzz leading up to it made it worthwhile. At that point, having made their decision to go, they were committed to their fate.
    No doubt those who escaped the island alive will be thinking themselves lucky. They 'cheated death', coming as close as possible to being wiped-out ... and I'm sure they'll be telling everyone they can about it, some excitedly spreading the idea that near-death experiences are the ultimate thrill. The grieving relatives and friends of the dead, on the other hand, will have plummeted into the pit of despair, a very introspective and sad place. Some might be spreading the word that "adventure tourism" is lethal and crazy, but do you honestly think this incident will materially change the way it is promoted and advertised in future? Will "adventure tourism" and "extreme sports" operators go bust in short order?
    Conceivably, some tourists decided not to take the fateful trip yesterday on safety grounds, or because they determined that it was "too expensive" and hence "not worth it". Although usually framed as a value judgment, to me that's a risk decision. Clearly they chose correctly, regardless of their analysis. The risk outweighed the benefits. I'd be interested to learn more about their thought processes.
    So there we have it: ultimate impact or ultimate thrill. The uncertainty is part of the package, part of the attraction for some. It's something I've seldom seen discussed in relation to information risk, specifically, although risk-acceptance is part of the professional lexicon. There are legitimate business reasons for knowingly getting into risky situations. We advise and assist our corporate colleagues to identify and evaluate the risks, to reduce them where cost-effective and prepare to deal with incidents and disasters when they eventuate. Risk, incident, disaster, safety and business continuity management are all part of the same process. Risk avoidance is often a viable option, one that should not be simply dismissed out of hand. There's a reason that "wise old men" are old.
    Categories: NoticeBored

    NBlog Dec 9 - ISO27k security awareness

    NoticeBored - Mon, 12/09/2019 - 1:47am
    Our two-hundred-and-first security awareness module concerns the ISO27k standards.
    ◄ The quotation from ISO/IEC 27000 is right on the button: information is worth securing because it's valuable, essential in fact. Inadequately protected organizations hit by ransomware incidents know that only too well, with hindsight ... which is of course 20/20 ...
    ... And that reminds me: as the NoticeBored service draws to a close, I'd like to think we'll be leaving the world in a better state in 2020, but to be honest we've made little impression. 
    Pundits have long advised that security awareness is important. An increasing proportion now recommend regular awareness activities. A few even suggest a continuous or ongoing approach. Perhaps they've been listening. I've been banging that drum for 20 years.
    As we hand over the reins, I hope the information security management and awareness pros will finally come to recognize the value of not treating their awareness audience as one amorphous blob, disparagingly called "users". As far as I know, NoticeBored remains unique in addressing two discrete audiences within "users" (we much prefer the term "workers") with distinct information needs: managers and professionals. Given their markedly different concerns and responsibilities, its hardly surprising (to me!) that they find little of value in conventional security awareness content and fail to participate in the usual awareness activities. They are largely disinterested and disengaged, substantially weakening the organization's security culture, like a three-legged milking stool missing two of its legs. 
    ISO/IEC 27002:2013 section 7.2.2 takes a page to say not very much about security awareness: I must take a close look at the awareness section in the draft update to '27002, currently extruding its way through the ISO/IEC sausage machine towards publication at the end of 2021. 
    Categories: NoticeBored

    NBlog Dec 3 - infosec driving principles

    NoticeBored - Mon, 12/02/2019 - 11:12pm
    In an interview for CIO Dive, Maersk's recently-appointed CISO Andy Powell discussed aligning the organization with these five 'key operating principles':"The first is trust. The client has got to trust us with their data, to trust us to look at their business. So we've got to build trust through the cybersecurity solutions that we put in place. That is absolutely fundamental. So client trust, client buy-in has been fundamental to what we tried to drive as a key message. The second is resilience. Because you've got to have resilient systems because clients won't give you business if you're not resilient ... The third really is around the fact that security is everybody's responsibility. And we push that message really hard across the company … be clear about what you need to do and we train people accordingly. ...The fourth one really is accountability of security and I have pushed accountability for cyber risk to the business. ... And the final piece, and this has been one of the big call outs of my team to everybody, is that security is a benefit, not a burden. The reason I say that is people's perception is that security will slow things down, will get in the way ... the reality is that if you involve security early enough, you can build solutions that actually attract additional clients."Fair enough Andy. I wouldn't particularly quarrel with any of them, but as to whether they would feature in my personal top-five I'm not so sure. Here are five others they'd be competing against, with shipping-related illustrations just for fun:
    • Governance involves structuring, positioning, setting things up and guiding the organization in the right overall direction - determining then plotting the optimal route to the ship's ultimate destination, loading up with the right tools, people and provisions. Corporate governance necessarily involves putting things in place for both protecting and exploiting information, a vital and valuable yet vulnerable business asset;
    • Information is subject to risks that can and probably should be managed proactively, just as a ship's captain doesn't merely accept the inclement weather and various other hazards but, where appropriate, actively mitigates or avoids them, dynamically reacting and adjusting course as things change;
    • Flexibility and responsiveness, along with resilience and robustness, present more options, opportunities to make the best of whatever situations occur, including novel hazards that weren't anticipated. If the Titanic's captain hadn't been steaming quite so fast through icy seas at night, or had thought further ahead, or was at the helm of a more nimble vessel, maybe he could have turned hard enough to avoid the iceberg that ripped open the hull of his supposedly unsinkable and apparently difficult to steer ship;
    • Making the best of available resources implies a blend of knowledge and skills, particularly in leadership and motivation of people: people remain central to information risk and security management. Even as technology grows in importance within information security, it's more tool than device. In the hands of a master mariner, a sextant becomes a valuable instrument rather than an ornament;
    • Assurance is a valuable product of oversight, monitoring, testing, reviewing and auditing activities, allowing management as well as third parties to have faith in the information risk and security management arrangements. The extent and quality of assurance activities correlates strongly with an organization's capabilities and maturity, largely because assurance supports the need for improvements and demonstrates progress.  That seaworthiness certificate isn't just a ticket to leave port: it gives confidence that things are in order down below.
    Categories: NoticeBored

    NBlog December - social engineering awareness module

    NoticeBored - Thu, 11/28/2019 - 11:22pm

    December 2019 sees the release of our 200th security awareness and training module on social engineering. This was planned to coincide with the end of year holiday period - peak hunting season for social engineers on the prowl, including those portly, bearded gentlemen in red suits, allegedly carrying sacks full of presents down chimneys. Yeah right!I'm fascinated by the paradox at the heart of social engineering. Certain humans threaten our interests by exploiting or harming our information. They are the tricksters, scammers, con-artists and fraudsters who evade our beautiful technological and physical security controls, exploiting the vulnerable underbelly of information security: the people. At the same time, humans are intimately involved in protecting and legitimately exploiting information for beneficial purposes. We depend on our good people to protect us against the bad people.Vigilance is often the only remaining hurdle to be overcome, making security awareness and training crucial to our defense. It’s do or die, quite literally in some cases! The module concerns information risks, controls and incidents involving and affecting people:
    • Various types of social engineering attacks, scams, cons and frauds – phishing being just one of many topical examples;
    • 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 social engineer’s tradecraft i.e. pretexts, spoofs, masquerading, psychological manipulation and coercion.
    While there are many indiscriminate scams and cons in operation, most are relatively minor (except, perhaps, ransomware). However, social engineering attacks and frauds specifically targeting the organization through its workforce are of greater concern. Adversaries who patiently research us and our people through social media and social networks stand a better chance of gaining our trust, reducing our wariness of unknown people and unusual requests, so catching us off-guard. Our being cautious about what we reveal to outsiders makes their task that bit harder, a subtle but effective control.Creative scammers are developing ever more sophisticated attacks, sometimes combining hacking, malware, physical site penetration and social engineering methods. Business Email Compromise, for instance, is highly lucrative, some attacks netting tens of millions of dollars by tricking professionals into making fraudulent payments from corporate bank accounts, bypassing the normal checking and authorization controls due to some trumped-up emergency situation. Tricking them into installing malware or changing payee account numbers are just two of their cunning tricks.




    I'm especially pleased with these three A-to-Z guides covering social engineering scams, techniques and controls respectively - aneat set with plentyof meaty content in
    an engaging format.




    Buy the materials today at SecAware.com and download them instantly: all our content is electronic, provided as MS Office files mostly, so that you can customize and adapt them to suit your specific needs. If you don't like our logo, swap it for yours. If our version of a social engineering policy doesn't quite work for your organization, hack it about as much as you like.
    Categories: NoticeBored

    NBlog Nov 28 - risks, dynamics and strategies

    NoticeBored - Wed, 11/27/2019 - 2:16pm

    Of information risk management, "It's dynamic" said my greybeard friend Anton Ayward - a good point that set me thinking as Anton so often does.
    Whereas normally we address information risks as if they are static situations using our crude risk models and simplistic analysis, we know many things are changing ... sometimes unpredictably, although often there are discernible trends.
    On Probability-Impact Graphs (PIGs), it is possible to represent changing risks with arrows or trajectories, or even time-sequences. I generated an animated GIF PIG once showing how my assessment of malware risks had changed over recent years, with certain risks ascending (and projected to increase further) whereas others declined (partly because our controls were reasonably effective).



    It's tricky though, and highly subjective ... and the added complexity/whizz-factor tends to distract attention from the very pressing current risks, plus the uncertainties that make evaluating and treating the risks so, errrr, risky (e.g. I didn't foresee the rise of cryptomining malware, and who knows what novel malware might suddenly appear at any time?).
    A simpler approach is to project or imagine what will be the most significant information risks for, say, the year or two or three ahead. You don't need many, perhaps as few as the "top 5" or "top 10", since treating them involves a lot of work, while other risks are often also reduced coincidentally as controls are introduced or improved. It's possible to imagine/project risks even further out, which may suit a security architectural development or strategic planning approach e.g. planning to implement biometrics in a few years' time to address increasing requirements for worker authentication.
    Another aspect of strategic planning for information risk and security management is that the risk modelling, analysis, treatment and projections are all inherently uncertain, therefore taking us into the realm of resilience and contingency thinking as I said yesterday. An ISO27k Information Security Management System (or, in fact, any structured approach to managing the corporation's risks) that helps the organization cope with an uncertain future is an asset, whereas one that rigidly restricts its options may turn out to be a liability if things don't quite go to plan.
    The point of this ramble, prompted by Anton's throwaway yet insightful comment about dynamics, is the need to consider both the 'here and now' and the future - even if you find yourself still desperately trying to catch up with the past!
    Categories: NoticeBored

    NBlog Nov 26 - 7 ways to improve security awareness & training

    NoticeBored - Mon, 11/25/2019 - 11:55pm
    Although 7 Ways to Improve Employee Development Programs by Keith Ferrazzi in the Harvard Business Review is not specifically about information security awareness and training, it's straightforward to apply it in that context. The 7 ways in bold below are quoted from Keith's paper, followed by my take.
    1. Ignite managers’ passion to coach their employees.  I quite like this one: the idea is to incentivize managers to coach the workforce. As far as I'm concerned, this is an inherent part of management and leadership, something that can be enabled and encouraged in a general manner not just through explicit (e.g. financial) incentives. For me, this starts right at the very top: a proactive CEO, MD and executive/leadership team is in an ideal position to set this ball rolling on down the cascade - or not. If the top table is ambiguous or even negative about this, guess what happens! So, right there is an obvious strategy worth pursuing: start at, or at the very least, include those at the very top of the organization ... which means taking their perspectives and addressing their current information needs, preferred learning styles and so forth (more below: directors and execs are - allegedly - as human as the rest of us!).
    2. Deal with the short-shelf life of learning and development needs. 'Short shelf-life' is a nice way to put it. In the field of information risk and security, the emergence of novel threats that exploit previously unrecognized vulnerabilities causing substantial business impacts, is a key and recurrent challenge. I totally agree with the need to make security awareness an ongoing, ideally continuous activity, drip-feeding workers with current, pertinent information and guidance all year long rather than attempting to dump everything on them in a once-in-a-blue-moon event, session or course. Apart from anything else, keeping the awareness materials and activities topical makes them more interesting than stale old irrelevant and distracting junk that is 'so last year' (at best!).
    3. Teach employees to own their career development. An interesting suggestion, this, especially for the more involved infosec topics normally taught through intensive training courses rather than general spare-time awareness activities. I'm not sure off-hand how this suggestion would work in practice, but it occurs to me that periodic employee appraisals and team meetings provide ample opportunities to offer training and encourage workers to take up whatever suits their career and personal development aspirations.
    4. Provide flexible learning options. This hardly needs saying, does it? Maybe it is news to some that 'on demand' learning can usefully exploit workers' free-time, filling-in odd moments in the working day that would otherwise go to waste.  It's not quite as simple as that in that the awareness and training content should be appealing, engaging and worthwhile for the individuals to encourage them to participate, which in turn means it ideally needs to be developed by creative professionals with a good appreciation of both the audiences and the learning content. There's more to it than making stuff 'accessible'.
    5. Serve the learning needs of more virtual teams. For me, this goes hand-in-hand with suggestions 1 and 4. 'Virtual teams' comprised of geographically-dispersed social groups present both opportunities and challenges for security awareness and training, especially if you accept that 'the virtual team' extends way beyond the organization these days.
    6. Build trust in organizational leadership. Keith asserts provocatively that "People crave transparency, openness, and honesty from their leaders. Unfortunately, business leaders continue to face issues of trust". Hmmmm. If true (and I'm not at all sure I accept that, at least not as a general statement of fact), it undermines all aspects of management and leadership, not just security awareness, making this a more fundamental and potentially very serious issue for corporations. On the other hand, Keith's suggestion to “lead by example” is sound, regardless of how deep the issues go. For me, this is another inherent part of management, leadership and motivation - a word that is conspicuously and curiously absent from the HBR article. Openly addressing "What's in it for me?" is an obvious means of motivating people, especially if coupled with both enforcement and reinforcement - in other words, don't just threaten to hammer people for doing the wrong things, entice them to do the right things though rewards and incentives of all sorts (again, not just financial). 
    7. Match different learning options to different learning styles. It is hardly rocket-surgery to suggest that individuals vary in their preferred 'learning styles', and although Keith only refers to Millennials using "cell phones, computers, and video games consoles", it's not hard to interpret this advice much more openly. For example, some people prefer to discover/learn stuff by reading, others by being told, others by doing. Some of us consider stuff before either accepting and internalizing it, or rejecting it, or (as with this blog piece) adapting and incorporating information and advice into a broader framework known as 'experience'. Some prefer to be told, simply and straightforwardly (and in far fewer words than this blog) what to do or not to do (lists of up to seven items for instance ...), and may only engage to the extent necessary to read the instructions, or view a diagram. Some "don't have the time for this", and some of us just love to explore the topic at our leisure. A few naturally resent being told to do anything and will rebel ... unless they are persuaded that it's in their best interests to comply (which can be tough!). Most of us have our interests and concerns, plus our non-interests and unconcerns, and we all differ, hence any attempt to offer a one-size-fits-all approach to security awareness and training is (I believe) doomed to failure.
    Categories: NoticeBored

    NBlog Nov 22 - who owns compliance?

    NoticeBored - Thu, 11/21/2019 - 5:51pm
    For some weeks now on the ISO27k Forum we've been vigorously and passionately debating whether an Information Security Management System should, or should not, include the organization's compliance with "information security-related" laws, regulations and other obligations such as contractual clauses specifying compliance with PCI-DSS.
    The issue arises because:
    • The relevant infosec compliance section is tucked away at the end of ISO/IEC 27001 Annex A, which has an ambiguous status with respect to '27001 certification. Although Annex A is discretionary rather than mandatory, certifiable organizations must use Annex A as a checklist to confirm that their ISMS incorporates all the information security controls necessary to address the information risks within scope of the ISMS. Interpret that paradox as you will ... and hope that the certification auditors take the same line;
    • It could be argued that, in a very broad sense, all the laws, regs, contracts, standards, ethical codes etc. which apply to the organization are "information security-related". The requirements are all forms of information with associated information risks. Therefore, they fall at least partially within the remit of an ISMS;
    • Likewise, "compliance", as a whole, could be seen as an information security control, a suite of organizational activities and measures to both satisfy and be able to demonstrate conformance with requirements, plus the associated assurance, reinforcement (awareness, acceptance) and enforcement aspects. In philosophical terms, compliance is an integrity issue, and integrity is part of information security, therefore compliance is part of infosec; 
    • However, most organizations either fail to identify and manage some of these risks and opportunities, or choose to manage them in other ways, for example through Legal and Compliance or Internal Audit departments. In practice, compliance with, say, the accounting and tax laws, or the health and safety regs, falls largely to the respective departments, teams and individuals who specialize in those areas. There is limited involvement of the information risk and security pro's, for example advising on the need for integrity, access and backup controls for the financial systems. In the event of conflict among the specialists, issues should be escalated to management, hopefully without blood being drawn, even if heads need to be knocked together to get things resolved.
    The “mandatory ISMS documents” paper in the free ISO27k Toolkit draws distinctions between documentation that is:
    1. Formally and explicitly required by '27001 - the documentation that is clearly mandatory for certification, reading the standard as strictly as I guess a lawyer might read it [IANAL!]; 
    2. Informally implied by ‘27001 - additional evidence that, in practice, is typically used to demonstrate to the certification auditors that all the standard's requirements are fully satisfied;
    3. Potentially required by the organization, not by the standard as such, to direct, operate and control the ISMS according to business objectives.
      At one end of the scale, the ‘keep it simple’ approach to designing and implementing an ISMS emphasizes (1): if ‘being certified’ is the prime focus, the purpose of having an ISMS at all, then doing the absolute bare minimum to achieve that with as little as possible of (2) and (3) helps achieve that specific aim as quickly and cheaply as possible. The end result, as I see it, is a minimalist ISMS that satisfies the standard but only just. The business value to the organization arises more from having the compliance certificate than from the ISMS itself. For some organizations, that’s good enough, job done. Well OK it's a starting point: it may evolve from there.
      At the other end of the scale, the pure ‘business-driven’ approach emphasizes (3): regardless of what the standard demands or expects, the purpose of a business-driven ISMS is to support and enable the business to manage its information risks and security controls. The end result, as I see it, could be a bloated ISMS, bigger and more complex than the minimalist version.
      There are risks associated with both approaches:
      • An extremely minimalist ISMS might run into trouble with certain certification auditors who interpret the standard differently and hence demand more of (2) and (3) than what the organization believes it needs to do for compliance. It also might not earn its keep and fail, for example if the compliance certificate turns out to be an asset of little value, perhaps even a liability if the limitations of the extreme minimalist approach come to light. It could be a dog!
      • A bloated ISMS might experience conflict between ‘doing what’s best for the business’ and ‘doing what is demanded by the standard’, and hence might not be certifiable. Being bigger and more complex also implies greater risks: the ISMS might lose focus and direction. It too might fail. It could be a monster!
      So, personally, I prefer an approach part way between those extremes: do whatever the standard requires or implies, plus whatever extras suit the organization’s objectives and can be justified on business grounds. It seems to me a pragmatic ISMS should:
      • Sail through the certification audit, since it more than satisfies the mandatory requirements; 
      • Exploit the sage advice offered by '27001 and other standards (ISO27k plus whatever); 
      • Exploit and supplement/support the expertise elsewhere in the organization, building effective working relationships with assorted experts and managers on compliance and other matters; 
      • Incorporate joint rather than sole control in areas where the ISMS scope overlaps other functions, working collaboratively together towards shared business goals, addressing the bigger picture (a governance issue); 
      • Have a long-term future, since it also addresses broader business objectives relating to the systematic management of information risk and security; 
      • Do all that in a businesslike manner - cost-effectively, with strong governance and priorities that align with the organization's objectives and values. 
      Business alignment is, as I see it, key to the long-term success of the ISMS and, naturally, I have plenty more to say on that!
      For now I'll end by mentioning three other specialist areas that intersect the ISMS scope: IT, risk and business continuity. The issues are much the same as with compliance.
      Categories: NoticeBored

      NBlog Nov 18: enough is enough

      NoticeBored - Sun, 11/17/2019 - 7:06pm
      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.
      Categories: NoticeBored