Overcoming the Tower of Babel in Your Cybersecurity Program

Best practices for communicating cybersecurity risks and efficiency

One of the most difficult challenges encountered within risk management in today’s ever-changing cybersecurity environment is the ability to communicate the risks posed to an organization effectively. Security executives expect communication to be in their own language, focusing on the financial implications regarding gain, loss, and risk, and the difficulty of translating traditional security terms and nomenclature into risk statements expected by business executives poses a serious challenge. Therefore, it is the responsibility of a cybersecurity professional to ensure that security risks are communicated to all levels of the organization using language that can be easily understood.

The communication of security metrics plays a crucial role in ensuring the effectiveness of a cybersecurity program. When disseminating information on cyber risks, several aspects of communication should be considered. For example, a security professional should be cognizant of the credibility of the information’s source, the targeted audience and how to place the risk into perspective. We firmly believe that the success of a business today is directly related to the success of its cybersecurity program. This is largely due to the fact that all organizations depend on technology. Specifically, the interconnectedness of digital technologies translates to a significant potential for damage to an organization’s operational integrity and brand credibility, if its digital assets are not meticulously safeguarded. We only need to look at the recent Equifax breach for an illustrative example of this. Considering the potential impact of cyber attacks and data breaches, organizations must improve how they communicate cybersecurity risk.

The first step to ensuring effective communication of cyber risks involves a comprehensive business impact assessment. This must consider the organization’s business goals and objectives. Business impact assessments focus on how the loss of critical data and operational integrity of core services and infrastructure will impact a business. Furthermore, it acts as a basis for evaluating business continuity and disaster recovery strategies.

The second step is the identification of key stakeholders and their responsibilities. According to experts, this step plays a significant role in being prepared to mitigate the impact of cyber risks. Stakeholders are directly affected by a breach and have the most skin in the game. Identifying stakeholders should not be a one-off exercise but must be conducted regularly. An important consideration is that the more stakeholders there are, the greater the scope for miscommunication. Failure to identify the responsible stakeholders will increase the probability that risk is miscommunicated. In the case of a breach, it means that the response will be ineffective.

The third and most critical step is the identification of Key Risk Indicators (KRIs) tied to your program’s Key Performance Indicators (KPIs). Doing this correctly will mean communicating cyber risks to executives in a way that allows them to make informed decisions. As an example, the amount or the severity of vulnerabilities on a critical system is meaningless to non-technical executives. Stating that a critical system that processes credit card data is vulnerable to data loss is more meaningful. Once business impacts have been assessed, stakeholders have been identified, and meaningful security metrics have been determined, regular communication to various stakeholders can take place.

Different stakeholders have unique needs. This must be considered when communicating KRIs and KPIs. When delivering information, we must accommodate both the stakeholders that prefer summaries and those that prefer reviewing data to make their conclusions. DFLabs’ IncMan generates customizable KPI and incident reports designed to cater to both audiences. Cybersecurity program metrics1 must also focus on costs in time and money to fulfill business needs. The ability to track these metrics is a key differentiator for DFLabs IncMan.

DFLabs’ IncMan is designed to not only provide the best in class incident orchestration and response capabilities but also provides the ability to generate customizable KPI reports that accurately reflect up-to-the-minute metrics on the health of your cybersecurity infrastructure. If your organization needs to get a true, customizable view that incorporates all stakeholders please contact us at [email protected] for a free, no-obligation demonstration of how we can truly keep your cyber incidents under control.

R3 Rapid Response Runbook for Spear Phishing

According to Verizon’s Data Breach Investigations report 2017, social engineering was a factor in 43% of breaches, with Phishing accounting for 93% of social attacks.

DFlabs has worked closely with our customers to draft and deploy Phishing specific runbooks. In this article, we take a look at an example R3 Phishing runbook below.

The Premise
Our premise is that an incident appears to be a Spear Phishing attempt has been forwarded to the SOC. The SOC team must qualify the incident and determine what needs to be done to mitigate the attack.

We begin our investigation with an incident observable, a fully qualified domain name (FQDN).

We will correlate the FQDN with several external threat intelligence services to assess whether this is truly an ongoing Phishing attempt or a benign false positive. We have used VirusTotal and Cisco Umbrella in this example, but other threat intelligence and malware services could be used instead.

We have 3 different potential outcomes and associated decision paths:

R3 Rapid Response Runbook for Spear Phishing 7

The R3 Runbook

