Often, in the world of information security and risk management, the question facing threat intelligence teams is amidst this sea of vulnerability disclosures, which ones matter the most to my organization? Which can impact us the most? And, how do I best explain threats to internal stakeholders in a way that helps minimize risk?
Reducing risk through proper patch management is not always simple. Not all common vulnerabilities and exposures (CVEs) are equally important. In July 2020, for example, the U.S. Department of Homeland Security released multiple top-priority advisories. One covered known exploits against certain application delivery systems (CVE-2020-5902) and another covered detected vulnerabilities in a domain name system (DNS) server (CVE-2020-1350). While both are top priorities, how do they apply to the network you use? Which threats are the most likely to impact your core business?
To better answer this, we must be able to identify relevant threats before beginning to address patching or manage risks. Enter threat identification: a necessary process that has become increasingly complicated.
Why Is Spotting Threats More Complex Today?
Threat identification today is far more complex than at any point in the past. On the one hand, infrastructure becomes more complex as more groups adopt digital transformation. On the other, we see the number of reported bugs increasing year after year. The recently published 2020 Cost of a Data Breach Report highlights this challenge as 41% of information technology (IT) and security professionals report a vulnerability or misconfiguration as the root cause of a malicious data breach.
These factors present a growing number of attack surfaces. To build an effective threat identification program for this complex field, take a precise and thoughtful approach. Otherwise, you risk deluging your audience with too much data, resulting in security paralysis.
Let’s look at the pillars of creating a threat identification plan that can pay off in saved time and costs down the line.
Step 1: List Your Threat Intelligence Stakeholders
To provide the highest value, multiple teams and parts of the group should view cyber threat intelligence. Each team may have a slightly different goal or benefit. For effective rapport with shareholders and the board of directors, the C-suite may require threat intelligence reports in order to understand, at a high level, the cyber risks to the group.
In addition, security operations (SecOps) teams may consume threat data to better understand what types of attacks are likely to be incoming. This allows them to tune their controls or run exercises and then validate controls and identify areas that can be improved. Vulnerability management teams use this data to choose which CVEs they should address and in what order. Depending on the type of business, this step can also prevent fraud or spot data leaks.
Step 2: Define Threat Intelligence Process and Goals
Knowing who is going to see and use your cyber threat data tells you how to examine it and structure reports for each department.
Reports for nontechnical groups can be simple stoplight charts with basic bullets. For more technical consumers, the reports might contain more information on remediation steps or more advanced analysis. Consider the following questions for each type:
- How do you differentiate intelligence based on personas?
- What are their key concerns?
- What data are useful to them?
- What are you providing them and how frequently?
- How can we empower them to take action on the data they receive?
The answers to these questions will shape the goals of your program. Clearly define these goals, including them in a workflow that covers the entire process. The threat intelligence life cycle steps are:
- Plan for your needs and create clear directions to outcomes and goals.
- Collect what you need to know to meet those outcomes and goals.
- Process the information to make it easier to analyze.
- Analyze data and produce actionable intelligence.
- Give out data in a format that is easy to read.
Step 3: Create a Threat Identification and Threat Intelligence Methodology
Start by defining your intelligence needs. These needs are the foundation of intelligence management. Specifically, ask yourself, “What is important to my group?” and translate the answers into specific needs.
Those requirements should vary depending on the group. A bank or insurance company may have one set of concerns that might not impact a utility or health care team. Keep in mind that attackers are moving from one sector to another more often as they realize a specific sector is more likely to give in to their demands. For example, ransomware attacks initially targeted many small businesses and state and local governments. Attackers quickly identified organizations that had more urgency to restore operations and could potentially pay more in ransom, such as healthcare, industrial organizations and law firms, for example.
From there, you can move toward defining technical needs for threat intelligence collection. This can entail log file parameters, incoming feeds from threat intelligence services and platforms and results of continuous breach-and-attack-simulation services.
Carnegie Mellon University has published an excellent series of guides on how to think about cyber intelligence and threat intelligence. These guides provide both frameworks and materials on how to develop a methodology.
Step 4: Define Areas of Collection
Once your methodology is laid out at the high level, you can add details to your framework to narrow down the threat intelligence information that your team should process, analyze and receive reports on. Three key facets are sector; what the attacker wants; and likely tactics, techniques and procedures (TTPs).
Sector
Many organizations nowadays span multiple sectors. Therefore, they have to reckon with greater risks. For example, large banks are also online service providers with their retail services. Telecommunication providers not only run communications and data networks but also process customer payments, sell products online and store sensitive customer information, including online activity and location. As a result, attackers often move rapidly from one sector to another to fulfill their goals via softer targets — think about ransomware attackers targeting healthcare institutions, which cannot endure even brief outages and face much greater penalties for loss of data than municipal governments.
Motivation
What the attacker wants can differ depending on the threat actor. Nation-state actors may seek to exfiltrate sensitive data. Fraudsters may seek to take over accounts to access money or loyalty points for resale. Ransomware gangs are looking for large, quick payouts in cryptocurrencies. Distributed denial-of-service attacks may be carried out to extort victims, take down rival sites, apply pressure in protest or exact revenge. Motivations are often blurred. State actor APTs may both seek to steal sensitive data and perpetrate financial crimes.
These wants can also be layered. A ransomware gang may first seek to gain access via malware or phishing attacks and then move inside the victim’s systems to implant ransomware in key points. Understanding the motivations of likely attackers helps define the top potential attack modalities and TTPs to prepare for.
Targets
After defining sector and motivation parameters, threat identification programs can more tightly focus on preferred target systems and common attack playbooks and TTPs of the most likely threat actors. Threat intelligence teams should know all of the attack surfaces of their employers and focus efforts down to systems they have.
For example, if your employer has Citrix Netscaler application delivery controllers (ADCs) but not F5 ADCs, then the main concern is threats to Citrix gear. Threats to F5 equipment may be considered as part of broader situational intelligence but left out of actionable suggestions.
Also, threat identification tactics should consider how likely systems are to be exposed and exploited. If a business uses Microsoft DNS services for internal routing amidst Microsoft systems but does not expose Microsoft DNS to the public internet, then risks to Microsoft DNS may receive a lower priority than threats to the publicly exposed attack surface.
Threat intelligence teams should also emphasize new attack types that are less likely to be patched or mitigated with additional security control settings or compensating controls around applicable systems. We must give specific emphasis to attack types that grant privileged access and can bypass perimeter defenses. The surge in virtual private network openings and exploits witnessed in the past six months fits this type.
With these considerations and goals in mind, a threat intelligence team can set up a risk rating formula to create a numerical, defensible and repeatable methodology for threat identification. This risk rating should guide vulnerability management on patching and remediation prioritization and SecOps teams for specific areas of focus in their day-to-day monitoring and security work. The Binary Risk methodology framework can be good as a baseline to enable structured quick risk discussions.
Step 5: Talk to Other Stakeholders
Once in place, the threat identification program should be summarized and given out in a convenient and readable format for stakeholders that need details.
“Stoplight” charts or other simple color-based charts with a single line of description are simple and easy to read. Beyond this basic treatment, threat identification reports also need to provide detailed guidance to more technical stakeholders based on exploits and business risk:
- Vulnerability management teams should receive a risk-weighted list of which patches to use.
- SecOps teams should receive a list of attack types to watch out for. Also provide them a description of how those types might manifest in log files or other telemetry and scans.
- Threat identification reports can also guide breach-and-attack-simulation deployment and suggest which playbooks should be loaded for simulations and which security controls should be validated against newer or emergent attacks.
- Each version of the report should have next steps customized to the reader and their role. At best, this modular report structure will take a simple form of nested messages that allows easy zoom-in and zoom-out for any stakeholder.
Building a threat identification program is a critical foundation for proactive cybersecurity. Doing it the right way can pay dividends for years to come. The program can create clear and consistent plans, standards and communication models that improve awareness and security.
The post Building A Threat Identification Program to Better Manage Risk: The Key Pillars appeared first on Security Intelligence.
