Article by Isabelle Meyer, Co-Founder Zendata
The cybersecurity maturity of an organization will be evaluated by its resilience and capacity to respond efficiently to an incident and avoid it becoming a crisis. ZENDATA aims to manage incidents effectively to minimize damage to systems and data, reduce recovery time and cost, control damage, and maintain brand reputation.
Our Incident Response as a Service (IRaaS) offer includes prepaid hours for use during a cybersecurity incident. ZENDATA IRaaS includes qualified engineers onsite and logistic, legal, and communication support.
Regardless of all the security tools, awareness training, and process organizations deployed, we see a continued increase in cyber incidents and data breaches. The sad truth is that, in contrast with compliance, cybersecurity can not be guaranteed. This is often a sensitive topic to address with top management as they have often invested hundreds of thousands or even millions of dollars in protective measures and are rightfully concerned with never seeing the end of the tunnel. However, once there is a shared understanding that cybersecurity protection is a moving target, the discussion can switch to risk mitigation and no longer be about risk removal.
A vital factor of a successful incident response is to detect it in the first place quickly. The industry is making a lot of progress on this matter. In 2015, it took 205 days for an attack to be discovered, with the value dropping to 16 days in 2022. This progress is mainly due to better security tools and Security Operating Centre (SOC) operations, enabling the incident response team to be engaged sooner. It is, however, far from being satisfactory. It is assumed that it takes around two h for a hacker to start moving laterally within a company once in.
There is already plenty of literature on incident response protocols and how they should operate; therefore, ZENDATA would like to share some insights and lessons learned from our past engagements instead of stating the obvious.
Responding to an incident is a complex mission combined with some adrenaline rushes. In the absence of upfront planning, everything needs to be done on the spot: within the first few hours, the incident response team must exchange with the top management of the organization, understand how it operates, learn what are the backend technologies and spend time documenting the incident step[1]by-step. It sounds obvious that this should be planned for. But, in 90% of the cases we have been confronted with, it was not. Following this, there are several days and nights when the team has to put aside all the other projects to resolve the incident, and the pressure is immense: The outcome of incident response efforts can have far-reaching consequences for an organization; Incident responders are tasked with coordinating with various teams within an organization, such as IT, legal, public relations, and executive leadership; and most importantly the pressure of being better than the criminal for the mission to be a success. Failing to plan for incidents is almost equal to planning to fail.
An often-forgotten part but one of the most important, is the definition of the objective of the incident response. It has to be clearly defined by the top management as the organization’s core values should drive it and will not only dictate the priorities of the incident response team but also how time/money will be spent and if the mission, in the end, was a success. Some organizations tell us the most crucial objective is to be quickly back online, and others limit the cost; some focus on assuring that the customers are protected, while others want to keep the incident under the radar. An improper response strategy to an incident can sometimes amplify the incident’s impacts. ZENDATA is hired on missions to negotiate ransom in the event of a cyber-attack; to proceed, the organization must predicate these objectives. This will drive the negotiation and the result. In incident response, there is no one-size-fits-all approach: the response should mirror the company values and priorities. And better you define it upfront with relevant stakeholders.
One of our team’s most common discussions with management is ransom payment. Of course, paying a ransom is never a desirable outcome. This can cost thousands or even millions of dollars and, above all, fuels the cybercrime industry. Paying a ransom will not only fund the group of hackers, allowing them to recruit additional members and increase their ability to hack. It also confirms that the target type (region and industry) is profitable and incentivizes them to repeat similar attacks.
However, the reality is often much more nuanced; having supported hundreds of victims, we notice that paying the ransom is often the only survival option for the company or the “best” thing to do to limit the damage to their operations, reputations, and third parties they are engaged with, including their customers and partners. ZENDATA elaborated the incident response playbooks with law enforcement. In short, we often hear people saying that no money should be paid, but again, this is not a white-and-black situation and often the best of the worst options.
From our experience, more than 30% of ransomware targets eventually choose to pay the ransom. Cybercriminals are very meticulous and know how to maximize their victim’s damage: for example, they read their emails to find the most sensitive data and accordingly devise a plan to cause the most panic, pain, and operational disruption, thereby forcing the victim to pay. The only good news is that experience shows that the price of ransoms can be heavily negotiated and, depending on the threat actor group, can be lowered by up to 75%. In addition, the hackers know that the longer it takes for the victim to pay, the lower the chance of receiving the funds.
However, even by paying the ransom, the victim is not necessarily out of the heat zone; the decryptor provided by the criminals may not work correctly on all files (bugs exist in all programs), and some documents may remain encrypted despite best efforts. Similarly, hackers will often seek to monetize their attack further: they browse the exfiltrated information to use it in other attacks or resell it. They may find in email exchanges potential new victims for CEO fraud, opportunities to send fake invoices, or use personal information for identity theft.
There is also a technical part to respond to a ransomware incident. It consists in securing the compromised infrastructure. Whether the ransom is paid or not, the environment must be secured and hardened to become a safer place for the restored or recreated data. Since, in most cases, the threat actor gains administrator access to the environment, we should assume full compromise and organize for a brand-new environment. Nevertheless, often it is not financially and operationally doable, and some parts of the environment might be sufficiently segregated (cloud platform, different OS, distant offices, etc.) to block the threat actor’s lateral movements, i.e., from one part of the organization to the other. In this case, it is essential to identify what part of the infrastructure is safe to operate and what needs to be cleaned up/secured for future and continuous operation.
The second most common type of incident ZENDATA is called upon is business email compromise. It usually happens when a threat actor gains access to someone’s email account and uses it to request fraudulent financial transfers. Usually, the damage has already been done once the Incident response team is mobilized. In such cases, considering the money has often been already stolen, often our mission is to understand how the threat actor got into the infrastructure, what else they stole, and if someone inside the organization supported them.
What is usually very impressive with this type of investigation is the deep understanding of the threat actor of not only the technological backend and the ways to avoid detection but also the financial system and workflows. In one specific investigation where 12 million dollars got stolen, in less than 45 days after compromising the email account, the criminal successfully maintained stealth persistence, discovered the email of interest, created a fake company with the same name in the UK, opened a bank account, sent forged invoices, and moved the money out to the Far East. Even though the money was lost, ZENDATA’s incident response team’s investigation enabled us to establish which company was compromised and who was responsible for the money loss.
Incident response requires many skills, from business understanding to technical knowledge and human skills. The most important part to note is that if the team has the opportunity to be involved early on in the Disaster and Recovery Plan (“DRP”) creation and the plans have been tested and approved by management, chances are that the victim of a cyber incident will be able to contain it and avoid having an incident become a crisis.
In conclusion, many companies are looking for KPIs to value their performance in terms of cyber security maturity. One critical KPI for us at ZENDATA is how quickly (on the far left) incidents are detected and handled on the kill chain. There is a direct correlation with the level of potential damages. Moore’s law on technology evolution is well known. The joy’s law less so. It states that whatever you do, the most intelligent people might not belong to your organization. This applies to incident response. So best you surround yourself with people who do this for a living. We advise companies and organizations to have a retainer-based contract for this service. Our IRaaS service includes but is not limited to:
• Onsite and remote forensic analysis
• Incident response coordination and management
• Onsite Incident Response
• Attack Investigation
• Emergency BCP/BRP implementation & execution
• Deployment of temporary security tools
• On-demand file analysis.
• Breach containment
• Initial access discovery
• Persistence & backdoor removal
• Ransomware and blackmail negotiation service
• Analysis of assets (endpoints, servers, network equipment, mobile equipment, etc.) that may have been infected
• Post-incident reporting and debriefing, including future remediations