1. The FQDN is automatically extracted from the incident alert and then sent to Cisco Umbrella Investigate for a classification.

R3 Rapid Response Runbook for Spear Phishing 1


2. Depending on the outcome – whether Cisco Umbrella Investigate classifies the FQDN as benign or malicious – we can take one of two different paths.

R3 Rapid Response Runbook for Spear Phishing 2


3. The FQDN will be rechecked with VirusTotal to verify the result. We do this whether the first classification was malicious or benign. At this point we do not know whether one of the two services is returning a false positive or a false negative, so we do a double check.

R3 Rapid Response Runbook for Spear Phishing 3


4. IF both external 3rd party queries confirm that the FQDN is malicious, we have a high degree of certainty that this is a harmful Phishing attempt and can step through automatically to containment. In our example, we automatically block the domain on a web gateway.

R3 Rapid Response Runbook for Spear Phishing 4


5. Alternatively, if only one of the two queries returns a malicious classification, we need to hand the runbook off to a security analyst to conduct a manual investigation. At this point, we cannot determine in an automated manner where the misclassification resides. It could be that one of the services has stale data, or doesn’t include the FQDN in its database. With the ambiguous result, we lack the degree of confidence in the detection to trust executing fully automated containment.

R3 Rapid Response Runbook for Spear Phishing 5


6. If both VirusTotal and Cisco Umbrella Investigate return a non-malicious classification, no further action will be necessary at this point. We will notify the relevant users that the incident has been resolved as a false positive and can close the case for now.

R3 Rapid Response Runbook for Spear Phishing 6


This R3 Phishing Runbook demonstrates the flexibility and efficiency of automating incident response . Incident Qualification is automated as much as is feasible but keeps a human in the loop when cognitive skills are required. It only automates containment when the degree of confidence is sufficient. It eliminates false positives without requiring human intervention.

Finding a Balance Between Rapid and Measured Incident Response

Since I am a new face (or perhaps just a name to most of you) here at DFLabs, I wanted to take a moment to introduce myself before we jump into the topic for today. My name is John Moran and I recently joined the DFLabs team as Senior Product Manager. Prior to joining the DFLabs team, I worked in a variety of roles, including incident response consulting, security operations and law enforcement. While I have many responsibilities at DFLabs, one of my primary roles and the one that I am perhaps most passionate about is ensuring that DFLabs continues to bring you the industry leading security orchestration, automation and response feature that you have come to expect from IncMan. If you have feature requests, suggestions or other comments, good or bad, regarding IncMan, I’d love to hear from you. Please reach out to me at [email protected]. With that out of the way, let’s get to the good stuff…

While reports such as the Verizon DBIR indicate that the increased focus on creating holistic, detect and respond security programs has had a positive impact on reducing the time to detect security incidents, these same reports have also shown that attackers are continuing to evolve. There is still a continuing gap from compromise to detection. what I would like to discuss here instead though, might be described as the opposite problem; overreaction to a perceived security incident, or conducting a full-scale response to a security incident prior to validating that a security incident has indeed occurred.

Please do not misunderstand what I am saying, I will always advocate the “treat it as an incident until you know otherwise” approach to incident response. However, I would also encourage that the response to any security incident should always be a measured response. The incident response process must be rapid and decisive; but just as under-responding to an incident can present serious financial and reputational risks to an organization, so too can over-responding to a potential security incident. As with any other business process, incident response must provide value to an organization. Continued over-response to perceived security incidents will reduce the overall value that incident response provides to an organization, and over time will result in decreased support from management.

Few studies have truly been able to quantify the costs associated with failing to conduct a measured response. A 2015 study by the Ponemon Institute suggests that response to incidents detected based on erroneous or inaccurate malware alerts costs large organizations up to 395 hours-per-week, or almost $1.3 million a year. It is important to note that this study only took into consideration time spent investigating malware alerts. While malware detection technologies have undoubtedly improved in the two years since this study was conducted, most organizations have a variety of detection technologies, all generating alerts which must be investigated. It was assumed by Ponemon that the organizations surveyed were conducting an appropriate, measured response to each of these false positives. With the cost already so high, it is easy to conclude how costly over-responding to incidents can become at scale.

