Welcome to NBlog, the NoticeBored blog

I spy with my beady eye ...

Jan 18, 2020

NBlog Jan 18 - business discontinuity



As if following a cunning plan (by sheer conicidence, in fact) and leading directly on from my last two bloggings about business continuity exercises, Belgian manufacturing company Picanol suffered a ransomware infection this week, disabling its IT and halting production of high-tech weaving machines at its facilities in Ypres, Romania and China.



Fortunately, Picanol's corporate website is still up and running thanks to Webhosting.be, hence management was able to publish this matter-of-fact press release about the incident:






Unsurprisingly, just a few short days after it struck, technical details about the "massive ransomware attack" are sparse at this point. The commercial effects, though, are deemed serious enough for trading in its shares to have been suspended on the Brussels bourse. 

There's already plenty of information here for a case study in February's awareness module. Through a brief scenario and a few rhetorical questions, we'll prompt workers to consider the implications both for Picanol and for their own organizations. If a similar malware incident occurred here, knocking out IT and production for at least a week, what would be the effects on workers, the company, its customers and other stakeholders? How should management respond, after such an incident ... and what can be done now to reduce the risks?

Normally our case studies are designed for the general staff awareness audience. This one, however, appeals to the management and tech/specialist audiences too, with only minor changes of emphasis in the questions to prompt discussion and learning.

I'm sad to say that Picanol and Travelex are not the only recent newsworthy incidents involving malware: ransomware in particular is a 'real and present danger' right now. For security awareness purposes in general, regardless of the specific topics, we rarely struggle to find relevant incidents to discuss ... largely because we choose awareness topics that are topical. It's not always quite so easy for topics such as APT malware (Advanced Persistent Threats), insider threats, industrial and commercial espionage, or other incidents that are normally kept quiet by victims, but somehow we've always managed.

Jan 17, 2020

NBlog Jan 17 - live-fire continuity exercises

Yesterday I blogged about the advantages and disadvantages of business continuity exercises. Today's topic concerns the alternative approaches, in particular the idea of 'live-fire' exercises in the business continuity context.

Vast tracts of prime agricultural land are set aside as military training grounds, allowing the armed forces to practice their maneuvers and, sometimes, fire actual bullets, mortars, missiles and bombs. Real ones, not dummies. 

There are, of course, certain health and safety risks associated with weapons (!), so why take the risks? What are the benefits of not using blanks and simulations?

Two obvious reasons are:
  1. To test, prove and improve the weapons, for example confirming the accuracy, range and effectiveness of a field gun firing live rounds towards a tank, building or bunker, with gusting cross winds, challenging terrain, engineering and operational variables.
  2. To practice, test, prove and improve the soldiers' capabilities, including dealing with the very real safety concerns when their weapons are locked and loaded.
These are still exercises, though, somewhat removed from genuine action on the battle grounds of, say, the middle East ... and it could be argued that even those are merely limited-scope live-fire exercise in preparation for for all-out global warfare.

So do we have the equivalent of live-fire exercises in the business continuity context? Yes, there are at least two types: 
  1. Actual incidents that occur routinely within the organization, ranging from frequent minor events up to the occasional more serious incidents, if somewhat removed from genuine disasters thanks, in part, to the incident management and disaster mitigation activities. Hopefully all that preparation and exercising pays off! It's straightforward for a responsible manager to "declare an emergency", initiating the disaster management activities even though that may not be strictly justified by the exact circumstances. From that point, turning the incident into an exercise may simply be a matter of going through the motions, perhaps simulating various facets that haven't been tested and proven lately. 
  2. Actual incidents that afflict other organizations. These can be valuable gifts in that we get to find out something about what actually happened under fire, without finding ourselves in the cross-hairs. 
A nice benefit of both approaches is that, unlike typical continuity exercises and just like real disasters, they are opportunistic, not pre-planned. They are unlikely to occur, conveniently enough, at the end of the working week before a long holiday weekend. Coping with the adrenaline rush of truly believing that a severe incident or disaster has actually occurred is an integral part of the event/exercise. The chaos and confusion are a step up from the usual cool, calm and collected exercises. True, there are risks too, but they are still less than the risks of being unprepared for incidents and disasters. Risk is relative not absolute, remember, and can seldom if ever be totally eliminated.

I'll have more to say about using third party incidents for awareness purposes tomorrow. Maybe later. Let's live on the edge.

Jan 16, 2020

NBlog Jan 16 - pros and cons of continuity exercises

