'Spotting incidents’ is the brand new security awareness and training module for April. It concerns vigilance, early detection and (where appropriate) prompt reporting of a  deliberately diverse and open-ended set of information-related incidents, concerns and risks ...   Whether you consider them to be incidents or not, suspicious activities and near-misses are also worth reporting if ‘early warning’ is something you and your management would appreciate. Nasty surprises are, well, nasty.  The sooner you know about trouble on the horizon, the more options you have, not least the possibility of deftly avoiding the minef ields ahead. Scope The awareness module concerns two critical early steps that kick-start the incident management cycle: We have cover ed the remainder of the incident management process before and will do so again - in fact every single awareness module concerns incidents since they are the very reason that information risks are of concern, and information...

Kaspersky has released information on Operation ShadowHammer , a malware/APT infection targeting ASUS systems with particular MAC addresses on their network adapters. According to a Motherboard report : "The issue highlights the growing threat from so-called supply-chain attacks, where malicious software or components get installed on systems as they’re manufactured or assembled, or afterward via trusted vendor channels. Last year the US launched a supply chain task force to examine the issue after a number of supply-chain attacks were uncovered in recent years. Although most attention on supply-chain attacks focuses on the potential for malicious implants to be added to hardware or software during manufacturing, vendor software updates are an ideal way for attackers to deliver malware to systems after they’re sold, because customers trust vendor updates, especially if they’re signed with a vendor’s legitimate digital certificate." And that, in a nutshell, is a concern with, ...

ITU X.1056 " Security incident management guidelines for telecommunications organizations " includes the following little nugget: Well said ITU-T! The idea of incorporating information about the organization's own incidents into the awareness program is something we suggest almost every month in the train-the-trainer guides for each security awareness module. Actual incidents naturally resonate with the audience, all the more so if they affected the organization directly. 

As far as incidents go, a core meltdown at a nuclear power plant is about as big as they come. This afternoon, I've been reading an official US report into the Fukushima incident following the Sendai tsunami eight years ago this month. " Lessons Learned from the Fukushima Nuclear Accident for Improving Safety of U.S. Nuclear Plants " is an excellent treatise on the incident, published just over three years afterwards. As you would expect from a formal report, the style is matter-of-fact, describing the sequence of events that unfolded as the tsunami struck, the plant was terminally damaged, the electrical supplies and hence the monitoring, control and communications systems all failed, and the operators went to heroic lengths to shutdown all the units. The scenario was so extreme that the well-practiced emergency operating procedures and fail-safe controls proved inadequate, leaving the operators firstly struggling to determine what was going on inside the reactor buil...

Yesterday I wrote about a five-part strategy to increase the number and quality of incident reports. The fifth part involves making both staff and management vigilant or alert for trouble. There is an obvious link here to the ongoing security awareness and training activities, pointing out and explaining the wide variety of threats that people should know about. Thanks to this month's awareness content on malware, for instance, workers should be in a better position to spot suspicious emails and other situations in which they are at high risk of picking up malware infections. Furthermore, they ought to know what to do when they spot threats - avoiding risky activities ( e.g. not opening dodgy email attachments or links) and reporting them. In April we have the opportunity to take that a step further. What could or should the organization do to empower (facilitate and encourage) alert workers to report the malware threats and other concerns that they spot? What's the best way t...

Working on the management seminar slide-deck over the past couple of days, we've developed and documented a coherent five-part strategy for improving both the speed and the accuracy of incident reporting. The strategy mostly involves changing the motivations and behaviors of both staff and management, possibly with some IT systems and metrics changes where appropriate to support the objectives. Elaborating on the background and those objectives explains what the strategy is intended to achieve: the slides and notes justify the approach in business terms, in effect outlining a business case . It's generic, of course, but providing it in the form of a management seminar plus supporting notes and briefings encouragescustomers to engage their managers in a discussion around the proposal, hopefully leading to consensus and agreement to proceed, one way or another. The nice thing about this is that it can't really fail: the very act of management considering and discussing the pr...

Incident reporting is a key objective of next month's security awareness module. More specifically, we'd like workers to report information security matters promptly.  So how might we achieve that through the awareness and training materials?  Possible approaches include: Tell them to report incidents. Instruct them. Give them a direct order. Warn them about not doing it. Perhaps threaten some form of penalty if they don't. Convince them that it is in the organization's interests for workers to report stuff. Persuade them of the value. Convince workers that it is in their own best interest to report stuff. Persuade them. Explain the reporting requirement ( e.g. what kinds of things should they report, and how?) and encourage them to do so. Make reporting incidents 'the easy option', and not reporting harder. Reward people for reporting incidents. Something else? Trick them? Goad them? Follow up on those who did not report stuff promptly, asking about their reas...