While conducting incident response consulting, I have personally seen organizations spend weeks to months conducting full-scale incident response activities before spending tens of thousands of dollars for incident response consulting, only to find out that the perceived incident was based on faulty information or conclusions. So how do you minimize the risk of over-responding while continuing to ensure that each potential incident is properly investigated? Here are five tips based on my experience:

  1.  Have the right people in place – There is simply no substitute for having the right people in place. While proper training and experience are vital, the qualities of an effective analyst extend beyond these two attributes. It is crucial to have analysts who possess an analytical mindset and can remain level-headed amidst a stressful and dynamic environment. Training and be provided, the experience can be gained, however, some of these less tangible qualities are much harder to learn.
  2.  Have the right toolsets in place – Attempting to substitute tools for skills will inevitably lead to failure. However, it is important to have the proper tools in place to give those highly skilled analysts the information they need to make fact-based conclusions. Even the most highly skilled analysts will inevitably arrive at the wrong conclusion when presented with incomplete or inaccurate information.
  3.  Know the threat landscape – Threat intelligence, and I mean actual intelligence, not just a machine-readable threat feed, can provide much greater context surrounding a potential security incident. Analysts must also be provided the opportunity to remain up-to-date on the ever-changing threat landscape. This can allow decision makers a much more accurate perspective on which to base their initial level of response. Often, it is a lack of knowledge and conclusions based on assumptions that lead to a dramatic over-response.
  4.  Know your limitations – Unless you are fortunate enough to work for a government agency or one of the world’s largest organization, chances are at some point your needs may exceed the scope of your internal capabilities. These limitations are not weaknesses in and of themselves. Instead, the risk here presents itself when an organization fails to realize its limitation and attempts to work outside of those bounds. It is important to know when to consider tapping into external resources such as consulting, incident response retainers and managed services.
  5.  Replace the emotional response with processes and procedures – Even the most highly skilled analysts will approach some potential security incidents with certain biases or preconceived notions. It is essential to implement quality processes and procedures which maximize the analyst’s skills, take full advantage of the available tools, and guide the incident response process. Processes and procedures surrounding incident validation, incident classification and initial resource allocation can ensure that the process stays on track and avoid straying down the wrong, costly road.

The most important goal of any security program must always remain to never under-respond to an incident. However, integrating these five tips into your security program will undoubtedly provide a better, more efficient process to determine what the appropriate level of response to each potential security incident should be, greatly reducing the risk of over-responding.

GDPR & Breach Notification – Finally We Will Get Some European Breach Data

The EU GDPR will be enforced from May 25th next year. GDPR mandates a wide variety of requirements on how data processors must manage customer and 3rd party data. Although it is not primarily focused on cybersecurity, it does contain vague requirements on security monitoring. This includes that data processors must establish a breach notification procedure, that include incident identification systems, and must be able to demonstrate that they have established an incident response plan.

GDPR and Data Breach Notification

Further, there is a requirement to be able to notify the supervisory authority of a data breach within 72 hours of becoming aware of a data breach or face a stiff financial penalty. This last requirement is of special interest beyond the impact on data processors. Because it means that for the first time, we will begin having reliable data on European breaches.

Historically, European companies have had no external requirement to be transparent about being affected by a breach. This has had the consequence that we have not had good data or an awareness of how well or badly European organizations are doing when it comes to preventing or responding to security breaches.

I am sure that if like myself, you have worked in forensics and incident response in Europe over the years, you are aware of far more breaches that are publicly disclosed. The only information available is when a breach is disclosed due to the press and law enforcement, or the impact is so great that it can’t be ignored. We also have some anonymized reports from some vendors and MSSP’s, but these are really no more than samples. While not without benefit, these also do not provide a reliable indicator, as the samples are not necessarily statistically representative This provides a false sense of how European organizations are faring compared to other regions and presents a skewed image of European security in general.

The true state of European security is an unknown and has been difficult to quantify. I have seen German articles for example that have claimed that German Security is better than the rest of the world because there are less known breaches. The absence of evidence is of course not evidence of absence. Something that has not been quantified cannot be said to be good or bad. More importantly, if you do not measure something, it cannot be improved.

It will be interesting to see whether GDPR will force European organizations to place more focus on Incident Detection and Response, and give us insight into the true state of European security.

Learn everything you need to know about GDPR breach notification requirements and how to prepare your organization for them in our new whitepaper: Incident Response with the new General Data Protection Regulation. Download your free copy here

Integrating Lessons Learned into Incident Response

Let me start by saying that total prevention is not attainable with today’s technology. Whether through negligence or ignorance, any data stored on a network is subject to unauthorized access by 3rd parties. Instead, we must combine Prevention with Detect and Respond. We know we are going to get breached, so we must focus on the how we deal with that.

