In our recent blog post, we discussed the need for knowledge transfer and why it has to become a crucial part of the incident response process and an organization’s security program. This time we will take a closer look and take the topic one step further to discuss how to successfully implement knowledge transfer in incident response.
It’s important to note that knowledge transfer within an organization does not only happen within Security Operations Centers (SOCs) between incident responders and must also include other departments involved in the IR process. The Legal department should be included in order to ensure and oversee regulatory compliance as well as the Human Resources team to monitor the security incident processes that take place across the entire organizational landscape. Last but not least, management stakeholders need to be updated on areas such as ROI to ensure they have the latest data available to make key decisions.
Based on the need for knowledge transfer in incident response and the difficulties it currently presents within security teams, this blog post focuses on the details of 5 key elements needed for achieving successful knowledge transfer.
- Understanding your audience – knowing the people who are going to receive the knowledge that you’re going to put out (for example, you’re not going to use technical terms for a legal audience).
- Develop a focused curriculum – creating a curriculum that’s engaging to the audience you are going to work with.
- Designate the appropriate delivery method – there’s a number of different delivery methods for moving the transfer of knowledge (for example automated, manual or a combination of both).
- Designate a messenger – this is probably one of the most critical parts of the five key elements because you’ll want someone who is going to be speaking from the point of view of actually having been there, or having experienced the things they are to deliver.
- Evaluate the results – Is it the right information that we’re pushing forward? Is this what they need to be successful? Is there a way to edit this information efficiently and effectively to keep it up to date?
Breaking Down the Elements
Now let’s break down the components of knowledge transfer in incident response in more detail and see how we can implement them individually to achieve success.
Understanding your audience
You must provide as much context as possible to ensure the clarity of the task. Moreover, providing context is essential for people to pull that information in and process it within their own experience. Another important step is to identify who will actually be getting the most benefit from the information, not just who may top the organizational charts – the people who are actually expected to accomplish the tasks are the priority.
Craft the message to the audience (IT jargon with legal and HR folks could result in blank faces). Make sure that you craft your message so that the audience understands what you’re trying to deliver. Don’t be afraid to schedule time after the training session for follow-up questions. This is sometimes your most valuable interaction with the attendees.
Developing focused materials
The information transfer should focus on clearly defined goals for the identified audience, for example, ITSEC has one set of goals, legal another, senior stakeholders yet a third. Focus the information on those tasks that are relevant to resolving the identified issues – you should make sure to address only those tasks that are critical to solving a certain issue.
Materials should be based on regulations and standards. If there isn’t a defined set of regulations, utilize your local policies and best practices from the industry. All of these things ensure validity in the process of knowledge transfer.
Determining the appropriate delivery method
This can be performed manually or automatically. If it is done manually, the following tips should be taken into consideration:
- Have regularly scheduled training sessions – having someone in, take a seat – this can sometimes be tricky because you might be pulling people during their off time, or you have to do it in shifts
- Internal methods of communication – this will help passing messages along, or use some type of a chat, intranet, or something similar to that nature, so people can stay in tune with what exactly is happening
- Access to webinars and online content – this is more self-styled; if an incident responder hesitates on how to do a particular task, they can look for a webinar online or content that has the answers from previous historic events.
On the other hand, if this is performed automatically, then the following steps should be considered:
- Have a formalized knowledge base – this basically means that you can put all of the knowledge transfer articles in one centralized database which is easily accessible
- Create structured playbooks – these are an integrated part of security orchestration automated response – incident responders are using them now as part of their incident management program. Being able to use structured playbooks to transfer knowledge is like killing several birds with one stone.
Designating a messenger
In order to choose the most suitable person for this position, there are a number of qualifying factors to take into consideration. The best candidate should be an expert in the subject matter, should allow a cross-section of subject matter experts to contribute and also ensure they are part of periodic reviews.
Evaluating the results
As the final step of the process, it is key to ensure results are evaluated and this is an integral part of the post-incident response process. It should be determined if the knowledge transfer process was effective, was any information missing or could any further processes be improved in the future. Based on these evaluations and developments, training materials should be updated and also undergo periodic reviews to ensure they remain up to date.
With all of the above said, it can be easily concluded that knowledge transfer loses its main purpose when executed ad-hoc and in an informal manner. Organizations need to figure out the importance of knowledge transfer and come up with a structured, multi-layered program that will be designed to be of service to all stakeholder audiences and more importantly, is in line with the goals of the organization and the needs of the clients. In the case of incident response, implementing an automated approach, using a centralized database, with designated playbooks for different incident types will ensure knowledge transfer is consistent and repeatable and remains within the business.
If you would like to learn more about how to facilitate knowledge transfer, in particularly within security operations and by utilizing security orchestration, automation and response, check out our recent webinar here “How to Facilitate Knowledge Transfer within SecOps Utilizing SOAR Technology”.
If you’re playing buzzword bingo in 2018, Orchestration and Automation (O&A) are two words you want to see on your card. Unlike some buzzwords, O&A are not just fluff; when implemented properly, Orchestration & Automation are real solutions which can provide tremendous benefits to overworked security teams.
However, as the industry starts to see real benefits emerge in new classes of solutions, more and more products start to incorporate aspects of that solution into their existing products. This tends to muddy the waters in the product space and leaves potential customers confused (talk to a SIEM vendor if you want to hear someone else’s perspective on this problem).
Before we go any further, let me clarify something; this blog is not intended to be a shot at anyone’s marketing or any vendor incorporating Security Orchestration and Automation into their existing product. To the contrary, when implemented properly, Automation and Orchestration can benefit customers at many levels. If you’re in a product space where O&A can provide value to your customers, you should absolutely be looking into it. Instead, this blog is intended to answer the question we are getting asked more and more recently; “I see vendor X is doing orchestration and automation now, are they your competitor? How are you different?”
Orchestration and Automation
In terms of O&A, there are two main categories of solutions (of course, there are always some that fall somewhere in the middle:
- Security Orchestration, Automation and Response (SOAR) solutions
- Other solutions which have implemented some level of Orchestration and Automation into their existing (non-SOAR) solutions
When you begin to compare these two categories, there are two significant differentiators. Non-SOAR solutions tend to focus on O&A within their own product, or within a similar product space (let’s use vulnerability management as an example). Their focus on one particular product space tends to make them very capable of addressing advanced use cases in that product space, however, they typically do not support use cases outside of that space. A SOAR solution, on the other hand, should be capable of performing O&A across many different product spaces in one cohesive solution.
The other significant differentiator between SOAR and non-SOAR solutions is their ability to perform other Response (the R in SOAR) and incident management functions. Whereas a SOAR solution should be able to perform these other Response functions, a non-SOAR solution is typically limited in this regard.
Which is the right solution?
As always, it depends on the problem you are trying to solve. If you are trying to increase your efficiency in vulnerability management, threat intelligence, endpoint detection or network management, a non-SOAR solution in one of these spaces with O&A capabilities may be the right solution for you. If you are trying to solve inefficiencies across all of these spaces, you may want to invest in a SOAR solution. Of course, there is also nothing wrong with layering these technologies either; perhaps a focused solution which includes O&A is required in one space, which can then be orchestrated with other security products through a SOAR solution.
So, getting back to answering the original questions, “I see vendor X is doing orchestration and automation now, are they your competitor? How are you different?” If vendor X is not a SOAR solution provider, there is probably some overlap, however, they are usually focused on solving a different or more specific problem to DFLabs, so they are most likely not a competitor. In fact, in some cases, they may be a technology partner. In these cases, our core differentiators are usually those listed above. If vendor X is a SOAR solution provider, they may very well be a competitor and our core differentiators will depend on the specific vendor.
In either case, DFLabs would be happy to discuss its differentiators from other SOAR solutions in a more personalized way, so if you have any questions or would like a one to one demo of our IncMan SOAR platform, please do get in touch. However, I wanted to take a few minutes out of the day to address this common question you may have as you start your journey down the O&A road.
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”.
Building an effective security strategy in organizations today requires the right combination of experts, processes, tools and technologies. Luckily, there are many different ways in which you can organize them to fit your company’s needs.
The two types of teams most often mentioned today are Security Operations Centers (SOCs) and Computer Security Incident Response Teams (or CSIRTs). SOCs and CSIRTs have distinctive roles and responsibilities, so deciding which one is better for your organization’s security program isn’t always easy. This blog post will focus on explaining their main objectives and how they differ in structure, which may help you to decide which one is more suitable for your organization’s internal infrastructure and strategy, especially if you are looking to set one up in the near future as your business expands.
Security Operations Center (SOC)
The term SOC bears the connotation of an environment designed specifically to defend corporate data and networks, and it can be used to describe the facility where carrying out security tasks takes place or the people who are responsible for that.
A SOC is the “brain” of a security organization, as it acts as the center of all roles and responsibilities, with the main goal of protecting information within the organization. Its main tasks are:
- Incident management / response
- Anything that involves managing and protecting information within the company
Furthermore, the SOC also monitors people, technology and tools, and processes involved in all aspects of cybersecurity. Often companies have a SOC before they decide to establish a separate CSIRT. The end objective of every SOC is to monitor and take care of every cyber activity that takes place and ultimately ensure the organization is protected against any type of attack.
The SOC is also responsible for incident response if there is no formal CSIRT established within the organization. If there is, the SOC helps the CSIRT in responding faster and more efficiently to a cyber threat.
The SOC is responsible for the following:
- Monitoring the security of users, systems, and applications
- Prevention, detection, and response to security threats
- Creating and managing procedures
- Integration of security systems with other tools
What makes a SOC unique and different from other units within the organization is its centralized role with a strong focus on combining techniques, skills, and technology, by utilizing tools to increase the protection of the company against threats. It’s also important to underline that even though incident prevention and management is not its specialty, a SOC may still cover these events as well, being a department that covers all things related to cyber security.
Computer Security Incident Response Team (CSIRT)
CSIRT is a centralized department within an organization whose main responsibilities include receiving, reviewing, and responding to security incidents. CSIRTs may work under SOCs, or function individually, depending on the organization’s needs and structure.
The main goal of a CSIRT is to minimize and control the consequences from an incident. It’s not just addressing the attack itself, their role involves communicating with boards, executives, and clients about the incident.
Some of its main responsibilities include:
- Prevention, detection, and response to security threats
- Ranking alerts and tasks
- Investigating and conducting forensics on incidents
- Coordinating strategies
What do CSIRTs do?
The basis of every CSIRT is providing incident management. The CSIRT is the central point of contact in the event of a security incident. Depending on how fast a CSIRT team responds to an incident, it can limit the damage from the incident by providing rapid response and recovery solutions. This ensures the workflow is uninterrupted and lowers the overall costs.
Incident management presupposes three functions: reporting, analysis and response. With this being said, the CSIRT activities usually involve the following:
- Understanding incidents – CSIRTs must be aware of the nature of the incident and the consequences that might arise from it. A repository helps teams gain insights of the patterns of a certain cyber attack and this could lead to future activities that could prevent the occurrence of such attacks.
- Handling negative impact – CSIRTs carry out elaborate research of a certain problem and recommend solutions for it.
- Assist other departments – CSIRT teams distribute alerts across the organizations on the latest threats and risks.
- Compose security strategies
Does my organization need a CSIRT?
The CSIRT within an organization may be a formal unit or an ad-hoc team, depending on the company’s needs. If your organization is not facing a cyber threat on a regular basis, the need for a CSIRT might not be as big as for larger organizations, or companies in high-risk industries, such as healthcare, finance or government. In industries such as these, responding to threats happens daily and there’s a need for a formal, full-time CSIRT.
Whatever the needs of your organization, don’t forget that a CSIRT team will evolve with time. What might start as an ad-hoc team may develop into a fully functioning department as the business expands and progresses.
Regardless of the final choice, which will depend on a number of individual requirements and factors, (including but not limited to the size of the organization, the number of threats it faces, the industry and the company’s security program maturity), don’t forget that whatever team is established, it is always important to clearly define roles and responsibilities, have efficient processes in place that can be automated, and implement the right tools and technologies that will help your team do their job more effectively. Set up correctly, SOCs and CSIRTs will facilitate the organization to respond to all security alerts and react faster to the ever-evolving cyber security incidents.
Discussions about security breaches often focus on the planning elements, but simply talking about planning is not enough. Comprehensive plans need to be drawn up, fully executed and regularly reviewed in order to be successful. This is the only way to potentially contain the breach and limit the impact it could have on the organization. Properly planning and implementing is the difference between success and failure for companies when it comes to security and incident response.
As the ever-evolving cyber security landscape poses new challenges, companies are pushed even more to fight back the growing number and even more sophisticated levels of cyber attacks. Organizations across all sectors and industries are potential targets and could become victims at any time. With attacks escalating in all areas, whether via phishing or malware, for example, security operations teams need to be prepared to respond to existing and new types and strains of threats, in order to fully defend and protect their company assets and networks.
Along with prevention becoming increasingly difficult for security teams, some organizations also tend to have a weakness when it comes to incident response. Below outlines some of the main reasons why this failure is happening today and if this a true representation of your organization, it is important for action to be taken in order to improve it.
With the number of sophisticated cyber threats in the past several years growing at a phenomenal rate, the security industry has been facing an explosion of security tools available in the market. Many of these though have adversely resulted in creating more tasks for security teams and analysts in terms of monitoring, correlating, and responding to alerts. Analysts are pushed to work on multiple platforms and generate data from every single source manually, while afterwards then needing to enrich and correlate that data which can take many hours or even days.
Security budgets are often limited, and while it is often easier to gain support and approval for additional security apps and tools than it is for additional staff members, this means that many security teams often are forced to search innovative ways to perform many different tasks with extremely limited personnel resources.
Another important point to note is that with increased market competition for experienced and skilled analysts, companies are often forced to choose between hiring one highly skilled staff member versus a couple of less experienced, junior level ones.
Over the years, organizations have witnessed an increasing number of security tools to fight back the growing number of security threats. But even though these tools manage alerts and correlate through security information and management system, security teams are still overwhelmed by the volume of alerts being generated and in many instances are not physically able to respond to them all.
Every single alert must be verified manually and triaged by an analyst. Then, if the alert is determined to be valid, additional manual research and enrichment must take place before any other action to address the threat. While all of these processes take place, other potential alerts wait unresolved in a queue, while new alerts keep being added. The problem is, any one of these alerts may be an opportunity window for an attacker while they wait to be addressed.
Risk of Losing Skilled Analysts
Security processes are performed manually and are quite complex in nature, therefore training new staff members takes time. Organizations still rely on the most experienced analysts when it comes to decision making, based on their knowledge and work experience in the company, even with documented procedures in place. This is commonly referred to as tribal knowledge, and the more manual the processes are, the longer the knowledge transfer takes. Moreover, highly qualified analysts are considered a real treasure for the company, and every time a company loses such staff member, part of the tribal knowledge is also lost, and the entire incident response process suffers a tremendous loss. Even though companies make efforts to keep at least one skilled analyst who is able to teach other staff members the skills they have, they aren’t always successful in that.
Failure to Manage Phases
Security teams work with metrics that could be highly subjective and abstract, compared to other departments which often work with proven processes for measuring the effectiveness or ineffectiveness of a program. This is largely due to the fact that conservative approaches and methods for measuring ROI aren’t applicable, nor appropriate when it comes to security projects, and might give misleading results. Proper measurement techniques are of utmost importance when it comes to measuring the effectiveness and efficiency of a security program, therefore it is necessary to come up with a measurement process customized according to the needs of the company.
Another important issue that should be mentioned here is the one concerning the management of different steps of the incident response process. Security incidents are very dynamic processes that involve different phases, and the inability to manage these steps could result in great losses and damages to the company. For the best results, companies should focus on implementing documented and repeatable processes that have been tested and well understood.
In order to resolve these issues, organizations should consider the following best practices.
The coordination of security data sources and security tools in a single seamless process is referred to as orchestration. Technology integrations are most often used to support the orchestration process. APIs, software development kits, or direct database connections are just a few of the numerous methods that can be used to integrate technologies such as endpoint detection and response, threat intelligence, network detection, and infrastructure, IT service and account management.
Orchestration and automation might be related, but their end goals are completely different. Orchestration aims to improve efficiency by increased coordination and decreased context switch among tools for a faster and better-informed decision-making, while automation aims to reduce the time these processes take and make them repeatable by applying machine learning to respective tasks. Ideally, automation increases the efficiency of orchestrated processes.
Strategic and Tactical Measurement
Information in favor of tactical decisions usually consists of incident data for analysts and managers, which might consist of indicators of compromise assets, process status, and threat intelligence. This information improves decision-making from incident triage and investigation, through containment and eradication.
On the other hand, strategic information is aimed at executives and managers, and it’s used for high-level decision making. This information might comprise statistics and incident trends, threat intelligence and incident correlation. Advanced security programs might also use strategic information to enable proactive threat hunting.
If these challenges sound familiar within your security operations team, find out how DFLabs’ Security Orchestration, Automation and Response solution can help to address these to improve your overall incident response.
Incident and Forensics Investigations Management
Security incidents and digital forensics investigations are complex events with many facets, all of which must be managed in parallel to ensure efficiency and effectiveness. When investigations are not managed and documented properly, processes fail, critical items are overlooked, inefficiencies develop, and key indicators are missed, all leading to increased potential risk and losses.
Investigation management can be broken down into a number of key components and it is important that an organization is able to carry out all of these elements collectively and seamlessly in order to properly handle and manage any incident they may potentially face.
This blog will briefly cover 9 key areas that I believe are the most important when it comes to incident and forensics management. Ensuring these are firmly in place within your security operations or CSIRT team will ensure more efficient and effective incident management when an incident does occur.
If you would like to learn more about each of the components in more detail and how DFLabs has incorporated them into its comprehensive and complete Security Orchestration, Automation and Response (SOAR) platform to enable organizations to improve their security program, you can download our in-depth white paper here.
Every investigation must be organized into a logical container, commonly referred to as a case or incident. This is necessary for several reasons. Most obviously, this container is used to identify the investigation and contain information such as observables, tasks, evidence, notes and other information associated with the investigation, discussed in greater detail in the subsequent sections. Many investigations contain sensitive information which should only be accessible by those with a legitimate need to know. These containers also serve to enforce a level of access control.
Observables and Findings
Investigations generate a large volume of data, from simple observables such as IP addresses, domain names and hash values, to more complex observables such as malware and attacker TTPs, as well as findings such as those made from log analysis, forensic examination and malware analysis. All this information must be recorded and shared with all appropriate stakeholders to ensure the most effective response to a security incident.
Data gathered from previous incidents can be an invaluable tool in responding more effectively to future security incidents. As individual data points are associated with each other, this information is transformed from simple data into actionable threat intelligence which can inform future decisions and responses.
Phase, Expectation and Task Management
Investigations generally progress through a series of phases, each of which will contain a series of management expectations and a set of tasks required to meet those expectations. As the complexity of an investigation increases the tracking of these phases, expectations and tasks become both more critical and more difficult to manage. Failing to properly track and manage investigation phases, expectations and tasks can lead to duplicated efforts, overlooked items and other inefficiencies which lead to an increase in both cost and time to successfully complete an investigation.
Evidence and Chain of Custody
Documenting evidence and tracking chain of custody can be a complex process during an investigation of any size. Documentation using older paper-based or spreadsheet systems does not scale to larger investigations, is prone to error and is time-consuming. Failing to maintain a full list of evidence or maintain chain of custody can result in lost evidence, duplication of efforts and inability to use critical evidence during legal processes.
Forensic Tool Integration
Security operations use a multitude of tools and technologies on a daily basis with different ones being utilized for varying types of investigations. Logging into several platforms individually to collect data is often a manual process and can be tiresome and painful, as well as extremely time-consuming, and time is always of the essence. It is critical that security tools are connected and integrated to improve efficiencies and to fuse intelligence seamlessly together so that all data can be analyzed and documented in a single location and immediately shared with relevant stakeholders.
Reporting and Management
Reporting and the management of reports is a vital function during any investigation. Once information is documented, it must be able to be accessed easily and in multiple formats appropriate for a wide variety of audiences. As the scale of an investigation grows, so does the number of individual reports which will be generated. This can result in many complexities, including sharing logistics, proper access controls and managing different versions of reports. To reduce the impact of these complexities, a single report management platform should be used to act as the authoritative source for all reports.
Activity Tracking and Auditing
Tracking actions taken during an investigation is important to ensure a consistent response, identify areas where process improvements are needed, and to prove that the actions taken were appropriate. Not only must actions be documented, but it is also crucial to ensure that the integrity of this documentation cannot be called into question later. However, documenting activity during an investigation can be time-consuming, taking analysts attention away from the tasks at hand, and is often an afterthought.
Investigative data can be extremely sensitive, and it is crucial that the confidentiality of such data be maintained at all times. Confidentiality must be maintained not only for those outside of the organization but also for those internal users who may not be authorized to access some or all of the incident information.
No matter the specific roles a team is tasked with, the team will require many different physical and logical internal assets to accomplish their tasks. This may include workstations, storage media, license dongles, software and other hardware. Regardless of the asset, an organization must be able to track that asset throughout its life, ensuring that they (and the money spent on them) do not go to waste. As the team grows, managing the tracking of these assets, who they are issued, their expiration dates and more can become a full-time task.
These core components combined enable security teams to work more efficiently throughout the entire investigative lifecycle, reducing both cost and risk posed by the wide variety of events facing organizations today. Providing a holistic view of the security landscape and the organization’s broad infrastructure allows for better use of existing tools and technologies to minimize the time team members must spend on the administrative portions of investigations, allowing them to focus on the more important tasks that will ultimately impact the outcome of the response.
Learn more about the topic by downloading our latest Whitepaper titled “DFLabs IncMan SOAR: For Incident and Forensics Management“.
Security incidents are complex and dynamic events, requiring the coordinated participation from multiple teams across the organization. For these teams to work with maximum efficiency, as a single body, it is critical that information flows seamlessly between all teams in real-time. Faced with a continued onslaught of security incidents, organizations must find ways to maximize the utilization of their limited resources to remain ahead of the attackers and ensure the integrity of the organization’s critical resources.
This blog will briefly discuss how your security operations team can manage security incidents in a whole new and efficient way by integrating DFLabs IncMan Security Orchestration, Automation and Response (SOAR) platform with your existing Jira solution, including a simple use case.
It is critical to bridge the gap between security teams orchestrating incidents with SOAR solutions such as IncMan and teams tracking other tasks with Jira, to ensure that all teams maintain a holistic view of the incident and function together as a single, unified body.
Today there are many challenges faced by security teams within their specific security programs. By integrating DFLabs IncMan SOAR with Jira you will be able to overcome the following key problems:
- How can I ensure that all teams have the most up-to-date incident information?
- How can I integrate the power of IncMan into my existing issues management process?
- How can I enable all teams to work as a single unified body to increase the efficiency of the incident response process?
- How can I quickly communicate critical information to those outside the security team?
Let’s discuss how in more detail.
How to Streamline Incident Management and Issue Tracking With The DFLabs SOAR and Jira Solution
Security operations teams struggle to gain visibility of threats and rapidly respond to cyber incidents due to the sheer number of different security technologies they must maintain and manage and the resulting flood of alerts. Aggregating these into a single pane of glass to prioritize what is critical and needs immediate attention requires a platform that can consolidate disparate technologies and alerts, and provides a cohesive and comprehensive capability set to orchestrate incident response efforts.
Jira’s industry-leading issue tracking solution has been battle-tested and becomes the core of an organization’s support, IT, incident response and project management processes worldwide. Jira allows teams from across the organization to collaborate and share information to plan, track and report projects and issues in real-time, maximizing efficiency and reducing impacts on the organization’s critical business processes.
By integrating with Jira, DFLabs IncMan extends these capabilities to Jira users, combining the orchestration, automation and response power of IncMan with the organization’s existing issue tracking process. IncMan’s R3 Rapid Response Runbooks can be used to automatically create issues within Jira and continue to update the issue as the incident progresses.
Allowing organizations to seamlessly share information between IncMan and Jira ensures that all involved in the incident response process are working with a unified set of information, enabling organizations to maximize security analyst efficiency, reduce incident resolution time, as well as reduce the number of incidents handled.
An alert of a host communicating with a potentially malicious domain has automatically generated an Incident within IncMan.This alert is automatically categorized within IncMan based on the organizations’ policies, which initiates the organization’s Domain reputation runbook, shown below:
Through this runbook, IncMan automatically gathers domain reputation information for the domain which generated the alert. If the resulting domain reputation information indicates that the domain may be malicious, IncMan will use a Notification action to automatically create a new Issue within Jira, allowing Jira users to immediately begin next steps. Next, using additional Enrichment actions, IncMan will automatically gather additional information regarding the suspicious domain, such as WHOIS and geolocation information. IncMan will then automatically update the Jira issue with this information. Finally, a screenshot of the page (if applicable), is taken and added to IncMan.
The automated workflow of IncMan’s R3 Runbooks means that an IncMan incident and Jira issue will have been automatically generated, and these enrichment actions through the Quick Integration Connector with Jira and other enrichment sources will have already been committed before an analyst is even aware that an incident has occurred. Both IncMan and Jira users are now able to perform their respective tasks, knowing that they are each working with the same information, and can continue to do so as the incident progresses.
By harnessing the power of Jira’s industry-leading issue tracking solution, along with the orchestration, automation and response capabilities of DFLab’s IncMan SOAR platform, organizations can elevate their incident response process, leading to faster and more effective incident response and reduced risk across the entire organization.
If you would like to see IncMan and Jira in action together in more detail, get in touch to request a live demo of IncMan with one of the team.
Whether you call it Incident Management or Incident Handling, most will agree that there is a distinct difference between responding to an incident and managing an incident. Put simply, Incident Response can be defined as the “doing”, while Incident Management can be defined as the “orchestrating”. Proper Incident Management is the foundation and structure upon which a successful Incident Response program must be based. There are numerous blogs, articles and papers addressing various aspects of the differences between Incident Response and Incident Management dating back to at least a decade. Why add another to the top of the pile? Because while most organizations now see the value in putting people, tools, and basic processes in place to respond to the inevitable incident, many still do not take the time to develop a solid Incident Management process to orchestrate the response effort.
Security incidents create a unique environment, highly dynamic and often stressful, and outside the comfort zone of many of those who may be involved in the response process. This is especially true during complex incidents where ancillary team members, such as those from Human Resources, Legal, Compliance or Executive Management, may become involved. These ancillary team members are often accustomed to working in a more structured environment and have had very little previous exposure to the Incident Response process, making Incident Management an even more critical function. Although often overlooked, the lack of effective Incident Management will invariably result in a less efficient and effective process, leading to increased financial and reputational damage from an incident.
Many day-to-day management processes do not adapt well to these complex challenges. For example, as the size and complexity of a security incident increases, the number of people that a single manager can directly supervise effectively decreases. It is also not uncommon for some employees to report to more than one supervisor. During a security incident, this can lead to mixed directives and confusion. During a security incident, it is critical that information flows quickly and smoothly both vertically and horizontally. Many organization’s existing communication methods do not adapt well to this.
When an ad-hoc Incident Management system is used, the response process becomes much less consistent and effective. A common pitfall of this ad-hoc management style is that it can create a flat management structure, forcing the Incident Response Coordinator to directly oversee the functions of many groups with vastly different objectives. A flat structure such as this also tends to inhibit the flow of information between the individual groups.
Another common pitfall of this ad-hoc management style is that it often results in a fragmented and disorganized process. Without proper management to provide clear objectives and expectations, it is easy for individual groups to create their own objectives based on what they believe to be the priority. This seriously limits the effective communication between individual groups, forcing each to work with incomplete or incorrect information.
There are numerous ways in which the Incident Management process can be streamlined. On Wednesday, January 31st, DFLabs will be releasing a new whitepaper titled “Increasing the Effectiveness of Incident Management”, discussing the lessons that can be learned from decades of trial and error in another profession, the fire service, to improve the effectiveness of the Incident Management process. John Moran, Sr. Product Manager at DFLabs, will also be joining Paul and the Enterprise Security Weekly Team on their podcast at 1 PM EST on January 31st to discuss some of these lessons in more detail. Stay tuned to the DFLabs website, or listen in on the podcast on January 31st for more details!