Building out a security operations center is a big job, but it’s worth it if it’s done right and provides enough security for your company. People, processes, and technology must all be carefully planned and coordinated while constructing a SOC. In the face of today’s threat landscape, a fully operational SOC will have the capability to assist secure your firm.
Each of these areas will be covered in-depth in this three-part series, beginning with the key threat detection and response functions:
- intelligence on threats
- Threat analysis
- Engineering detection
- Look into it
- Handling of incidents
Despite the fact that these functions are distinct, they must be tightly integrated. These tasks frequently rely on one another to some degree, with one function informing the actions made by the next. Organizations frequently combine these functions or have them handled by partners to create closer alignment or to meet budgetary restrictions.
Intelligence on threats
We’ll begin with threat intelligence, which is a critical component of well-run security operations. The threat model, which is used to identify relevant threats, is the starting point for a threat intelligence function. Once these risks have been detected, the intelligence team works to identify and classify them so that they can be prioritized.
Threat intelligence is ultimately a decision-making tool. The intelligence team may produce a range of outputs based on a threat model as its primary input, which can be used to guide decisions ranging from strategic to tactical:
Investing in security technology or knowledge, either internally or outside
Data sources for gaining insights into and eventually detecting threats
Preventative and detective controls are employed to avoid threats if possible, and to enable investigation and incident response when necessary.
Prioritization of certain tasks for other teams, such as assisting the detection engineering team in prioritizing their analytics backlog.
Analysts and incident responders can use context to draw faster, more informed investigative conclusions.
This function can be assigned to a single individual, done by a team, or shared amongst various functions, depending on the organization. The only obstacles to entry are being clear about the goal of your intelligence function and being able to operationalize the intelligence you produce or receive.
Threat analysis
If the intelligence team’s goal is to inform decision-making, threat research should include the following activities:
- Ascertain that the intelligence priorities identified are adequately contextualized.
- Identify emerging dangers that are unknown or poorly understood so that they can be prioritized.
- Determine coverage gaps and assumptions, as well as practical suggestions for boosting detection coverage.
Provide a level of detail in terms of attack strategies, threats, malware, and other forms of analysis that can’t be time-optimized in the same way that detection engineering or incident handling can.
The abilities you’ll need for this team will vary depending on the technology you’re in charge of learning. Exposure to detection engineering, operating system internals, malware analysis, and offensive security are all common characteristics. Threat research, more than anything else, necessitates time and a desire to delve into technology, opponent tradecraft, or software as needed.
Engineering detection
The threat intelligence’s functioning end can be thought of as the detection engineering function. They use the threat profiles and prioritizing of the intelligence team as input to create the software and/or analytics that the team will employ to detect those threats.
Because the detection engineering team is frequently the last stop before potential threats are surfaced for investigation, it is frequently where responsibility for ensuring that potential threats are not only reliably recognized, but also packaged properly for investigation rests. This includes ensuring that analysts have access to important information about a potential danger, such as:
What it was and where it came from
- What happened to it?
- What it could be
- What it’s likely to do next
This may appear to be a lot, and it is. Your level of maturity in all functions, from security architecture to threat intelligence, will be more evident here than anywhere else.
In practice, detection engineering does not necessitate the use of specialist tools, but it does necessitate the use of a sound method. You might find yourself using detection analytics in a commercial solution like a SIEM. You can also define, construct, and run software that is specifically designed to deal with complicated, highly contextual detections. Aside from the platform, know what you’re optimizing for. Either way:
- A broad range of risks, or a small number of high-impact threats
- Detection that is quick versus detection that is complete and precise
- See these further resources for a more in-depth look at detection engineering:
- The effectiveness of ATT&CK is determined by how well it is implemented: 5 typical blunders to avoid
- Detecting everything with limited information
- Engineering detection: Setting goals and sizing up for expansion
Look into it
Consider the investigating team to be similar to an emergency room. The first task you’ll face is triage: Which of the a hundred activities you could be doing right now is the most important? The quality of your defensive telemetry, the maturity of your detection engineering function, and the thinking of your threat intelligence team will all be on full display and immediately visible in this area of security operations. In order to priorities threats based on their severity, you’ll need to include the following information in your triage process:
Context for the analytic(s) that led to the investigative lead, so you know why you’re looking at a specific occurrence in the first place.
An indication of the threat you’re looking into, as well as its potential impact
Situational awareness is important whenever you’re confronted with an event that’s connected to a recent or ongoing issue.
You now face competing demands comparable to those faced by the detection engineering team if you’ve established a good method and rhythm for triage. You must do the following:
Investigate early stage incursions in a timely manner to detect and shut them down.
But don’t rush or be sloppy.
When you detect a proven threat, be meticulous in your documentation.
The primary goal of this function is to generate timely, accurate, and confirmed threat reports for the incident handling team to act on. There are additional goals, but the overriding goal of any information security program is to reduce risk, particularly realized risk for an operational team. With this in mind, a strong collaboration between analysts and detection engineering to balance shared and competing objectives is crucial to the mission’s success.
Handling of incidents
The incident response team is responsible for validating threats, understanding their breadth and severity, containing them, and eradicating them. The activities that take place after a threat has been triaged, examined, and confirmed are the emphasis of this model.
It’s important to distinguish incident handling from incident response, which is a much broader capability that starts with things like authority and policy, relies on the security operations team for incident detection and response and includes processes like postmortems and feedback loops into the technology team. Incident handling can be thought of as a coordinator of operational functions within a larger incident response program.
What isn’t there?
A superb security operations team, like any well-tuned operational capability, does not operate in isolation. The technology that the operations team will use must be compatible with their requirements and goals. In addition, regular training, drills, and testing of the end-to-end system are necessary so that the entire company can act decisively and confidently in the event of an emergency.
The next two articles in this series will go over security operations enablement as well as other testing and validation functions, demonstrating how everything works together and outlining all of the necessary components of a contemporary SOC.
