Showing posts with label Hacking. Show all posts
Showing posts with label Hacking. Show all posts

Tuesday 12 March 2024

A nightmare on DR street


A provocative piece on LinkeDin by Brian Matsinger caught my beady eye and sparked my fertile imagination today. I'm presently busy amplifying the disaster recovery advice in NIS 2 for a client. When I say 'amplifying', I mean generating an entire awareness and training piece on the back of a single mention of 'disaster recovery' in all of NIS 2. Just the one. Blink and you'll miss it.

Oh boy.

Anyway, Brian points out that recovering from disasters caused by 'cyber attacks' requires a different DR approach than is usual for physical disasters such as storms, fires and floods. Traditional basic DR plans are pretty straightforward: essentially, the plans tell us to grab recent backups and pristine systems, restore the backups onto said systems, do a cursory check then release services to users. Job's a good 'un, off to the pub lads.

Sunday 16 July 2023

Internet security guidance

The second edition of ISO/IEC 27032 "Cybersecurity - Guidelines for Internet security" has just been published.

The introduction to the new edition commences:

"The focus of this document is to address Internet security issues and provide guidance for addressing common Internet security threats, such as:
— social engineering attacks;
— zero-day attacks;
— privacy attacks;
— hacking; and
— the proliferation of malicious software (malware), spyware and other potentially unwanted software."

Notice the standard is focused on "Internet security issues" which, in practice, means it covers active attacks perpetrated via the Internet. However:

Wednesday 26 April 2023

Using ChatGPT more securely

Clearly there are some substantial risks associated with using AI/ML systems and services, with some serious incidents having already hit the news headlines within a few months of the release of ChatGPT. However, having been thinking carefully and researching this topic for couple of weeks, I realised there are many more risks than the reported incidents might suggest, so I've written up what I found.

This pragmatic guideline explores the information risks associated with AI/ML, from the perspective of an organisation whose workers are using ChatGPT (as an example).  

Having identified ~26 threats, ~6 vulnerabilities and dozens of possible impactful incident scenarios, I came up with ~20 information security controls capable of mitigating many of the risks.

See what you make of it. Feedback welcome. What have I missed? What controls would you suggest? 

Tuesday 29 November 2022

Information risks a-gurgling

There are clearly substantial information risks associated with the redaction of sensitive elements from disclosed reports and other formats, risks that the controls don't necessarily fully mitigate.

Yes, controls are fallible and constrained, leaving residual risks. This is hardly Earth-shattering news to any competent professional or enlightened infidel, and yet others are frequently shocked. 

A new report* from a research team at the University of Illinois specifically concerns failures in the redaction processes and tools applied to PDF documents. The physical size of redacted text denoted (covered or replaced) with a variable-length black rectangle may give clues as to the original content, while historically a disappointing number of redaction attempts have failed to prevent the original information being recovered simply by removing the cover images or selecting then pasting the underlying text. Doh!

Monday 18 July 2022

Skyscraper of cards


Having put it off for far too long, I'm belatedly trying to catch up with some standards work in the area of Root of Trust, which for me meant starting with the basics, studying simple introductory articles about RoT.

As far as I can tell so far, RoT is a concept -  the logical basis, the foundation on which secure IT systems are built.

'Secure IT systems' covers a huge range. At the high end are those used for national security and defence purposes, plus safety- and business-critical systems facing enormous risks (substantial threats and impacts). At the low end are systems where the threats are mostly accidental and the impacts negligible - perhaps mildly annoying. Not being able to tell precisely how many steps you've taken today, or being unable to read this blog, is hardly going to stop the Earth spinning on its axis. In fact' mildly' may be overstating it.

'Systems' may be servers, desktops, portables and wearables, plus IoT things and all manner of embedded devices - such as the computers in any modern car or plane controlling the engine, fuel, comms, passenger entertainment, navigation and more, or the smart controller for a pacemaker

Trust me, you don't want your emotionally disturbed ex-partner gaining anonymous remote control of your brakes, altimeter or pacemaker.