Usually, business continuity-related exercises are very carefully planned in advance. Those directly involved are generally well aware of the impending events, often having a good idea if not explicit information about the timescale as well as the situation to be simulated. The more involved the exercise, and the longer the planning, the greater the leakage of information about it. The rumour mill grinds it out.

There are several good reasons for all that exercise pre-planning:

  • Preparing for exercises is also [at least partly] preparing for genuine incidents - a convenient [partial] alignment of objectives 
  • Planning improves the chances of 'success' - an important factor for those personally charged with overseeing, managing and conducting the exercises 
  • People and organizations confronted with an exercise scenario are less likely to panic, thinking and reacting as if it is a genuine incident, if they know about it in advance
On the other hand, the pre-planning has its drawbacks too:
  • People and organizations naturally focus on and prepare for the specific scenario/s planned, perhaps diverting resources from other aspects of preparedness that might be even more important/urgent
  • A pre-planned and anticipated exercise removes a substantial element of uncertainty that occurs in real incidents, begging questions such as "Is this an incident?", "What's going on?", "How serious is this?" and "Am I the only person who knows about this?"
  • "Success" in an exercise is not quite the same as "success" in a genuine incident - generally speaking, the stakes and hence the stresses are much higher, pushing systems, processes, individuals, organizations and communities to and in some cases beyond their breaking points, something that most exercises studiously avoid. It is conceivable for organizations to become highly accomplished at exercises, yet hopeless in actual incidents.
  • There may be adverse effects on operations if exercises go wrong, despite all the efforts to minimise the risks, whereas there certainly will be adverse effects in the case of actual incidents, especially those severe enough to warrant all this preparation, planning, exercising and so on. One consequence of this is that exercises tend to last a few hours or days at most, maybe a further few weeks for the wash-up meetings, reporting and note-taking for the next run. Genuine incidents typically last for weeks or months, with business and personal impacts that can easily last a year or more.
So, with that in mind, it is worth considering whether business continuity exercises are sufficient, in fact, in terms of both preventing or ameliorating incidents and gaining assurance that the arrangements will work properly when required for real.

I'll have more to say about this tomorrow, providing nothing disastrous happens in the meantime.

Jan 14, 2020

NBlog Jan 14 - a live case study

As we slave away on next month's security awareness module on malware, the Travelex ransomware incident rumbles on - a gift of a case study for us, our customers and for other security awareness pro's out there.

A quick glance at Travelex dotcom tells us that (as of this blogging) the incident is ongoing, unresolved, still a public embarrassment to Travelex that is presumably harming their business and their brand ... although having said that I've already mentioned their name three times in this piece. If you believe 'there's no such thing as bad publicity', then headline stories about the incident are all good, right?

Hmmm, leave that thought with me. Meanwhile, for the remainder of this piece, I'll call them "Tx" for short.

Technically speaking, the Tx dotcom website is up and running, serving a simple information page 'apologising for any inconvenience' [such as retail customers being unable to use the site to access Tx financial services in the normal fashion] and blaming 'a software virus': 



It refers to another Tx website which appears to be a legitimate Tx customer authentication page ... but, if it were me, given the incident I would be very dubious about submitting my credentials without first ascertaining that the site is legitimate, not simply part of the scam.

Anyway, the point is that they are at least on the Web, albeit a basic holding page, including their logo I notice. Without further information, we can only guess as to whether this page plus the associated webserver was hurriedly knocked together from scratch during the course of the incident, or was prepared in advance as part of a pre-planned incident response, perhaps customised a little and published when the evil ransomware struck. Likewise the separate login page.

Tx doctom is currently being served from an Amazon cloud, on an IP address shared by an eclectic collection of ~200 domains including:


Fair enough, there's no particular information security issue with cloud services and shared IPs, but it suggests that Tx's dedicated webservers and IP addresses are currently offline. In other words, the informational We've got a problem, Houston page is presumably being served from an alternative webserver ...

.... so what I'm doing now is building the case study, systematically piecing together whatever information I can glean or surmise about the incident, more importantly trying to figure out or plain guess what Tx may have done already and might now be doing in response to the incident. There are things to be pointed out, lessons to be learned here, lessons that hopefully don't involve the rest of us suffering an actual malware incident. For that, we should all be very grateful to Tx, and at the same time sad that they evidently didn't have the advantage of learning the hard lessons from the many unfortunate organizations that have suffered similar incidents before them. [Yes, there are lessons here for Tx too, plus their customers ... and I suspect they know that only too well right now, without our unsolicited input.]