One significant activity that can improve cyber incident response and enable the timely mitigation of threats is the transfer of knowledge after an incident as part of a formalized “Lessons Learned” phase of the incident response life cycle. Integrating successful processes and procedures from previously successful incident response activities can play a critical role in determining whether a business will suffer in terms of operational integrity, reputation and legal liability. A publicized security breach will lower customer confidence in the services offered by an organization as well as call into question the safety of their sensitive 3rd party information. This impacts a business credibility and translates directly into lost revenue.

In regulated industries, increased regulatory scrutiny is an additional consequence of a breach. This involves evaluating if the tools and procedures used in responding to security threats were sufficient. Integrating lessons learned into existing and future incident response playbooks ensures that the proper technologies and processes are deployed, and avoids accusations of gross negligence, expensive and time-consuming investigations and regulatory demands.

Procedural improvements can be incorporated into incident workflows via incident playbooks and ensure that all stages of the incident response process have been acknowledged and addressed. It also ensures that required security measures and procedures are documented and relevant stakeholders informed of their roles in case of an incident.

This process can be augmented through machine learning. Applying machine learning to this problem requires that all relevant data associated with incidents are analyzed and automatically applied to future incidents. DFLabs recently released DF-ARK machine learning capability to do precisely this. Our patent-pending Automated Responder Knowledge (DF-ARK) module applies machine learning to historical responses to threats and recommends relevant runbooks and paths of action to manage and mitigate them. DF-ARK requires sufficient training data – it begins with no knowledge, but learns from the experience and actions of your security team, becoming more effective over time. DF-ARK implements supervised case-based reasoning machine learning.

Figure 1DFLabs IncMan Automated Responder Knowledge

It also involves combining automated workflows and manual procedures to keep a human in the loop. This can be constantly improved by applying new observations and data, to fine tune existing methods and procedures identified in the lessons learned phase.

IncMan offers the R3 Rapid Response Runbook engine and Dual Mode playbooks to facilitate this. R3 Runbooks are created using a visual editor and support granular, stateful and conditional workflows to orchestrate and automate incident response activities such as incident triage, stakeholder notification, data and context enrichment and threat containment. Dual Mode Playbooks support manual, semi-automated and automated actions, meaning that users can automate the action without automating the decision.

Adding all of this together, here are 5 best practices for increasing the effectiveness of incident response via lessons learned:

  1. Encourage feedback from responders at every level. First, second and third line SOC operators and incident handlers each have a unique perspective that must be incorporated into future response playbooks.
  2. Review all relevant documentation to ensure compliance. This includes organizational policies or regulatory mandates to ensure any disparities are addressed in future playbooks.
  3. Chronicle any unanticipated or unusual events to extend procedures to mitigate similar occurrences in the future
  4. Annotate enhancements to existing processes that were identified during the incident response cycle.
  5. Designate a business unit or individual to be responsible for making necessary changes to existing playbooks, processes or procedures and to distribute these to stakeholders.

Capitalizing on lessons learned during incident response provides immediate and long-term benefits that contribute crucial time savings necessary to successfully mitigate future threats. Deploying a platform designed to facilitate the rapid inclusion of identified improvements to the incident workflow, such as DFLabs’ IncMan, can not only reduce the time it takes to fully investigate an incident but also reduces the overheads required to do so. If you want more information please contact us at DFLabs for a no obligation demonstration of exactly how we can improve your response time, workflows and remediation activities.

Demolishing the Ivory Tower – Collaboration and Communication in Incident Response

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]


3 Best Practices for Incident Categorization to Support Key Performance Indicators

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:

  1. 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.
  2. 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.
  3.  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

Slaying the Hydra – Incident Response and Advanced Targeted Attacks

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.

Interested to know what 412 IT professionals and cyber security professionals think on the latest Security Analytics and Operations trends?

A Weekend in Incident Response #35: The Most Common Cyber security Threats Today

Companies across different industries around the globe, along with government institutions, cite cyber attacks as one of the biggest security threats to their existence. As a matter of fact, in a recent Forbes survey of over 700 companies from 79 countries, 88 percent of respondents said that they are “extremely concerned” or “concerned” by the risk of getting attacked by hackers.

