One common challenge for organizations in both the public and private sector that’s almost ubiquitous, is how successfully knowledge transfer happens between employees in a consistent way. A process for training and knowledge transfer often seems to be a low priority when other items are competing for time and money. As a result, knowledge transfer becomes somewhat an ad-hoc process. There’s frequently no formalized processes in place and this leads to inconsistent and unreliable performance of security team members.
What is knowledge transfer and why do we need it?
Essentially, it’s the transfer of knowledge related to incident response processes, intelligence, and procedures from senior, more experienced incident responders to less experienced ones, acting as an organizational force multiplier. “Force multiplier” here means taking existing resources and preparing them in a way that improves your organization’s or team’s processes. Depending on the industry, sometimes this is referred to as “tribal knowledge”.
Why do we need knowledge transfer as part of our IR infrastructure?
As threats evolve, our response capabilities have to evolve too. So how do we make sure that the knowledge picked up during an investigation by one incident responder is effectively communicated to the other team members? We all know that experience is the best teacher, but transferring the experience they have garnered from previous investigations can be time-consuming. One thing that incident response teams don’t have is a plethora of time to afford spending on all the tasks that need to be done. Therefore, a training program has to be built on a foundation of knowledge application (how it was effectively used), and not merely on the provision of knowledge (this usually comes out as anecdotal examples that frequently lack validity).
Knowledge transfer provides us with three key elements needed for a successful incident management process. That process has to be repeatable, defensible and consistent. Unfortunately, there are still many organizations that lack the capacity to transfer the knowledge and skills among employees, and a lot of the time as a senior more experienced expert leaves so does their knowledge. This is a significant issue that should be addressed and steps need to be taken in order to manage and mitigate this in the future.
Knowledge transfer is such an important segment of cybersecurity, it is strange how it’s still not a core part of SOC operations. There is hardware and software personnel leading to a growing necessity for integrating knowledge transfer into SOCs. Unfortunately, training doesn’t have a high priority when team members get so many alerts daily and are always reacting to the next potential serious incident. Typically an analyst joins an organization and they’re handed basic information and are thrown into the deep, without really having a good knowledge foundation.
Another important point to highlight is the difficulty to gauge the ROI. If you take an analyst that is untrained and measure how long it takes them to work on an incident compared to an analyst who is trained, it is a time-consuming process in itself. So, if we can’t gauge the ROI (it quickly becomes a non-priority considering the importance of SOC metrics, for example, mean time to detection, mean time to response and the number of incidents handled.
There are other alternatives to a formalized process, but with no structure it is easy for something such as an internal shared drive to become a dumping ground for information, leaving small positive impact on the daily operations.
Knowledge transfer doesn’t just concern incident responders. Legal experts need to be included for GDPR compliance and HR for personnel issues considering the dangers of insider threats. HR should be working closely with all teams and must be aware at all times of the processes taking place within the security team.
And finally, the stakeholders for ROI considerations and funding. It’s important that they know exactly how your processes and procedures work, even if it’s at a high level, so when the time comes to present quarterly reports and present them to the board, they’re have firm understanding exactly how it contributes to a positive ROI.
These are just some of the factors that determine why knowledge transfer should be a fundamental part of SOC operations and if knowledge transfer can be effectively facilitated it can have a positive impact on individual analysts, security teams and overall performance.
In a future blog we will discuss the 5 key elements of implementing successful knowledge transfer in incident response, but if you can’t wait, why not check out our recent webinar on-demand now “How to Facilitate Knowledge Transfer in SecOps Utilizing SOAR Technology”.
Responding to a new security incident in the fastest possible time frame is critical for any security operations center (SOC) or computer security incident response team (CSIRT), but having the necessary information at your fingertips is key in order to help improve response times and appropriately deal with the threat at hand. In this blog post we’ll take a closer look at how security teams can increase the efficiency and effectiveness of their response by adding context and enrichment to the alert information directly from ArcSight, when utilizing DFLabs’ Security Orchestration, Automation and Response (SOAR) platform and its many other bidirectional integrations.
Organizations are generating more log data than ever before and are increasingly turning to SIEM tools to help manage, correlate and alert on potential events from this large quantity of data. Once data is correlated and an alert is generated, enriching alert data is often a manual task which consumes a significant amount of analysts’ time. Pivoting from a single alert or from enriched information is often also a manual process, requiring many more custom written queries within the SIEM. Enriched and additional data must then be correlated manually by the analyst before it becomes actionable.
On a daily basis an analyst will face a number of challenges and is likely to be asking themselves the following questions:
- How can I use the SIEM logs to add context to a security event?
- How can I enrich information from the initial security alert?
- How can I pivot from the initial security alert to further my investigation?
The DFLabs and ArcSight Solution
DFLabs and MicroFocus ArcSight bring SOAR and SIEM together to allow rapid, informed responses to security incidents based on enriched, actionable information. DFLabs’ IncMan SOAR platform allows users to automatically query ArcSight to pivot from an initial alert to gather increase insight into the activity within the organization. IncMan also allows users to enrich information retrieved from ArcSight, such as IP addresses, hostnames and domains, using any number of IncMan’s other integrations.
About MicroFocus ArcSight
ArcSight is an industry-leading Security Information and Event Management (SIEM) solution from MicroFocus. ArcSight collects and analyzes events from across systems and security tools. It detects security threats in real time so that analysts respond quickly, and it scales to meet demanding security requirements. ArcSight’s advanced distributed correlation engine, helps security teams detect and respond to internal and external threats, reduces response time from hours or days to just minutes.
To get a real understanding of how the two solutions work together, here is a simple use case in action.
A Web Application Firewall (WAF) has observed a potential attack against an application server in the organization’s DMZ. IncMan automatically responds by initiating an appropriate runbook for the alert. The runbook begins by performing basic enrichment on the source IP address of the malicious traffic. This basic enrichment is followed by a query for IP reputation information on the source IP address from the organization’s threat reputation service of choice.
Following the threat reputation search, ArcSight is queried for any other events which have been recently generated by the source IP address. If ArcSight returns any other recent events generated by the source IP address, or the source IP address has a negative threat reputation, the severity of the incident is automatically upgraded to High. The analyst is then presented with a user choice decision to determine if the source IP address should be blocked at the perimeter firewall. If the analyst chooses to automatically block the source IP address, a ticket will be created in ArcSight Enterprise Security Manager (ESM) to notify the appropriate teams to follow up on the emergency change according to the organization’s policies.
These actions are followed by a second query to ArcSight, this time for any other recent events involving the web application server. If ArcSight returns any other recent events generated from the web application server, the severity of the incident is automatically upgraded to High (unless it has already previously been upgraded). The runbook concludes by performing a query of the organization’s endpoint detection solution for all recent events from the web application server. This information will be retained for review by the analyst during the investigative process.
In summary, here are the actions available to security analysts by using ArcSight.
- Get Active List Entries
- Search Into Events
- Add Active List Entries
- Clean Active List Entries
- Create Ticket
- Get Ticket
- Update Ticket
Integrating ArcSight with DFLabs’ IncMan SOAR allows organizations to efficiently triage the volume of alerts being generated by the SIEM, automatically prioritizing those alerts which may pose the greatest risk to the organization. By automating and orchestrating the SIEM with other security solutions, IncMan SOAR can automatically enrich the alert information, then pivot based on the enriched information as an analyst would do during a manual investigation. This ability to automatically enrich and pivot allows IncMan to more accurately prioritize incidents which may initially seem innocuous.
SANS recently released their 2018 SOC Survey and many of their findings were of no surprise to anyone who has been responsible for maintaining their organization’s security posture. Many respondents reported a continued breakdown in communication between NOC and SOC operations, lack of dynamic asset discovery procedures, and event correlation continues to be a manual process even though SOC staffing is being worn thin by the surmounting responsibilities they have to take on.
Why Measuring SOC-cess Matters?
Anyone who has been a part of a security team knows these issues are an everyday battle, but those “common” issues were not what caught me off guard. The most shocking statistic I gathered from this survey is that only 54% of respondents reported that they are actively using metrics to measure their SOC’s success! I was taken aback by this finding and couldn’t help but wonder if all the other reported SOC deficiencies could be directly related to this missing link?
I have been in the security industry for close to ten years, most of which was spent as a SOC analyst and SIEM engineer for a large MSSP. It was my responsibility to be an extension of my client’s security arm and those clients ranged from large Fortune 500 companies to small family owned businesses. Each client was unique, what one found to be important, another thought of as noise. The diversity between each of these clients taught me early on how important it is to understand what their definition of success was so that I may help them to not only achieve their security goals but to assist them in staying ahead of today’s rapidly expanding threat landscape.
This diversity also taught me another valuable lesson: not all security programs are created equally. Naturally, my larger clients had a more mature security posture, they knew what they wanted and what it would take to get them there, and they had the funding to back it up. Unfortunately, some of my smaller clients were not as lucky. They were severely understaffed, their IT department was the Security department, they lacked adequate funding to stay ahead of the ever-growing security curve, and in many cases, the measurement of success resembled a game of whack a mole.
Does this sound familiar? If the answer is yes, you can rest assured that you are not alone. Even the most secure, highly funded organizations have struggled with these obstacles. However, I believe one of the biggest differences between these organizations and the organizations striving to be like them isn’t directly due to the lack of funds, but instead the metrics they are using to show value in what they are trying to accomplish.
Don’t get me wrong, funding is and always will be an obstacle that organizations, large or small, will have to overcome when trying to build and maintain a security program. But the larger and more dangerous obstacle is the one we are creating for ourselves by not measuring and monitoring our security strengths and weaknesses through a strong security metrics program.
This type of security program will be as different as the organization it aims to define. To truly understand what success looks like for you there are a few recommended tasks, that when completed, will give you a greater understanding of your environment and a strong foundation for your security metrics program.
How to enhance your security program
- Conduct a risk assessment
A risk assessment is meant to help identify what an organization should be protecting and why. A successful assessment should highlight an organization’s valuable assets and showcase how they may be attacked and what would be at stake if an attack is successful. Armed with the results of this assessment, organizations can not only begin to address their deficiencies but now have a solid set of metrics that they can use to measure their success as they move forward.
- Perform vulnerability assessments
Vulnerability assessments are another vital security tool which is designed to detect as many vulnerabilities as possible in an environment, and aid security teams in prioritizing and remediating the issues as they are uncovered. All organizations regardless of maturity will benefit from these types of assessments, but organizations with a low to medium security posture may benefit the most. The result of these assessments will help give greater definition to what an organization’s metrics should consist of and what steps are necessary for continued success.
- Adopt a security framework
Even if you are not held to a compliance standard, adopt a security framework anyway. I understand that choosing a framework to model form does not guarantee an organization’s safety, but it is proven that those organizations who adopt a standard have a higher security maturity and are more likely to identify, contain, and recover from an incident faster than those who do not follow security program’s best practices. These frameworks, in conjunction with the security assessments mentioned above, were built to give organizations a blueprint of how to best protect their environment and measure their successes.
I sincerely believe in the value of a rich metrics program and have seen first hand what it can do for an organization. With the level of sophistication in today’s cyber attacks and the environments they target, we can no longer afford to leave our security up to chance. It is my hope that when SANS publish their SOC Survey for 2019, that we have taken the steps necessary to change this statistic because I know as an industry we can do better.
If you want to read more about KPIs and the metrics that we suggest should be set, monitored and measured for a more efficient and effective security program, read our white paper titled “Key Performance Indicators (KPIs) for Security Operations and Incident Response”.
Each year SANS conducts a global Security Operations Center – SOC survey to identify the latest trends, recommendations and best practices to enable organizations to successfully build, manage, maintain and mature their SOCs. With the continual increase in volume and sophistication of cyber attacks it is crucial that SOCs are performing as effectively and efficiently as possible to respond to all security alerts and potential incidents, as well as providing a clear benefit and ROI to the organization’s current security program.
This week SANS released the results of their 2018 survey and what they defined as “SOC-cess”! This blog will cover a quick snapshot of the report highlights and we will delve deeper into some of the results in future posts.
SANS 2018 SOC Survey Highlights
Regardless of whether you are a security analyst, a SOC manager or a C-level executive, I am sure there will be some key learning points and takeaways for you, with some of the results resonating with you and your organization. So, how does your SOC stack up against the 2018 survey results?
Here are the key findings.
- Only half of SOCs (54%) use any form of metrics to measure their performance
- There is a lack of coordination between SOCs and NOCs (only 30% had a positive connection)
- Asset discovery and inventory tool satisfaction was rated the lowest of all technologies
- The most meaningful event correlation is still primarily carried out manually
- Over half of respondents (54%) did not consider their SOC a security provider to their business
- The most common architecture is a single central SOC (39%)
- Nearly a third of SOCs are staffed by 2-5 people (31%) and just over a third by 6-25 people (36%)
- Top shortcomings to SOC performance included:
- – Shortage of skilled staff (62%)
- – Inadequate automation and orchestration (53%)
- – Too many unintegrated tools (48%)
What do these results actually mean? I am sure they can be interpreted in many ways. For me some results were not surprising, such as the shortage of skilled labor is the number one shortfall affecting SOC performance. However, some were quite startling, in particular surrounding the number of SOCs that do not use any form of metrics to measure performance – results indicating nearly half.
With the growing number of threats also comes a growing number of challenges, and today it just isn’t possible for SOC analysts to manually carry out everything that is needed to run the SOC effectively. Investment in technology seems to be a must to help improve efficiencies, but it needs to be the right technology for the organization. The survey results show a clear need for SOCs to invest further in tools such as automation and orchestration, which was identified as the second most common shortfall affecting performance at 53%.
Defining and Measuring SOC-cess
What is “SOC-cess” and how can we determine what an efficient and effective SOC is? SANS definition of SOC-cess is as follows.
“SOC success requires the SOC to take proactive steps to reduce risk in making systems more resilient, as well as using reactive steps to detect, contain and eliminate adversary actions. The response activities of SOC represent the reactive side of operations.”
I am sure it can be defined and is defined in a multitude of ways across different organizations, but metrics will always be a key factor. Of those SOCs surveyed, the top three metrics measured included:
- Number of incidents handled
- Average time from detection to containment to the eradication of an incident
- Number incidents closed in a single shift
Without these metrics, there is nothing to compare to or benchmark against to measure the overall performance and capabilities of the SOC and it will be difficult for management to justify any additional investment in additional tools or resources if the effectiveness and return on investment can’t be calculated or quantified. Therefore, measuring metrics should be a number one priority for any SOC to determine its success, not only by the 54% of SOCs that currently do so.
Summary of Findings
Overall the SANS 2018 SOC survey results indicated that there was somewhat limited satisfaction with current SOC performance with an absence of a clear vision and route to excellence. Also, survey respondents felt that their SOCs were not fulfilling expectations and many areas could still be improved, although there was an overall consensus of the key capabilities that they felt must be present within a SOC.
Compared to last year’s survey, the results showed a minor improvement; however, there are still many challenges facing today’s SOCs and the teams operating within them which need to be overcome.
There are though a number of things that can help to drive improvements and these include better recruitment and internal talent development, improved metrics to ensure the SOC is providing value to the organization, a deeper understanding of the overall environment that is being defended and better orchestration both with the NOC and SOC, using orchestration tools to drive consistency.
Overall, the existence of a functional and mature SOC is a critical factor in an organization’s security program to adequately protect the business from the ever-evolving threat landscape and SOCs will need to continue to work on improving what they already have in place.
How Can DFLabs Help?
A Security Orchestration, Automation and Response (SOAR) platform, such as that offered by DFLabs can not only help to tackle the orchestration and automation shortfalls as mentioned above, but can also help to tackle a number of other common SOC challenges and pain points, including the shortage of skilled workforce, the integration of tools, as well as measuring SOC performance metrics.
Ask DFLabs today how we can help you to transform your SOC with SOAR technology and request a live demo of IncMan SOAR in action to see more.
Threat hunting is defined as an iterative and focused approach to searching, understanding and identifying internal adversaries that are found in the defender’s network. It’s been shown that incident response automation tools can provide Security Operations Center (SOC) team members with additional time that can be leveraged in a more focused, threat hunting role within the SOC environment.
The SOC staff members should have some understanding of how they can use this additional time provided by incident response automation to enable them to hunt for threats, rather than spending valuable time and resources gathering threat information which could otherwise be done in an automated fashion. It’s long been established as we make the migration from threat prevention to threat discovery that malicious actors and processes are frequently well-hidden within the organizations infrastructure and in order to effectively locate and investigate them we must start by asking the 5 W’s, who, what where, when, why and perhaps most importantly, how.
SOC team members must first understand what threat hunting is to be truly effective. The staff members should channel their question on the three tenets that make up the threat triangle; capability, intent, and the opportunity. By focusing on these three tenets, threat hunters can leverage orchestration to accomplish not only the system monitoring but the automated data gathering to support this expanded role without adding additional infrastructure. Additionally, team members must understand that the threats can be human and not just, for example, malware that is directed at them. This, coupled with an understanding of the affected systems function, will help provide the insight into possible contributing factors to the incident.
As the level of automation scales upward, we’ve seen a corresponding scaling of the transition from simple incident data gatherers to data hunters. Additional time and resources will become available to teams that leverage incident automation, permitting them to forego the traditional gatherer role and begin to embrace a more proactive hunter role. The good news is both of these roles can be supported within the SOC and also within the same Security Orchestration, Automation and Response (SOAR) platform. IncMan SOAR from DFLabs provides the necessary combination of force multiplication and machine learning to ensure that not only are incidents capable of being prioritized automatically, but the necessary actions for successful resolution are available at incident inception.
If you would like to see how a SOAR platform can give your incident response team the necessary tools to make the migration from simple data gatherers to threat hunters, reach out to us for a free, no obligation demo.
Not so long ago we used to hear about a cyber-attack or a new form of vulnerability in the news perhaps on a quarterly or monthly basis. Today, they are becoming increasingly more frequent and I don’t think a day goes by that we don’t read in the headlines about the consequences an organization is having to face, due to another attack. McAfee recently reported a staggering eight new cyber threats a second in Q4 2017.
With the sophistication of attacks also continuously evolving, the modern CISO is now facing up to the fact and preparing for a “when it will happen” scenario as opposed to “if it will happen”, as cyber incidents become more inevitable. Based on this, their cybersecurity strategy is being turned on its head and instead of focusing more on how to prevent an incident from occurring in the first place, they are now heavily investing in technologies and solutions to help identify, manage and contain an incident, in order to minimize the impact to the organization when it does occur.
In larger enterprises today, it is common to have a Security Operations Center (SOC) and/or a Computer Security Incident Response Team (CSIRT) to monitor, manage and respond to incoming security alerts, but with this, there are numerous challenges that are continuously being faced. Our recent blog “How to Implement Incident Response Automation the Right Way” specifically addressed the challenge of increasing volumes of alerts, resulting in an exponential volume of mundane tasks and discussed how utilizing automation should be implemented to overcome this. In reality, the number of challenges is probably many more than what we will cover in this blog, but here are our top five, which we believe are currently having the biggest effect on SOCs and CSIRTs today.
Top 5 Challenges Faced by Security Operations Centers
1. Increasing Volumes of Security Alerts
With the snowballing number of security alerts being received, valuable analyst time is being consumed sorting through a plethora of security alerts. Most commonly, time is wasted performing a multitude of mundane tasks to triage and determine the veracity of the alerts, often resulting in alerts being missed or those of more damaging consequences slipping through the net as they are overlooked. As you can probably imagine, analysts time would be better spent working on the more sophisticated alerts that need human intervention, as well as proactively threat hunting, in order to minimize the time from breach discovery to resolution.
2. Management of Numerous Security Tools
As a wider range of security suites are being adopted by SOCs and CSIRTs, it is becoming ever more difficult to effectively monitor all of the data being generated from the multiplying number of data points and sources. A typical security operations center may use a combination of 20 or more technologies, which understandably can be difficult to monitor and manage individually. It is therefore important to be able to have a central source and single platform to summarize all of the information as it is being generated and to be able to have a helicopter view of your overall security environment to manage, monitor, and measure security operations and incident response processes effectively.
3. Competition for Skilled Analysts and Lack of Knowledge Transfer Between Analysts
With the global cybersecurity talent shortage to hit 1.2m by 2020 and to increase to 1.8m by 2022, the pool of suitable analysts will only continue to diminish over time, with the level of competition becoming more fierce for analysts that have the required skill set. As with most companies and industries, workforce comes and goes, but knowledge transfer is particularly important within a security operations center and incident response teams, in order to ensure the correct response and process takes place within the minimal amount of time, reducing the time to incident detection and time to incident resolution. This lack of knowledge transfer can inevitably lead to increased response times and wasted resources.
4. Budget Constraints with Security Incidents Becoming More Costly
As within most organizations large or small alike, budgets are always restricted in some way, shape or form. In order to authorize spending, a clear positive ROI usually needs to be forecast and/or proven. Security operations and incident response are notoriously difficult to measure, monitor and manage, (why not read our recent whitepaper entitled “KPIs for Security Operations and Incident Response” to learn more), so justifying spend is always difficult. With the increasing number of cyber-attacks, organizations are increasing the level of investment in cyber security tools, but what level of spending is necessary and what amount outweighs the benefits it will achieve? Can you put a price on the consequences of a potential incident such as a data breach, knowing you will likely face a hefty fine, as well as brand and reputation damage?
5. Legal and Regulatory Compliance
Meeting a growing number of legal and regulatory compliance such as NIST, PCI, GLBA, FISMA, HITECH (HIPPA) and GDPR to name a few, as well as industry best practices, will inherently have an impact on any organization, but can have a heavy bearing depending on the specific industry or geographical location. Using the example of the upcoming Global Data Protection Regulation, taking effect on May 25, 2018, it is even more important for security operations centers to have mandatory processes and procedures clearly in place which are conducted in a legally and policy-compliant manner. Providing sufficient incident reporting and breach notification within the required parameters (in the case of GDPR to notify the supervisory authority within 72 hrs of a breach) is going to be key, or the legal, financial and reputational impact and repercussions could be significant.
Based on these five challenges alone, enterprise SOCs and CSIRTs are struggling to remain efficient and effective and are increasingly being forced to do more with less, while striving to keep up with the current threat landscape and a plethora of security alerts.
With security incidents becoming more costly, enterprises need to find new ways to further reduce the mean time to detection and resolution. As a result, security and risk management leaders will see the business need to invest in Security Orchestration, Automation and Response (SOAR) technology and tools, such as the IncMan SOAR platform from DFLabs, to help improve their security operations proficiency, efficacy, and quality, in order to keep their cyber incident under control.
If you are interested in reading more about how SOAR technology can help to address these challenges in more detail, look out for our future blog on the topic coming soon.
At the heart of incident response, and by extension of Security Automation and Orchestration technologies, resides the Cyber Incident. A typical definition of a cyber security incident is “Any malicious act or suspicious event that compromises or attempts to compromise, or disrupts or tries to disrupt, a critical cyber asset”. Almost everything we do in a SOC or a CSIRT is based on incidents, and there are a variety of potential incident sources, for example:
- Alerts from cyber security detection technologies such as Endpoint Detection & Response or User Entity Behavior Analytics tools
- Alerts from Security Information & Event Management Systems (SIEM)
- Emails from ITSM or case management systems
- Website submissions from internal stakeholders and whistle-blowers
- Phone calls from internal users and external 3rd parties
This diversity of incident sources means that a solid SAO solution must offer a variety of different methods to create incidents. Regulatory frameworks also frequently mandate being able to originate incidents from different sources. DFLabs IncMan offers a rich set of incident creation options.
There are three primary ways to create incidents in IncMan, offering flexibility to accommodate a variety of incident response process requirements and approaches.
Option 1: Automated Incident Creation
We will feature automated incident creation in a more detail in a future post. In the meantime, I will show you the location of this feature.
Select settings menu, then head to the external sources:
You will see that under the external sources option there are 3 options available to use as sources to automate incident creation:
- Incoming events automation, for CEF/Syslog
- Incoming Mail automation, for a monitored email account
- Integrations, for all QIC integration components.
Automating incident creation supports a variety of filters to support a rules-based approach. In addition, it is also possible to create incidents using our SOAP API. Certified 3rd party applications use this mechanism to create incidents within IncMan, for example, Splunk.
Option 2: Manual Incident Creation
Click the incidents menu option, then click the + symbol selecting the incidents screen
Fill out all mandatory fields (these can be defined in the custom fields screen) then step through and complete the incident wizard to create the incident:
Once all relevant fields have been completed, click save and this incident will then appear in the incident view and apart of the queue you assigned in the details screen.
Option 3: Incident creation from source
Select an incident source for the incident you want to create, for example, a Syslog or CEF message, an Email, or a Threat intelligence source (STIX/TAXI, ThreatConnect):
In this screen, you can then convert this source item to an incident, or link the source to an existing incident.
Today, we will talk about our dashboards in IncMan. We will see how to add, delete and generally organize the dashboard widgets. IncMan widgets can display charts, graphs and tables to display and track Key Performance Indicators. IncMan supports role-based dashboards. This is a key requirement for any SOC, facilitating that the right information is available to the right person based on their role, duties, and needs. Which information is required for any individual or team will differ from organization to organization, so we support customization to create unique and dedicated dashboards for every persona.
How to use IncMan Dashboards and Widgets
This default screen displays a number of out of the box charts to get you started. But you will want to customize the dashboard with the widgets you need for your role.
1. To begin creating your unique dashboard, select “Customize” to open the menu.
2. The dashboard screen is split into 4 distinct parts: top, left, right and bottom. By selecting the “+” symbol, you can add an additional widget from a number of pre-defined templates. For this example, let’s add the “Incident Overview” widget:
3. You can change the name of the widget in the configuration screen, for example, “GDPR” or “Urgent Incidents”. You can also specify the applicable timeframe for the widget, and the refresh rate, to determine how often the widget will be updated.
4. Next, we will configure the widget filters to determine the data that the widget displays.
We can apply search filters to narrow down the displayed incidents. You can filter by a variety of attributes, including tags, incident priority, the Incident Response process stage, and any custom fields you have defined. Every filter that is selected will also need a corresponding value assigned to it in the values tab.
5. Once you’ve selected the values you want to add into the table, the final step allows you to define which columns will be displayed in the widget.
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.
I have often talked about the benefits of employing flexible playbooks to deal with evolving cyber incidents and unique threat scenarios, and in these series of blogs, I am going to explore some of the points of emphasis when creating a new playbook.
The advantage to Security Orchestration, Automation and Response (SOAR) platforms, and in particular our IncMan platform, is the ability it provides to tailor playbooks or runbooks to deal with all manner of cyber incidents. These Playbooks are defined by three key factors:
1.Phases: Determine the number of phases for the response process based on the incident scenario. The phases are really a placeholder for what you are trying to achieve in your response.
2.Automation: How much automation will benefit the given scenario without hindering or otherwise adversely impacting your business.
3.Actions: What actions apply to each phase and what is the benefit to each action.
Wash, Rinse, Re-playbook.
Play books, or runbooks, should never be static and hard-coded for a fixed set of events. Ultimately, incidents will differ and you should always remain in control, ready to adapt and adjust the response workflow. This flexibility is vital should a Plan B need to be executed. The approach of IncMan to security playbooks & runbooks support both mature and emerging SOC teams by providing multi-flow advanced runbooks to the former, and for the less mature, a simplified playbook containing a dual mode where automation and manual actions can co-exist.
In talking with CSIRT/SOC managers, I have learned that they have typically aligned themselves with a particular standard. Most organizations follow the likes of ISO for Incident Response, NIST
800-62 or alternatives along the lines of CREST or NISA. Structured incident handling processes based on these standards are a great baseline, but how about also having actions and reactions pre-prepared and ready to respond immediately according to the threat you face? Can you see the instant advantage in having smaller, simpler playbooks and runbooks specific to an adversary or threat scenario?
Dealing with incidents with tailored playbooks will ultimately provide better threat coverage as each has enrichment and containment actions that are concentrated on the tasks specific to a given scenario. Additionally, allowing your SOAR product to tie the dots to bring enrichment to the observables and the indicators encountered in incidents will bring measurable value to the increased speed of the incident response process. Allowing analysts dynamic interaction at all phases of the workflow will help also help your reactions become more efficient. This mix of structured playbooks and dynamic response capability can also help push the CSIRT teams into a more pro-active mindset, allowing system and network-level security policy and infrastructure configuration changes to be handled on the fly while leveraging current and accurate information, and all from a single response console.