A collaborative environment between IT and security groups is critical. The number of cyber security incidents currently impacting networks and customers is increasing exponentially and mitigating security incidents and risks is more complex than ever before. Timely and effective communication are keys to improved collaboration between all parties involved in the cyber incident response process. One of the simplest and most effective methods to improve communication between all relevant IT and security groups is to deploy a common, shared platform where stakeholders can review and analyze incidents across the entire cyber landscape. A cross-departmental platform enables them to focus on correlating cyber incidents and risks with contextual information relevant to their role and responsibilities plays a significant part in organizational success in this regard.
Incorporating knowledge transfer between disparate business entities often separated both geographically and functionally is essential to facilitate a better understanding of the current IT and security challenges. The preferred method to provide this collaborative environment is via electronic based communication mediums and devices. To tie all of these channels together, an organization should consider deploying a cyber incident response platform, and the platform must be able to integrate these technologies, be it SMS, email or other messaging medium, to cover the broadest range of communication channels to transmit critical information to stake holders.
Another successful strategy that focuses on effectively communicating timely, critical information to relevant stakeholders is via the creation of an incident notification group. IncMan supports the creation of groups of Watchers that are appraised of incidents and activities automatically via SMS, email or an integrated communications system. A Watcher group can ensure that information is properly communicated to the appropriate stakeholder(s). This provides differing stakeholders with the capability of monitoring incidents that may impact business continuity. Additionally, IncMan has integrated communications capabilities comply with industry best practices which recommend having a separate, secure and hardened communications channel if email or other internal communication channels are compromised. This independent messaging capability also provides additional benefits such as asymmetric encryption capabilities.
Leveraging a dedicated solution that can orchestrate the communications to stakeholders standardizes the process of cyber incident response and mitigation and is the key to ensuring a more effective response. If you would like more information or a free no obligation demonstration of how IncMan from DFLabs can more effectively automate and orchestrate your incidents please contact us at [email protected]
Alert fatigue is the desensitization when overwhelmed with too much information. The constant repetition and sheer volume of redundant information are painful and arduous but sadly often constitutes the daily reality for many people working in cyber security. Mike Fowler (DFLabs’ VP of Professional Services) discusses several best practices to help with some of the challenges involved in this in his recent whitepaper “DFLabs as a Force Multiplier in Incident Response”. I am going to discuss another one, but looking at it from a slightly different angle.
Imagine the scenario where we have tens of thousands of alerts. Visualize these as Jigsaw pieces with a multitude of different shapes, sizes and colors and the additional dimension of different states. We have alerts from a firewall, anomalies from behavioral analytics, authentication attempts, data source retrieval attempts or policy violations. Now, there are a lot of ways to shift through this information, for example by using a SIEM’s to correlate the data and reduce the some of the alerts. The SIEM could identify and cross-reference the colors and shapes of the jigsaw pieces so to speak.
The next question once that I’ve got the all the pieces I need for the puzzle is how do I put this together? How do I complete the puzzle and unlock the picture?
The “what does the jigsaw picture?” question is something that will often puzzle the responders, pun intended. How do you prioritise and escalate incidents to the correct stakeholders? How do you apply the correct playbook for a specific scenario? How do you know which pieces of information to analyse to fit the jigsaw pieces together and make sure the puzzle looks correct?
Automation process can speed up putting that puzzle together, but making sure you automate the right things is just as critical. If skilled staff are running search queries that are menial, repetitive and require little cognitive skill to execute, you should ask yourself why they are performing these and not instead focused on analyzing the puzzle pieces to figure out how they fit together?
Remove the menial tasks. Allow automation to do the heavy lifting so your teams are not only empowered by the right information they need to successfully manage the response to an incident but also to give them more time to figure out the why, how and what of the threat.
We also welcome you to join us for a webinar hosted by Mike Fowler on this topic on the 6th of September.
Over the past few months during the post-hoc analysis of WannaCry-Petya, we have spoken in great lengths about what should have been done during the incident. This is quite a tricky thing to do in a balanced way because we are all clever in hindsight. What hasn’t been spoken about enough is understanding more generally what we need to do when things go wrong.
This question isn’t as simple as it appears, as there are a lot of aspects to consider during an incident, and only a brief window to identify, contain and mitigate a threat. Let’s look at just a few of these:
– Response times
This is often the greatest challenge but of utmost importance. The response is not only understanding the “how” and “why” of a threat but is also about putting the chain of events into action to make sure that the “what” doesn’t spiral out of control.
– Creating an effective playbook
A playbook should be a guide on how your incident response plan must be executed. Orchestration platforms contain these playbooks/runbooks. Also, note that these are not generic plug and forget policies. They need to be optimized and mapped to your business and regulatory requirements and are often unique to your organization. Otherwise, the incident will be controlled by an incorrect playbook.
– Skills and tool availability
Do you have the correct skills and tools available and are you able to leverage these. Do you understand where your security gaps are and do you know how to mitigate them?
On paper, incident response always works. Right until the moment of truth during a data breach that shows that it doesn’t. To avoid relying on theory only, it is best to run breach simulations and simulate some of the attacks that may affect your organization to find out if your processes and playbooks also work under more realistic conditions.
We’re always playing catch‒up for many reasons—new technologies, new vulnerabilities, and new threats. Software and hardware may possibly always be at the mercy of hackers, criminal actors and other threat actors, so prevention alone is futile. We have to become more resilient and better at dealing with the aftermath of an attack.
The key summary for me is this: How do you respond? Can the response be improved? Utilize the lessons learned in breach simulations to understand how you make the response better than before.
The DNA sequence for each human is 99.5% similar to any other human. Yet when it comes to incident response and the manner in which individual analysts may interpret the details of a given scenario, our near-total similarity seems to all but vanish. Where one analyst might characterize an incident as the result of a successful social engineering attack, another may instead identify it as a generic malware infection. Similarly, a service outage may be labeled as a denial of service by some, while others will choose to attribute the root cause to an improper procedure carried out by a systems administrator. Root cause and impact, or incident outcome, are just a couple of the many considerations that, unless properly accounted for in a case management process, will otherwise play havoc on a security team’s reporting metrics.
Poor Key Performance Indicators can blind decision makers
What is the impact of poor KPI’s? All too often the end result leads to equally poor strategic decisions. Money and effort may be assigned to the wrong measures, for example into more ineffective prevention controls instead of improved response capability. In a worst case scenario, poor KPI’s can blind decision makers to the most pertinent security issues of their enterprise, and the necessary funding for additional security may be withheld altogether.
Three best practices are required to address this all too common problem of attaining accurate reporting:
- A coherent incident management process is necessary in order to properly categorize incident activity. Its definitions must be clear, taking into account outliers, clarifying how root causes and impacts are to be tracked, and providing a workflow to assist analysts in accurately and consistently determining incident categorization.
- The process must be enforced to guarantee uniform results in support of coherent KPI’s. Training, quality assurance, and reinforcement are all necessary to ensure total stakeholder buy-in.
- Security teams must have the technologies to support effective incident response and proper categorization of incidents.
There are several ways that the IncMan platform supports the three best practices:
First, IncMan provides a platform to act as the foundation for an incident management program. It provides customizable incident forms allowing for complete tailoring to an organization and the details it must collect in support of its unique reporting requirements. Custom fields specific to distinct incident types allow for detailed data collection and categorization. These custom fields can be coupled with common attributes to track specific data, thereby providing a high level of flexibility for security teams in maintaining absolute reporting consistency across the team’s individual members.
Next, playbooks can be associated with specific incident types, providing step-by-step instructions for specialized incident response activities. Playbooks enforce consistency and can further reinforce reporting requirements. However, playbooks are not completely static, and while they certainly provide structure, IncMan’s playbooks also offer the ability to improvise, add, remove or substitute actions on the fly.
The platform’s Knowledge Base offers a repository for reference material to further supplement playbook instructions. Information collection requirements defined within playbook steps can be linked to Knowledge Base references, arming analysts with added information, for example with standard operating procedures pertaining to individual enterprise security tools, or checklists for applicable industry reporting requirements.
IncMan also includes Automated Responder Knowledge (ARK), a machine learning driven approach that learns from past incidents and the response to them, to suggest suitable playbooks for new or related incident types. This is not only useful for helping to identify specific campaigns and otherwise connected incident activity but can also highlight historical cases that can serve as examples for new or novice analysts.
Finally, the platform’s API and KPI export capabilities enable the extraction of raw incident data, allowing for data mining of valuable reporting information using external analytics tools. This information can then be used to paint a much clearer picture of an enterprise’s security posture and allow for fully-informed strategic decision-making.
Collectively, the IncMan features detailed above empower an organization with the means to support consistency in incident categorization, response, and reporting. For more information, please visit us at https://www.dflabs.com
In incident response, protecting against a targeted attack is like slaying the hydra. For those not familiar with what a hydra is, it is a multi-headed serpent from Greek mythology, that grows two new heads for every head you chop off. A determined attacker will try again and again until they succeed, targeting different attack vectors and using a variety of tactics, techniques, and procedures.
The Snowden and Shadowbroker leaks really drove this home, giving partial insight into the toolkit of nation state actors. What really stuck out to me was the sheer variety of utilities, frameworks, and techniques to infiltrate and gain persistence in a target. Without the leak, would it be possible to reliably determine that all of those hacking tools belonged to a single entity? Would a large organization with thousands of alerts and hundreds of incidents every day be able to identify that these different attacks belonged to a single, concerted effort to breach their defenses, or would they come to the conclusion that these were all separate, unrelated attempts?
Our colleagues in the Threat Intelligence and Forensic analysis industries have a much better chance to correlate these tools and their footprint in the wild – they may discover that some of these tools share a command and control infrastructure for example. A few did have at least an outline of the threat actor, but judging by the spate of advisories and reports that were released after the leaks, not very many actually appear to have achieved this to a great degree. The majority were only able to piece the puzzle together once equipped with a concise list of Indicators of Compromise (IoC) and TTP’s to begin hunting with.
“How does this affect me? We are not important enough to attract the attention of a nation state actor”
Some readers may now be thinking, “How does this affect me? We are not important enough to attract the attention of a nation state actor”. I would urge caution in placing too much faith in that belief.
On the one hand, for businesses in some countries the risk of economic espionage by-nation state hacking has decreased. As I wrote on Securityweek in July, China has signed agreements with the USA, Canada, Australia, Germany and the UK limiting hacking for the purpose of stealing trade secrets and economic espionage. However, this does not affect hacking for national security purposes, and it will have little impact on privately conducted hacking. These are also bilateral agreements, and none exist in other nations, for example, Russia or North Korea. For militarily and economically weaker nation states, offensive cyber security is a cheap, asymmetric method of gaining a competitive or strategic advantage. As we have seen, offensive cyber activity can target civilian entities for political rather than economic reasons, and hackers are increasingly targeting the weakest link in the supply chain. This means that the potential probability of being targeted is today based more on your customer, partner, and supply chain network, and not just on what your organization does in detail. Security through obscurity has never been a true replacement for actual security, but it has lost its effectiveness as targeted attacks have moved beyond only focusing on the most prominent and obvious victims. It has become much easier to suffer from collateral damage.
Cyber criminals are becoming more organized and professional
On the other hand, cyber criminals are becoming more organized and professional, with individual threat actors selling their services to a wide customer base. A single small group of hackers like LulzSec may have a limited toolbox and selection of TTP’s, but professional cybercrime groups have access to numerous hackers, supporting services and purpose-built solutions. If they are targeting an organization directly and are persistent and not opportunistic, it will be as difficult to discern that a single concerted attack by one determined threat actor is taking place.
What this means in practical reality for any organization that may become the target of a sophisticated threat actor, is that you have to be on constant alert. Identifying, responding to and containing a threat is not a process to be stepped through with a final resolution step – instead, cyber security incident response is an ongoing, continuous and cyclical process. Advanced and persistent attacks unfold in stages and waves, and like a war consist of a series of skirmishes and battles that continue until one side loses the will to carry on the conflict or succeeds in their objectives. Like trying to slay the hydra, each incident that you resolve means that the attacker will change their approach and that the next attempt may be more difficult to spot. Two new heads have grown instead of one.
To tackle this requires that we cultivate a perpetual state of alertness in our SOC and CSIRT
To tackle this requires that we cultivate a perpetual state of alertness in our SOC and CSIRT – but we must do this without creating a perpetual state of alarm. The former means that your team of analysts is always aware and alert, looking at individual incidents as potentially just one hostile act of many that together could constitute a concerted effort to exfiltrate your most valuable data, disrupt your operational capacity, or abuse your organization to do this to your partners or customers. In the latter case, your analysts will suffer from alert fatigue, a lack of true visibility of threats, and a lack of energy and time to be able to see the bigger picture.
The hydra will have too many heads to defeat.
In the Greek legend of Heracles, the titular hero eventually defeats the Hydra by cauterizing each decapitated stump with fire to prevent any new heads from forming. Treating an incident in isolation is the Security Incident Response equivalent of chopping off the head of the hydra without burning the stump. Applied to our problem, burning the stump means that we have to conduct the response to each incident thoroughly and effectively, and continue the process well beyond containment.
We must invest more time in hunting and investigating, and we have to correlate and analyze the relationship between disparate incidents. We must use threat intelligence more strategically to derive situational awareness, and not just tactically as a machine-readable list of IoC’s. This also requires gathering sufficient forensic evidence and context data about an incident and related assets and entities during the incident response process, so that we can conduct post event analysis and continuous threat assessment after containment and mitigation have been carried out. This way we can better anticipate the level of threat that we are exposed to, and make more informed decisions about where to focus our resources, add mitigating controls and improve our defenses. In Incident Response “burning the stump” means making it more difficult for threat actors to succeed in the future by presenting them with a hardened attack surface, reducing their reside time in our infrastructure, and reducing the time we need to discover and contain them. To do this we need to learn from every incident we manage.