This fact is a clear indication that organizations have to ramp up efforts for enhancing their cyber resilience, but to do that successfully and in the most effective manner, they need to have a clear understanding of where the biggest cyber threats come from nowadays so that they can shape their cyber defenses accordingly. We take a look at the most common cybersecurity threats today, ranging from internal threats, cyber criminals looking for financial gains, and nation states.

Internal Threats

When talking about cyber security, some of the first things that usually come to mind are freelance hackers and state-sponsored attacks between hostile nations. But, many cyber security incidents actually come from within organizations, or to be more specific, from their own employees.

Pretty much all experts agree that employees are some of the weakest links in the cyber defense of every organization, in part due to low cyber security awareness, and sometimes due to criminal intent.

Employees often put their companies at risk of getting hacked without meaning to, by opening phishing emails or sharing confidential files through insecure channels, which is why organizations should make sure their staff knows the basics of cyber security and how to avoid the common cyber scams and protect data.

Connected Devices

With so many devices connected to the Internet nowadays, including video cameras, smart phones, tablets, sensors, POS terminals, medical devices, printers, scanners, among others, organizations are at an increased risk of falling victim of a data breach. The Internet of Things is a real and ever-increasing cyber threat to businesses and institutions, deteriorating their vulnerability to cyber attacks by adding more endpoints that hackers can use to gain access to networks, and by making it easier for hackers to spread malicious software throughout networks at a faster rate.

The Internet of Things is one of the factors that make DDoS attacks more possible and more easily conducted, and these types of attacks can have a significant and long-lasting impact on organizations, both in terms of financial losses and reputation damage.

Nation-State Attacks

Private entities and government institutions that are part of the critical infrastructure in their countries are under a constant threat of different types of attacks by hostile nations. As the number of channels and methods that stand at the disposal of hackers aiming to gain access to computer networks grows, organizations in the public and private sector are facing a growing risk of cyber attacks sponsored by nation-states that might have an interest in damaging the critical infrastructure of other countries, hurting their economies, obtaining top-secret information, or getting the upper hand in diplomatic disputes.

Most commonly, nation-state-sponsored cyber attacks use malware, such as ransomware and spyware, to access computer networks of organizations, as a means of gaining control over certain aspects of the critical infrastructure of another country.

No matter what types of attacks are common today, the number and level of sophistication of cyber threats to organizations are certainly going to grow in the future, which is why they have to constantly update and adjust their cyber defenses accordingly.

A Weekend in Incident Response #34: Proper Cyber Incident Response Plan in Critical Infrastructure Sectors Can Help Preserve Public Safety and International Peace

Cyber criminals do not discriminate against anyone when it comes to their targets of choice. They go after whatever organization they consider to have a potential to yield substantial financial benefits, without taking into account that some of their exploits might even lead to international conflict or an environmental catastrophe of unimaginable scale.

Cyber attacks on critical infrastructures have become commonplace lately, threatening public health and safety, and deteriorating relations between countries. Having in mind how sophisticated and advanced these cyber threats are, it is no wonder that it is extremely difficult to detect and prevent all of them, so a proper cyber incident response plan that would help contain the damage and recover from an attack becomes a necessity.

Incident Response Solutions for Critical Infrastructure Sectors

Critical infrastructure is comprised of organizations from various sectors, including health care, energy, telecommunications, financial services, government, and transportation, among others. All businesses and institutions that are part of one of these sectors are potential targets for cyber criminals.

To improve their ability to mitigate cyber security threats more effectively, these organizations are advised to create a workflow-based incident response plan relying on automation and orchestration platform.

Benefits of a Workflow-Based Security Incident Response Plan

By utilizing an incident response platform that allows an orchestrated approach while automating certain routine and time-consuming tasks, organizations can greatly reduce reaction times of their cyber security teams, and start the recovery process as soon as possible.

A workflow-based platform, that incorporates a set of actions tailored to specific types of cyber attacks, allows security teams to go through all stages of an incident response quickly and effectively, by providing them with concrete steps that need to be taken based on the type and scope of an attack. Furthermore, based on the attack types, knowledge sharing articles could be associated with the incident for faster and more efficient resolving.

In addition to workflows, automation-and-orchestration incident response platforms can easily integrate with intelligence sharing platforms, allowing organizations to send and receive essential cyber security events information, improving their ability to prevent future attacks.

Cyber attacks on critical infrastructure are probably going to become even more common, so investing in an incident response platform with automation and orchestration capabilities would be of great help to organizations looking to enhance their cyber defenses moving forward. By doing that, they would also be contributing to efforts for preserving international peace and public safety.