In  terms of the layers, we the people using IT are tottering precariously on the top of a house of cards. We interact with application software, interacting with the operating system and, via drivers and microcode, the underlying hardware. A 'secure system' is a load of software running on a bunch of hardware, where the software has been designed to distrust the users and administrators, other software and the hardware, all the way down to, typically, a Hardware Security Module, Trusted Platform Module or similar dedicated security device, subsystem or chip. Ironically in relation to RoT, distrust is the default, particularly for the lower layers unless/until they have been authenticated - but there's the rub: towards the bottom of the stack, how can low-level software be sure it is interacting with and authenticating the anticipated security hardware if all it can do is send and receive signals or messages? Likewise, how can the module be sure it is interacting with the appropriate low-level software? What prevents a naughty bit of software acting as a middleman between the two, faking the expected commands and manipulating the responses in order to subvert the authentication controls? What prevents a nerdy hacker connecting logic and scope probes to the module's ports in order to monitor and maybe inject signals - or just noise to see how well the system copes? How about a well-appointed team of crooks faking a bank ATM's crypto-module, or a cluster of spooks figuring out the nuclear missile abort codes?

Physically securing the hardware is a start, such that if someone tries to - say - open ('decapsulate') the TPM chip to analyse the silicon wafer under an electron microscope in the hope of finding some secret key coded within, the chip somehow destroys itself in the process - perhaps also the warhead for good measure. 

Other hardware/electronic controls can make it virtually impossible for hardware hackers to mount side-channel attacks, painstakingly monitoring and manipulating the module's power supply and ambient temperature in an attempt to reveal its inner secrets.

