A key part of making any threat management program successful is ensuring it maps properly to the client’s needs. In the past, this has been challenging for many groups providing threat management to their internal teams. The challenge has largely been in making sure the proposed program and the suite of solutions find and call out the most pressing threats that a client faces.

Threats could be different depending on the type of business, location or technology footprint. What’s more, clients prefer not to deploy threat management programs all at once. They like to move more carefully and prove that the threat management program works as they go along.

One approach to successful threat management program deployment is using real-world attack scenarios executed by platforms, such as SafeBreach, to verify that threats intended to analyze and track are actually the threats that matter the most to clients. All-or-nothing threat management rollouts are less likely to succeed and can cause disruption. Take a look at how to carefully roll out strategic threat management.

Step 1: Start threat management by collecting telemetry

To correctly map threat management program efforts to actual system signals, collect system telemetry to create a baseline of what should be monitored and reviewed. This data usually comes from server logs, endpoint detection, databases, user and entity behavior analytics (UEBA), email, network traffic logs and other systems of record monitoring activity.

This will also help you understand what sort of threats have attempted to enter the perimeter. It may also show you a few attacks and indicators of compromise (IoCs) that have actually breached the perimeter and even traversed internally.

The data will allow you to see normal traffic moving throughout the system, too. Having this picture of normal traffic gives you a baseline knowledge of movements and patterns.

Step 2: Audit collected logs

Once you have assembled the logs, you should run them through a SIEM platform, such as the QRadar SIEM platform or others. Using the platform, you can consolidate the log events and network flow data from all the devices, endpoints and applications connected to a client’s network and infrastructure. From this, you can determine what sort of attackers or intruders will be of greatest interest.

In this step, you can customize the threat management hierarchy to match the client. For example, for a financial services client located in Europe running Windows in a public cloud, you would focus on attacks directed against Windows systems and attack groups known to target financial services companies.

Step 3: Configure threat management rules to detect IoCs

Based on those findings, the threat management team can now configure rules to detect attacks, breaches and potential IOCs. The rules can be customized to prioritize the IoCs that pose the greatest risk and require immediate attention. Some rules might overlap, as IoCs can vary even for the same type of attack or an attack by the same type of malicious software or exploit.

Rules might also include known signs that likely result from spear-phishing or human errors. These are important to watch because they might allow trojans, malware and viruses to breach and scan or traverse internal networks.

Step 4: Generate useful data

From IoCs detected on client systems, you should start to generate useful intelligence on threats. This would take the form of reports and alerts with qualitative and quantitative ratings and rankings. These make it easier for threat intelligence analysts to understand. Then, they can make fast and accurate judgments on repairs and changes. With this step, the team moves from awareness to detection to active repairs.

Step 5: Simulate attacks against the client

A key element for building trust is showing a client actual results. Let the team run test attacks to demonstrate the tools and services are working as promised. The mock attacks also play a crucial role in spotting holes in the process. This could be log file types that the team had not added but are needed in order to detect IOCs. Attackers and exploits frequently obfuscate their actions and hide their trails. In addition, many attack types and techniques exploit paths that are not captured in default logging settings of major security control systems for Windows or Linux. By running an attack exercise against a smaller sample that applies to the client, you can determine whether you need to modify any of the previous steps.

On the other hand, it may become evident that you need to go back and ask more detailed questions about what the client really wants to protect. Both groups need to be clear about what systems and networks can expose the most precious business assets. The client may not have expressed their needs well in initial talks and due diligence, even with the first mock attacks. But, running real attack tests tends to clarify what a client really wants to measure, detect and identify. Once you are satisfied and can confirm that you have covered all the key points, then you are ready to move forward with a broader deployment.

Step 6: Repeat until threat management is thorough

Clients’ systems change. The threat actors they face also change. A major disruptor like COVID-19 can change the entire attack surface of a business overnight. You may tackle each threat management case in a bespoke fashion, but no security program can be static and still be effective. In this regard, running real attacks plays an important role. It allows for constant testing of the threat management tools and programs. This, in turn, helps to verify and validate that clients’ security teams are making the right fixes.

The prep work that goes into making sure a client environment is the right one is only the beginning. And, it is a needed beginning to maximize chances of success.