That's still only a small part of preparing February's awareness content, an illustration based on one specific incident. Generalising from the Tx incident is the bulk of our work this month. We'll be elaborating on the things that typically occur during and follow after a major malware incident, highlighting the things that can and should probably have been done ahead of time.

Jan 6, 2020

NBlog Jan 6 - post-malware-incident notification & other stuff

A couple of days ago here on NBlog I wrote

"One screamingly-obvious lesson from the rash of ransomware incidents is that we need to anticipate malware infections when the preventive controls fail, which means strengthening the security protecting our business-critical systems and being ready to recover IT services and data efficiently following incidents." 

That's not all.

Anticipating that, despite all we do to prevent them, malware infections are still likely to occur implies the need for several post-event controls.  These are the kinds of controls I have in mind:
  • Reliable, efficient, effective, top-quality incident response and management processes - in particular, speed is almost always of the essence in malware incidents, and the responses need to be well-practiced - not just the run-of-the-mill routine infections but the more extreme/serious "outbreaks";
  • Decisive action is required, with strong leadership, clear roles and responsibilities, and of course strong awareness and training both for the response team and for the wider organization;
  • Clarity around priorities for action e.g. halt the spread, assess the damage, find the source/cause, recover;
  • Technological controls, of course, such as network segmentation (part of network architectural design), traffic filtering and (reliable!) isolation of segments pending their being given the all-clear;
  • Clarity around priorities for reporting including rapid escalation and ongoing progress updates, in parallel with the other activities;
  • Forensics, where appropriate, feasible and helpful (e.g. which preventive controls failed, why, and what if anything can be done to strengthen them);
  • Restoration and testing of backups, prioritizing key business processes and other cleanup efforts as part of ...;
  • ... Business continuity management;
  • Additional/heightened preventive and detective controls with alerts/alarms and rapid responses to further/reinfection - that jumpy phase when we think but aren't entirely certain that everything is resolved;
  • Stakeholder notification, with implications for exactly what can and should be said, to whom, when, how and by whom (taking account of the impacts on them, including compliance failures and business service interruptions);
  • Post-incident reviews to identify and learn the lessons once the dust has settled, making the best of a bad job by improving whatever can and should be improved for the future - part of systematic improvement.
Stakeholder notification is something one of our awareness customers raised, and something we intend to cover specifically in February's awareness materials ... and while we're at it, I figure there's plenty more mileage in the remainder of those bullet points above. Given that, sadly, this will be our final update to the malware awareness and training content, it seems fitting to end with something new on what needs to be done when (not if) malware incidents occur, our legacy if you will.

Jan 5, 2020

NBlog Jan 5 - plus ça change, plus c'est la même chose

Malware has clearly been an issue for a long time. It was prevalent enough to be the topic of our second NoticeBored security awareness module way back in July 2003. I've just dug the old NB newsletter out of the archive to see what's changed.  

In 2003, I wrote about viruses (macro, boot sector and parasitic types), Trojans, worms and logic bombs. Although other forms of malware were around back then, we elected to stick with the basics for awareness purposes. 

Getting on for 18 years later, we're taking a broader perspective. Today's workers need to know about spyware, BEC & VEC (Business/Vendor Email Compromise), phishing, infectious mobile apps and more. Actual computer viruses are practically unheard of now, although the term remains.

We're still concerned about preventive, detective and corrective controls, and malware risks that include data corruption - only now it's mostly deliberate in the form of ransomware rather than cybertage or bugs in the malware code.

The 2020 and 2003 newsletters have a very similar style with minor differences that only catch my eye because I wrote them, and I've been responsible for using and updating the format throughout. We've changed from Arial to Calibri font. Shouty "EMAIL" became calmer "email" at some point. The Hinson Tips on awareness migrated from the newsletter to the train-the-trainer guide, and the NoticeBored banner logo was smartened up. We have reverted from 'American English' to English spelling. The two-column newsletter format remains, though, despite the layout problems that has caused me over the years, particularly when I wanted to include full-page-width diagrams. I've learnt to overcome most of the limitations of MS Word but not always without grief! 

We have more actual news now, too, finding short but relevant news items on the web to push the point home that the information risks are not merely theoretical: actual incidents are occurring all the time. Finding quotable news clips is becoming harder, however, due to the spread of paywalls: it's simply not economic for us to subscribe to all the commercial sources we'd need to maintain a broad-based newsletter, so we're increasingly using soundbytes from blogs and social media rather than the traditional news media. 

