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”.
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”.
We have all heard about Key Performance Indicators (KPIs) and how critical they can be for your security program, but confusion remains surrounding what KPIs are important to track and how they can be used to measure and improve the organization’s security program. Tracking KPIs is great, but if those KPIs are not relevant and actionable; if you are tracking KPI’s just for the sake of tracking KPIs and they are not being used to inform your security program, your KPIs will become more of a detriment than an enabler for your security program.
At its core, a KPI is a way of measuring the success or failure of a business goal, function or objective, and a means of providing actionable information on which decisions can be based. Quality KPIs serve as a security program enabler and driver for continuous improvement. This is true of both the tactical functions of security operations – looking for attack patterns and trends of malicious activity, as well as the strategic functions of security operations – identifying program gaps and making long-term program decisions.
KPIs should focus on assessing a goal or function and providing actionable information on which decisions can be made. The most effective way to develop meaningful KPIs is to start by identifying which security operations goals or functions are the most critical to the security operations program, then developing KPIs to measure those critical goals or functions. KPIs which will not inform the decision-making process in some way are unnecessary and should be avoided, they will serve only to muddy the waters.
When choosing KPIs to measure, quality should be valued above quantity. Each KPI should have a meaning to the organization and add value to the security program. There are many different methods for evaluating the effectiveness of a KPI; here we will use the acronym SMART. Each KPI should be:
- Simple– KPIs should not be overly complicated to measure. It should be clear what the purpose of each KPI is and how it impacts the security program.
- Measurable– A KPI must be able to be measured in some way, quantitatively or qualitatively. The method by which each KPI is measured should be clearly defined and consistent.
- Actionable– KPIs should be used as a driver for decisions. The purpose of a KPI is to measure performance, and if necessary, take some action based on the results. A KPI which is not actionable serves little to no purpose.
- Relevant– Each KPI should be a measurement of the function being assessed; in this case, the security program. KPIs which are simple, measurable and actionable, but are not relevant to the function being assessed will be of little value.
- Time-Based– KPIs can and should be used to show changes over time. An effective KPI should be able to be collected and grouped by various time intervals to show variations and patterns.
There will never be a set of “correct” KPIs to measure; the goals and objectives for each organization will always be different, and the organization’s KPIs should reflect the individual priorities. The key to choosing KPIs which will have a real, actionable impact on the organization’s security program is to ensure that the KPIs are SMART, focus on the six most common components of a successful security operations program, and are used to further the security program.
For more detailed information on how your organization can use KPIs to enhance your security program, check out our whitepaper “ Key Performance Indicators (KPI’s) for Security Operations and Incident Response” here