Cryptography is the primary control, coupled with appropriate use of authentication and encryption processes in both hardware and software (e.g.'microcode' physically built-in to the TPM chip's crypto-processor), plus other inscrutable controls (e.g. rate-limiting brute force attacks and, ultimately again, sacrificing itself, taking its secrets with it).

Developing, producing and testing secure systems is tough, even with access to low-level debugging mechanisms such as JTAG ports and insider-knowledge about the design. There must be a temptation to install hard-coded backdoors (cheat codes), despite the possibility of 'some idiot' further down the line failing to disable them before products start shipping. There is surely a fascination with attempting to locate and open the backdoors without tripping the tripwires that spring open the trapdoors to oblivion.

OK, so now imagine all of that in relation to cloud computing, where 'the system' is not just a physical computer but a fairly loose and dynamic assembly of virtual systems running on servers who-knows-where under the control of who-know-who sharing the global Internet who-knows-how. 

Having added several extra floors to our house of cards, what could possibly go wrong? 

That's what ISO/IEC 27070:2021 addresses. 

At least, I think so. My head hurts. I may be coming down with vertigo.

Saturday 21 May 2022

Responsible disclosure - another new policy

We have just completed and released another topic-specific information security policy template, covering responsible disclosure (of vulnerabilities, mostly).

The policy encourages people to report any vulnerabilities or other information security issues they discover with the organisation's IT systems, networks, processes and people. Management undertakes to investigate and address reports using a risk-based approach, reducing the time and effort required for spurious or trivial issues, while ensuring that more significant matters are prioritised.

The policy distinguishes authorised from unauthorised security testing, and touches on ethical aspects such as hacking and premature disclosure.

It allows for reports to be made or escalated to Internal Audit, acting as a trustworthy, independent function, competent to undertake investigations dispassionately. This is a relief-valve for potentially sensitive or troublesome reports where the reporter is dubious of receiving fair, prompt treatment through the normal reporting mechanism - for instance, reporting on peers or managers.

It is primarily intended as an internal/corporate security policy applicable to workers ... but can be used as the basis for something to be published on your website, aimed at 'security researchers' and ethical hackers out there. There are notes about this at the end of the template. To be honest, there are plenty of free examples on the web but few if any are policies covering vulnerability disclosure by workers.

All that in just 3 pages, available as an MS Word document for $20 from SecAware.com.

I am working on another 2 new topic-specific policies as and when I get the time. Paradoxically, it takes me longer to prepare succcinct policy templates than, say, guidelines or awareness briefings. I have to condense the topic down to its essentials without neglecting anything important. After a fair bit of research and thinking about what those essentials are, the actual drafting is fairly quick, despite the formalities. Preparing new product pages and uploading the templates plus product images then takes a while, especially for policies that relate to several others in the suite - which most do these days as the SecAware policy suite has expanded and matured. As far as I know, SecAware has the broadest coverage of any info/cybersec policy suite on the market.

... Talking of which, I plan to package all the topic-specific policies together as a bulk deal before long. Having written them all, I know the suite is internally consistent in terms of the writing style, formatting, approach, coverage and level. It's also externally consistent in the sense of incorporating good security practices from the ISO27k and other standards.

Wednesday 11 May 2022

AA privacy breach -- policy update?

According to a Radio New Zealand news report today:

"Hackers have taken names, addresses, contact details and expired credit card numbers from the AA Traveller website used between 2003 and 2018. AA travel and tourism general manager Greg Leighton said the data was taken in August last year and AA Traveller found out in March. He said a lot of the data was not needed anymore, so it should have been deleted, and the breach "could have been prevented"."

The disclosure prompted the acting NZ Privacy Commissioner to opine that companies 'need a review policy':

"Acting Privacy Commisioner Liz Macpherson told Midday Report that if data was not needed it should be deleted ... Companies needed a review policy in place to determine if the data stored was neccessary, or could be deleted, Macpherson said."

So I've looked through our SecAware information security policies to see whether we have it covered already, and sure enough we do - well, sort-of. Our privacy compliance policy template says, in part:

"IT systems, cloud services and business processes must comply fully with applicable privacy laws throughout the entire development lifecycle from initial specification though testing, release, operation, management and change, to final retirement.  For example, genuine (as opposed to synthetic) personal information used during the development process (e.g. for testing) must be secured just as strongly as in production, and securely erased when no longer required."

The final clause in that paragraph refers to 'secure erasure' without specifying what that really means, and 'when no longer required' is just as vague as determining whether the data remains 'necessary'. That said, the remainder of the paragraph, and in fact the rest of the policy template, covers other relevant and equally important issues - including compliance with applicable privacy laws and regulations - such as GDPR.

Digging deeper, article 28 of GDPR requires that (in part):

"[the data processor] at the choice of the controller, deletes or returns all the personal data to the controller after the end of the provision of services relating to processing, and deletes existing copies unless Union or Member State law requires storage of the personal data".

Article 28 doesn't appear to say what the controller must do with any personal data returned by the processor [although I am NOT a lawyer!]. GDPR recital 39, however, says (in part):

"The personal data should be adequate, relevant and limited to what is necessary for the purposes for which they are processed. This requires, in particular, ensuring that the period for which the personal data are stored is limited to a strict minimum."

So, if GDPR applies, there appears to be a legal obligation to restrict the storage period of personal data to a 'strict minimum' ... and compliance with GDPR is covered by our privacy compliance policy template.

That said, I'm wondering now whether to update the SecAware policy statement above, expanding on the bold final phrase to give more explicit direction.

One approach might be to associate expiry dates with all personal data records, using periodic automated system functions or manual procedures to erase expired personal data. The expiry date might be pre-loaded when the data are originally loaded and updated as appropriate (e.g. if the service is extended or the principal re-confirms their permission to continue storing and using their personal data), and further controls might be helpful (e.g. validation checks for personal data records without valid expiry dates within a defined, reasonable period; additional pre-deletion checks that personal data that appear to have expired are truly redundant; plus various controls associated with 'secure deletion').

There are doubtless other approaches, too.

I'm not convinced, however, that it is worth elaborating on the policy in such detail, particularly as (a) the controls would be quite costly, and (b) the practical implementation details are context-dependent whereas all our policy templates are deliberately generic. I think we'll leave this to the discretion of our valued customers and their legal experts!

Tuesday 10 May 2022

Threat intelligence policy

 

I finally found the time today to complete and publish an information security policy template on threat intelligence. 

The policy supports the new control in ISO/IEC 27002:2022 clause 5.7: 

"Information relating to information security threats should be collected and analysed to produce threat intelligence."

The SecAware policy template goes a little further: rather than merely collecting and analysing threat intelligence, the organisation should ideally respond to threats - for example, avoiding or mitigating them. That, in turn, emphasises the value of 'actionable intelligence', in the same way that 'actionable security metrics' are worth more than 'coffee table'/'nice to know' metrics that are of no practical use. The point is that information quality is more important that its volume. This is an information integrity issue, as much as information availability.

The policy also mentions 'current and emerging threats'. This is a very tricky area because novel threats are generally obscure and often deliberately concealed in order to catch out the unwary. Maintaining vigilance for the early signs of new threat actors and attack methods is something that distinguishes competent, switched-on security analysts from, say, journalists.

The policy template costs just $20 from www.SecAware.com. I'll be slaving away on other new policies this week, plugging a few remaining gaps in our policy suite - and I'll probably blog about that in due course.

Saturday 23 April 2022

Professional services - operational phase

Following-on from the preliminary phase I covered yesterday, the longest phase of most professional services engagements is the part where the services are delivered. With the contractual formalities out of the way, the supplier starts the service, providing consultancy support or specialist advice. The client receives and utilises the service. Both 'sides' are important to both parties, since a professional service that isn't delivered and used doesn't generate value for the client, and is unlikely to lead to repeat business - such as additonal assignments:


Deliberately taking a simplistic view once again, I have represented 'assignments' (which may be projects, jobs, tasks or whatever) as discrete pieces of work, each with a beginning, middle and end: 
 
Things are never so neat and tidy in practice. Some assignments may never really get off the ground, and some gradually diminish or peter out rather than coming to an abrupt end. On-again-off-again assignments are challenging to plan and resource. Assignments may blend into each other or split apart. If the same supplier resources (mostly people) are involved in multiple assignments, possibly for multiple clients, the work rate on each one may be reduced - and likewise for a busy client, juggling multiple activities and competing priorities.
 
[The guideline could address the lifecycle of each assignment within an engagement, as well as the overall lifecycle. I doubt the benefit would offset the added complexity, though.] 

Information risk-relevant aspects that deserve proactive attention include changes, incidents, performance and quality of service, and compliance. I plan to describe basic processes associated with each of those, briefly, in the guideline. Incident management, for example, should protect the interests of client and provider both separately and together, so communication and collaboration may be key.

Maintaining management's focus on information risk during this phase may involve: 

  • Opportunistically pointing out information risk-related concerns, issues with controls, compliance obligations, improvement opportunities etc.;
  • Incorporating information risk and security metrics into reporting (begging the question 'What metrics?'); 
  • Making information risk a standing agenda item for relationship management meetings, progress meetings, project meetings or whatever; 
  • Emphasizing mutual interest in minimizing incidents, wherever possibly collaborating to reduce the probability and impact; 
  • Reviews and audits to confirm the effectiveness of key controls, identify concerns and provide assurance. 
It helps if such activities were discussed and agreed in the preliminary phase, perhaps being noted in the contract and incorporated into policies and procedures ... which means the guideline will be a worthwhile prompt. The same point applies to the concluding phase that I'll blog about tomorrow: knowing that there may be important information risk-related activities ahead through to the far end of a professional services engagement is something worth bearing in mind from the outset. Forewarned is four-armed, or something.

Monday 6 July 2020

Of APTs and RPTs



Do you recall when APTs were A Thing? Advanced Persistent Threats were exemplified by Stuxnet, a species of malware that was stealthy enough to penetrate the defences of an Iranian nuclear fuel processing plant ten years ago, persistent enough to undermine numerous layers of control, and sophisticated enough to over-speed and wreck the centrifuges without alerting the plant operators until the damage was done.  

We seldom hear of weapons-grade APTs these days, suggesting they are no longer newsworthy or effective. Maybe they have gone the way of the trebuchet or musket ... but I believe it's much more likely that APTs have become even more sophisticated, stealthier and more damaging now than ever before, especially given the ascendance of IoT, IIoT and 'cyber-physical systems'. Now, Things are A Thing.

Meanwhile, we are frequently constantly assaulted by ordinary, conventional, old-school malware - Retarded Persistent Threats as it were.

In contrast to APTs, RPTs are relatively crude and commonplace - more blunderbuss than sniper's rifle but every bit as devastating at close range. Despite becoming increasingly sophisticated and capable, they are presumably well behind APTs, especially given governmental investments in cyber capabilities as part of national defence spending.

RPTs 'persist' in the sense that they steadfastly refuse to go away. Bog-standard malware has dogged computer systems, networks and users since the 1980s. It has grown in prevalence at least as fast as IT, and in some ways it has driven advances in IT. The few percent of system resources needed to run today's antivirus packages and firewalls would surely have brought systems from previous decades to their little silicon knees.

Whereas most RPT incidents are, well, incidental in relation to our global society, they threaten the very large number of vulnerable systems, individuals and organisations out there. It has become painfully obvious during COVID-19 that vanishingly few organisations stand alone, immune to the global repercussions. We are all entangled in, and highly dependent upon, a global mesh of information, goods and services. Just as a single COVID case causes knock-on effects, an RPT incident creates ripples.

We're lucky that, so far, neither real-world nor cyber-world viruses have tipped us over the edge, triggering the zombie apocalypse that preppers fear. With their additional stealth and firepower, APTs may one day push things a byte too far - and then what? Perhaps those preppers aren't so loco as they may seem. Perhaps it's not such a crazy idea to build and secure our virtual bunkers to protect the information we'll need when zombies emerge from the forest. I guess I should carve this blog piece onto a rock, an information archival medium proven to last thousands of years. I wonder if these strange hieroglyphics will mean anything when the rock is dug up? 

Come to that, I wonder if they mean anything now! Are these merely the incoherent ramblings of a paranoid infosec geek, or have I struck a chord? Comments are welcome. Chisel away.

Saturday 16 May 2020

Adjusting to the new normal


"The U.S. Government has reported that the following vulnerabilities are being routinely exploited by sophisticated foreign cyber actors in 2020:
  • Malicious cyber actors are increasingly targeting unpatched Virtual Private Network vulnerabilities.
    • An arbitrary code execution vulnerability in Citrix VPN appliances, known as CVE-2019-19781, has been detected in exploits in the wild.
    • An arbitrary file reading vulnerability in Pulse Secure VPN servers, known as CVE-2019-11510, continues to be an attractive target for malicious actors.

  • March 2020 brought an abrupt shift to work-from-home that necessitated, for many organizations, rapid deployment of cloud collaboration services, such as Microsoft Office 365 (O365). Malicious cyber actors are targeting organizations whose hasty deployment of Microsoft O365 may have led to oversights in security configurations and vulnerable to attack.

  • Cybersecurity weaknesses—such as poor employee education on social engineering attacks and a lack of system recovery and contingency plans—have continued to make organizations susceptible to ransomware attacks in 2020."

Well whadyaknow?

  • The US government blames "sophisticated foreign cyber actors" - the usual xenophobic, somewhat paranoid and conspiratorial stance towards those filthy rotten foreigners, desperately attacking little old US of A (today's version of reds under beds I guess);

  • "Unpatched" VPNs and insecurely configured Office 365 services are being targeted, implicitly blaming customers for failing to patch and configure the software correctly, blithely ignoring the fact that it was US-based software vendors behind the systems that required patching and configuring to address exploitable vulnerabilities;

  • And finally, uneducated users (the great unwashed) receive a further gratuitous poke, along with the lack of planning on system recovery and contingency ... which is whose fault, exactly? Hmmm, I'll pick up that point another day.
Accountability and QA issues aside, the sudden en masse adoption of Working From Home has undoubtedly changed corporate information risks for all organizations - even those of us who were already routinely WFH, since we depend on ISPs, CSPs, telecomms companies, electricity suppliers, professional services companies and other third parties who are, now, WFH. COVID is another obvious, dramatic change with further implications for information and other risks (e.g. mental and physical health; fragile self-sufficiency; global economic shock; political fallout ...), and it's far from over yet.

WFH is now A Thing (not in the IoT sense!) for some of us anyway, although it's not possible or suitable for everyone. As COVID gradually fades from the headlines, some WFH workers will drift back to regular office work, others may continue WFH and a good proportion will do a bit of both (hybrid working as it's now known) according to circumstances and workloads. If COVID returns with a vengeance, or when the next pandemic turns up, we'll presumably be WFH en masse once more. So, have you reviewed and updated your corporate risk profile lately? Have the incident management, business continuity, IT, HR, business relationship management and other controls, processes and arrangements coped brilliantly with the present situation, or are adjustments called for? Do you even know how things are going out there, the workforce now scattered, hunkered down in their caves?

    Thursday 5 March 2020

    SIM swap fraud

    I've heard rumours about the possibility of SIM-swap "identity theft" (fraud) but wasn't aware of the details ... until reading a couple of recent articles pointing to an academic paper from a team at Princeton University.

    The fraud involves socially-engineering the cellphone companies into migrating a victim's cellphone number onto a new SIM card, one in the fraudster's possession. That gives the fraudster control of a factor used in several multifactor authentication schemes ... and in some cases, that's enough to take full control (e.g. resetting the victim's password - another factor). Otherwise, it might take them a bit more effort to guess, steal or brute-force the victim's password or PIN code first. 

    Authentication is usually a key control, yet authentication schemes often turn out to have vulnerabilities due to:
    • Fundamental design flaws (e.g. saving passwords unencrypted or weakly encrypted) 
    • Bugs in the software and firmware (e.g. cheat codes - bypasses and backdoors in production, and broken crypto in CPU microcode)
    • Physical hardware limitations (e.g. the tolerances needed for biometrics, allowing fakes and forgeries)
    • Issues in their implementation, configuration and administration (e.g. giving new users the same well-known default passwords or weak password reset mechanisms) 
    • Operational "user" issues (e.g. naively falling for phishing attacks)
    Multifactor is stronger than single factor authentication but still not perfect ... hence aside from addressing the vulnerabilities, we should also anticipate control failures and put in place further, supplementary controls to detect and respond to incidents.

    The risks are there for authentication to networks, systems, apps and online services in general, but the greater potential impacts in the case of, say, banking, law enforcement and defence imply greater risks, justifying the investment in stronger controls.

    Tuesday 28 January 2020

    Woe betide ...

    .... any organization unfortunate enough to suffer a privacy breach today, of all days, being "Data Privacy Day". 

    In the unlikely event that there are no new ones today, recent newsworthy breaches are liable to be trawled up and paraded across the media, again. 

    I've been writing about preparing to deal with malware incidents all this month. Managing or controlling the publicity aspects is trickier than it may appear. Sony pulled a master stroke in getting its legal team to threaten action against journalists who continued to exploit the tittle-tattle disclosed in the Sony Pictures Entertainment breach five years ago - but that's not a universally applicable approach. Travelex did well to get basic, static web pages published quickly, plus a talking-heads video explanation/apology by the CEO ... but ask their retail customers whether they feel 'informed', while the promised restoration of services is patently taking longer than anyone (except perhaps the cybercrims behind the attack) wants.

    Blend in the compliance aspects as well for good measure. I suspect British Airways and Marriott International, for instance, would have much preferred to take their corporal punishment under GDPR in private, rather than baring their bottoms on News At Ten.

    There's a fine line between their being directly blamed for causing the incidents, and being blamed for failing to prevent them - a line which Public Relations teams might do well to consider. The real culprits here are the cunning VXers, hackers and cybercrims, rather than their targets. Defending all points at once is undoubtedly much tougher than exploiting one or more vulnerabilities. It's not a fair fight! Too bad: that's how it is ... but maybe it wouldn't hurt to explain that.

    By the way, the issues multiply when you take into account the wide range of people and organizations who want to know and/or should be kept informed. Take employees, for instance: when the screens go dark in any IT-enabled organization, workers are left wandering and wondering. What can management say to explain the situation and reassure people? How can they even get their calming messages out if the comms are down? Same thing with suppliers, customers, partners, owners and authorities. This is where preparing for serious malware incidents makes good business sense. It sure beats leaving them all wandering and wondering!

    (Some) IT, comms and information services are bound to degrade in and following an incident, but it takes deliberate effort to ensure they degrade gracefully, with dignity, rather than collapsing into a blubbering, smouldering heap.

    Meanwhile, deep down in the engine room, are the IT pros frantically running in circles tearing their remaining hair out, or systematically following a tried and tested process for halting the incident, maintaining resilient services, restoring others and gathering the forensic evidence that might one day be necessary to prosecute the offenders? Again, preparation is key, especially when "time is of the essence" (which is always!).

    If the lights go out before anyone has thought to get a torch, good luck with your fumbling.

    Monday 20 January 2020

    Travelex vs Sony shootout

    The Travelex ransomware case study is coming along nicely. Over the dull grey NZ weekend, I prepared a timeline of the ongoing incident to compare and contrast against the Sony Pictures Entertainment ransomware incident at the end of 2014. 

    Already, Travelex is well ahead on points, restoring UK customer services within 3 weeks of the attack with more on the way. The incident timeline is substantially compressed relative to Sony's: they are getting through whatever needs to be done more quickly.

    Travelex has done well to keep its retail customers updated throughout, from the initial rapid disclosure on Twitter through to brief informational pages on the web, an FAQ, plus a statement and talking-head videoblog by its CEO on Friday just gone. Full marks from me!

    As far as I'm concerned, Travelex has managed the disclosures and public comms well, releasing professionally-crafted, informative briefings about the evolving situation, reassuring customers and not trying to cover things up or hide away. The CEO fronting-up is notable, confirming beyond doubt that senior management is on top of things, facing up rather than shying away. As with city's most senior policeman fielding a press briefing very shortly after the London bombings of July 2005, impeccably dressed, confident and impressive, the reassurance is very valuable, damping down rather than fanning the flames.

    Although admittedly I have not hunted for them specifically, I haven't yet come across any informal/unauthorized disclosures by Travelex workers, such as those mobile phone photos of the scary skeleton threats plastered over Sony's screens. Despite what must surely be a tense atmosphere in the offices, the Travelex workforce is evidently pressing on with the job, all hands to the pumps. Good on them too!

    In parallel, Travelex management must have been busy liaising with and reassuring its commercial customers/partners, industry regulators and the global news media too, while the fairly rapid restoration of services hints at a huge amount of work under way down in the IT engine room (presumably a disaster recovery approach, rebuilding servers from backups?).

    Most likely there are incident investigation and information security activities going on as well, and possibly communications with the cyber-crims behind the attack and the authorities. We know virtually nothing about that aspect at present, which is to be expected since it is commercially sensitive and might be forensically relevant. Further information may or may not emerge over the forthcoming months and years ...

    ... which reminds me: this incident is some way short of being 'resolved' at this point. Even when all Travelex's customer services are fully operational, there will still be loose ends to tie off, business relationships to rebuild and lessons to be learned. Meanwhile, thank you Travelex (and Sony and the Metropolitan Police and others) for teaching us a thing or two about handling serious incidents.