Since March, we’ve been very busy providing incident-response and recovery services for organisations that have fallen victim to cyber crime. During that time, we have observed:
- Similarities in the security services, infrastructure and practices that were in place before the target organisations were compromised.
- Similarities in tactics and techniques that the attackers used to compromise the target organisations, and misuse the target assets after the target organisations were breached.
This blog post summarises our observations with the intent of helping other organisations to understand how they can undertake not just better incident detection and response, but more importantly, incident preparation and avoidance.
The frequency of successful attacks that are reported in the media is increasing, and this indicates that many organisations experience difficulties in the implementation and/or testing of policies and procedures associated with anomaly and threat detection, incident identification and incident response.
This observation is backed up by IBM’s reporting that shows:
- The average time to identify a data breach in 2020 was 220 days, and,
- Once identified, the average time to contain a data breach in 2020 was 73 days.
For more information, you can read IBM’s report.
As evidenced by recent headline extortion and ransom-ware events such as the attacks on Kaseya (and the thousands of subsequent attacks on Kaseya’s clients), AXA insurance, Colonial Pipelines, and JBS Meats, attackers are becoming more effective at earning the big bucks by damaging the reputation, revenue, customer-base and even the solvency of a rapidly growing number of increasingly diverse business and government organisations.
Most of the big-name reporting we see in Australia is associated with overseas victims of on-line crime but there’s nothing new under the sun and as incident responders, we see that the headline attacks pretty much mirror the tactics and techniques being used against Australian organisations.
Experience is the best of schoolmasters, only the school-fees are heavy. Thomas Carlyle
With the goal of helping as-yet uncompromised (or at least apparently uncompromised; more on that later) organisations, let’s look at some aspects of recent breaches that we have helped with: As you’ll see, they are very similar to the breaches that you’ll have read about in the news, and they provide an insight, not just into incident detection and response, but more importantly, into incident preparation and avoidance. The similarities in the breaches we have assisted with this year are worth understanding if we are to achieve our goal of helping to prevent similar damage and disruption of services:
- The targeted organisations were medium-to-large Australian organisations, as defined by the ABS.
- All the organisations were breached during the so-called HAFNIUM campaign that became widely-apparent in early March, but which was probably active some months before that.
- While most of the HAFNIUM breaches took place in February and March, the targeted organisations were not aware of the attack until some time between March (the earliest) and June (the latest).
- It’s worth noting that while HAFNIUM-related damage gave rise to our involvement in the incident-recovery process, it turned out that HAFNIUM was not even HALF (that pun; I had to… I’m sorry!) the problem. While analysing the HAFNIUM attacks, we found that more than half the organisations had been compromised before the HAFNIUM attackers arrived in March and in fact, two organisations had been compromised on two occasions prior to the HAFNIUM event. In line with IBM’s stats, we found that the oldest (certain) previous compromise took place in December 2020, and remained undetected (before it was discovered as part of the investigation into the HAFNIUM compromise) for at least 95 days.
- We say, at least 95 days in the previous point because it was not possible to be sure when precisely the previous breaches took place. There was some evidence of malicious powershell execution that showed that one organisation was certainly breached in December last year, but in some cases, the absence of consistent and complete, cross-system logs meant that it was not possible to make a determination regarding any possible earlier malicious activity.
So what's missing?
Confusion is a word we have invented for an order which is not yet understood. Henry Miller
A Security Information and Event Management (or SIEM) service, often existing as part of Security Operations Centre (SOC), facilitates the collection, analysis, and retention of event logs that allow an organisation to detect, correlate, understand, investigate and respond to threatening or anomalous events in a timely manner.
Without a properly designed and operated SIEM/SOC service, the activities of legitimate users and malicious attackers are generally indistinguishable, and if activity logs are being generated, the individual log events generally just swirl like tiny bubbles in an ocean of background noise until they are eventually deleted or overwritten.
A SIEM/SOC service can make sense of all the background noise and so should be a core component of a mature security plan and infrastructure; however, configuring, operating, maintaining and extending SIEM/SOC services is just plain hard work, even for skilled and expert professionals with years of experience! There is no time off for good behaviour but instead a constant and unceasing drive to improve system visibility and IOC detection, while also reducing false-positive alerts and response times.
And knowing all of that makes it easier to understand why we were asked to help with HAFNIUM-related incidents, up to almost four months after HAFNIUM became well known. The main reason is that the attacker(s) could remain undetected and resident for an extended period of time because the targeted organisations did not have effective SIEM/SOC services in place. Equally problematic, once some of the organisations realised that something was up, the limited availability of historical logs hampered response efforts and increased the time and costs associated with the attack-scoping and containment efforts.
To be clear, none of this is a criticism or indictment of any victim of on-line crime; it’s just a observation of fact: Even with the best of intentions, the implementation of mature SIEM/SOC services is, for many organisations, difficult if not infeasible… and that is music to the ears of an attacker!
Managed SIEM to the rescue!
There cannot be a crisis next week. My schedule is already full! Henry Kissinger
It makes good sense to align your security management activities with an established and recognised information security standard/framework such as CIS Controls, PCI DSS, NIST CSF, CPS 234 or ISO/IEC 27001 (we’ll look at standards and frameworks in a later post). Even if it’s not a regulatory requirement for your organisation, your cyber-insurer will be happier, and you can benefit from the combined knowledge of the experts that contributed to their development. Each of these security standards and frameworks effectively requires an organisation to collect, alert, review, and retain audit logs of events that could help detect, understand, or recover from an attack.
Of course, keeping track of (and adhering to) relevant standard and framework requirements only exacerbates the challenges associated with SIEM/SOC deployment, which is where Managed SIEM can assist!
DotSec uses the term Managed SIEM (MSIEM) to describe the provision of SOC functionality using SIEM (and other) services, delivering a complete set of SOC and SIEM capabilities. In contrast to the pain and expense associated with managing an in-house SIEM infrastructure, DotSec helps organisations to reap all of the benefits of a professionally designed and deployed MSIEM system, without incurring the overhead and expense associated with maintaining, operating and testing such a system in-house; and without the need to manage specialist-staff acquisition, training, support and retention.
DotSec has provided MSIEM services to government and corporate customers for over 12 years. DotSec is also a PCI DSS-compliant service provider which means that DotSec has completed Self-Assessment Questionnaire D and an Attestation of Compliance (AOC) for Service Providers, with an overall COMPLIANT rating.
Our MSIEM and incident detection and response experience this year reflects the trends that we all read about in the news: Corporate and government systems are increasingly being compromised by attackers who are able to remain undetected for extended (220 days on average, according to IBM) periods of time. And once discovered, it takes (again, according to IBM) an average of 73 more days before the breach can be contained.
Life’s like a movie. Write your own ending. Kermit The Frog
As described in the opening paragraphs above, we have observed similarities in the security services, infrastructure and practices that were in place before a number of organisations were compromised this year. Our experience echoes IBM’s reporting which indicates that attackers are able to remain resident and undetected within compromised organisations, for extended periods of time.
DotSec has helped compromised organisations by deploying MSIEM services to support scoping and containment efforts once an attacker has been discovered. Doing so however involves undertaking an expensive and time consuming catch-up process that may be too late to prevent information and assets from being stolen or destroyed.
A preferable and (far) less expensive option is to allow DotSec to provide collaborative, proactive MSIEM services that include the collection, aggregation, indexing, searching, storage and management of information security logs, assistance with the detection, prioritisation, alerting and reporting of notifiable events (which may include security incidents), and a range of supporting, pro-active services such as vulnerability detection and management, threat hunting, and adversary emulation and purple teaming.
We’re keen to help so give us a call. Act now and follow Kermit’s advice: “Write your own ending”.