Last evening I turned on the TV to veg-out at the end of a busy week. Instead of my favourite NZ comedy quiz show, both main national channels were looping endlessly with news of the terrorist incident in Christchurch. Well I say 'news': mostly it was lame interviews with people tenuously connected to Christchurch or the Muslim community in NZ, and fumbling interviewers seemingly trying to fill air-time. Ticker-tape banners across the bottom of the screen, ALL IN CAPS, kept repeating the same few messages about the PM mentioning terrorism, yet neglected to say what had actually happened. I managed to piece together a sketchy outline of the incident before eventually giving up. Too much effort for a Friday night. I gather around 50 people died yesterday in the event. Also yesterday, about 90 other people died, and another ~90 will die today, and every day on average according to the official government statistics:   This year, some 6,000 Kiwis will die of heart disease, and bet...

Today being Pi day 2019 , think of the organization's suite of policies as a delicious pie with numerous ingredients, maybe a crunchy crust and toppings. Whether it's an award winning blue cheese and steak pie from my local baker, or a pecan pie with whipped cream and honey, the issue I'm circling around is how to slice up the pie. Are we going for symmetric segments, chords or layers? OK, enough of the pi-puns already, today I'm heading off at a tangent, prompted by an ongoing discussion around policies on the ISO27k Forum - specifically a thread about policy compliance. Last month I blogged about policy management. Today I'll explore the policy management process and governance in more depth in the context of information risk and security or cybersecurity if you will. In my experience, managers who are reluctant or unable to understand the [scary cyber] policy content stick to the bits they can do i.e. the formalities of 'policy approval' ... and that...

Over the past ~three or four decades, the information risk and security management profession has moved slowly from absolute security (also known as "best practices") to relative security (aka "good practices" or "generally-accepted security") such as ISO27k . Now as we totter into the next phase we find ourselves navigating our way through  pragmatic security (aka "good enough"). The idea, in a nutshell, is to satisfy local information risk management requirements (mostly internal organizational/business-related, some externally imposed including social/societal norms) using a practicable, workable assortment of security controls where appropriate and necessary, plus other risk treatments including risk acceptance.  The very notion of accepting risks is a struggle for those of us in the field with high standards of integrity and professionalism. Seeing the dangers in even the smallest chinks in our armor, we expect and often demand more. It c...

In the course of sorting out the license formalities for a new customer, it occurred to me that there are several different ways of reading stuff: Skimming or speed-reading barely gives your brain a chance to keep up with your eye as you quickly glance over or through something, getting the gist of it if you're lucky; Proof-reading involves more or less ignoring the content or meaning of a piece, concentrating mostly on the spelling, grammar etc. with a keen eye for misteaks, specificaly; Studying  is a more careful, thorough and in-depth process of reading and re-reading, contemplating the meaning, considering things and mulling-over the messages at various levels. In an academic setting, it involves considering the piece in relation to the broader field of study, taking account of concepts and considerations from other academics plus the reader's own experience that both support and counter the piece, the credibility of the author and his/her team and institution, the techn...

On the SecurityMetrics.org discussion form, Walt Williams posed a question about the value of 'time and distance' measures in information security, leading to someone suggesting that 'speed of response' might be a useful metric. However, it's a bit tricky to define and measure: exactly when does an incident occur? What about the response? Assuming we can define them, do we time the start, the end, or some intermediate point, or perhaps even measure the ranges? Incidents that are highly visible and obvious to all ( e.g. a ransomware attack at the point of the Denial of Service and ransom being demanded) are materially different from those that remain unrecognized for a long period, perhaps forever ( e.g. a spyware attack) even if otherwise similar (using very similar remote-control Trojans in those cases).   Detectability therefore might be a valuable third dimension to the classic P robability I mpact G raphs for assessing and comparing risks.   However, that s...

Malware ( mal icious soft ware ) has been a concern for nearly five – yes  five   – decades. It’s an awareness topic worth updating annually for three key reasons: Malware is ubiquitous – it’s a threat we  all  face to some extent (even those of us who don’t own or use IT equipment rely on organizations that depend on it); Malware-related risks are changing – new malware is being actively developed and exploited all the time, while technical security controls inevitably lag behind; Security awareness is vital to prevent or avoid malware infections, and to recognize and respond promptly and effectively to those that almost inevitably occur. Last year, we focused on crypto-currency-mining Trojans, and it was ransomware the year before that. Both remain of concern today. That’s the thing with malware: new forms expand the threat horizon. Much like the universe, it never seems to shrink. Developing engaging and accessible awareness and training content on the current sta...