Are you scouring this blog for quotable content for your security awareness newsletters, I wonder? If so, go ahead, be my guest!

Jan 4, 2020

NBlog Jan 4 - malware awareness update 2020

Our security awareness topic for February will be malware, malicious software - viruses, Trojans, worms, crytpminers, APTs, ransomware, spyware and Tupperware. 

Well OK, maybe not all of them: viruses are vanishingly rare these days.

An increasingly important part of the malware problem is the wetware: we humans evidently find it hard to sense and react appropriately to the dangers presented by infected messages, web pages and apps. Addressing that is a key objective of the awareness module, and quite a challenge it is given that the bad guys are forever coming up with new ways to conceal their intentions or trick us into doing something inappropriate. 

Digging a little deeper, I feel we also need to explain why we can't rely on antivirus software etc. to save the day because the baddies are also finding novel ways to evade the technological controls, despite the best efforts of the good guys in IT.

One screamingly-obvious lesson from the rash of ransomware incidents is that we need to anticipate malware infections when the preventive controls fail, which means strengthening the security protecting our business-critical systems and being ready to recover IT services and data efficiently following incidents. Another less-obvious lesson from incidents such as cryptominers, spyware, Vendor Email Compromises and Advanced Persistent Threats is that detecting infections in progress is harder than it appears ... and, again, it makes sense not to over-depend on detection. 

Taking that to its logical conclusion, what could/should we do if we presume the organization is currently infected by some sneaky malware? I'm talking about the malware element of counter-espionage, for example deliberately seeding false information, or creating situations designed to reveal 'moles in the camp'.

There we are then: malware issues to discuss with general employees, tech/specialists and management, respectively. Now all I need to do is prepare the content for those three streams and Bob's yer uncle!

Jan 3, 2020

NBlog Jan 3 - ISO27k business case published


I've just published the ISO27k business paper I wrote for the latest security awareness moduleIt elaborates on the typical business benefits and drawbacks of the ISO/IEC 27000 “ISO27k” information security management standards

It is the fourth revision, a complete re-write in fact of a generic business case paper I started roughly two decades ago. Since then, I've gained experience working with clients, chatting with participants in the ISO27k Forum, plus colleagues on the ISO/IEC committee writing and maintaining the ISO27k standards.

The new version deliberately takes a very broad perspective: ISO27k is not just about securing IT systems, networks and data ('cybersecurity') nor even 'information security'. It's really a governance structure for managing an organization's information risks systematically, in support of its business objectives. It's as much about exploiting as protecting information. ISO27k is a business-enabler.

Use it to construct your business case, budget request or project proposal to adopt ISO27k or, if you already have an Information Security Management System in operation, find ways to squeeze even more business value from it. 


Comments welcome.

Dec 31, 2019

NBlog January - ISO27k awareness & training materials


January's security awareness and training materials concern a topic I've been itching to cover for years, literally (the years part, not the itching ... thanks to the magic ointment).

I've been a user and fan of the ISO/IEC 27000 series standards since forever, before they were even conceived, even before BS 7799 was published.

From the original corporate security policy and 'code of practice' on information security (essentially a catalogue of information security controls), ISO27k has grown into a family of related standards, along the way assimilating a couple of other standards and, lately, expanding into privacy, eDiscovery, IoT, smart cities, big data and more.

Making sense of the bewildering scope of today's ISO27k was a particular challenge for this awareness module ...



... and of course ISO27k is not the only source of guidance out there ...



The module came together and turned out nicely ...


I'm especially pleased with how the ISO27k business case and metric (the 'universal KPI') turned out. They and the other awareness materials will serve double-duty in connection with our ongoing ISO27k consulting gigs.

The shiny new batch of ISO27k awareness content is available to download now at SecAware.com. It's our 70th information security awareness and training topic. Top that!

Dec 27, 2019

NBlog Dec 27 - Pakistan supports ISO27k


Through the Pakistan Software Export Board of the 
Ministry of IT & Telecom, the Pakistan government is subsidising 80% of the cost of consultants and auditors to advise and certify Pakistani IT companies against ISO 20000 (ITIL) and ISO/IEC 27001 (information security). With over 5,000 companies in Pakistan offering Business Process Outsourcing and IT services, this represent a substantial investment, reflecting the government's intention to raise standards in the industry. Good on them! If only other governments would follow their lead.