As I wrote about last month, there is an increasing interest by a wide range of organizations to acquire access to external threat intelligence or feeds. While this is potentially a good thing, it needs to be seen within the context of what an organization can actually do with such information once acquired.
There are a number of challenges organizations need to address to make effective use of threat intelligence data. One major challenge is simply working around existing internal separations of roles or responsibilities (i.e. the network team, the server team, and the security team are essentially completely autonomous from each other). This can prevent, or at least make difficult, taking direct action based on gathered data.
For example, threat intelligence might indicate that there is an increased likelihood of a targeted attack designed to exploit an unpatched vulnerability. However, what happens when those devices are managed by another team? They are now forced to perform an “off schedule” patch, possibly with limited testing, while interrupting other ongoing scheduled tasks. Without a sense of cooperation or teamwork, and the ability to rate risk against business impact, over time this is likely to become a “boy crying wolf” scenario.
One excellent method for bridging this divide is to begin thinking and talking about risk from a threat awareness perspective.
You might be wondering what I mean by threat awareness, and how this is different from threat intelligence. Threat awareness is the process of identifying the systems, services, and applications that are essential to the operation of your organization, assessing the current controls and protections that have been implemented for them, identifying the areas where new and/or improved controls are needed, and then developing a prioritized plan to address those gaps.
Historically, this approach was applied to the physical elements of organizations, particularly those that dealt with high-risk products, such as chemical plants, transportation, and similar critical infrastructure industries.
These same concepts need to be applied by all organizations to the security of their information technology systems as well, particularly as ever-increasing numbers of these systems are exposed to external users rather than the more traditional (and hopefully, more closely monitored) internal users – i.e. the security nemesis that is the Internet, or increasingly, systems that have been moved completely outside of our physical control, such as migration to cloud services. This latter trend may also change threat awareness prioritization. For example, data at rest in our own data centers may be viewed as secure. However, when it is sitting in an external, shared storage system, then encryption of this data may need to be a much higher priority.
A complementary component of threat awareness is having a plan, or at least a framework, in place to deal with a threat once you become aware of it. Each element identified in your threat awareness evaluation should have a related plan of action that is triggered when that particular element appears to be under attack.
For example, let’s consider a simple internally developed Internet application delivered via a Cloud Services (IaaS) deployment. Do you know what steps your IaaS provider is taking (if any) to prevent attacks such as DDoS, or even a simple port scan? If the application was deployed in-house, you could ask your security or network team. Who is the equivalent resource at your provider? The answer to that question will determine what additional protections you may want to build into your application stack. Then of course, the application itself should be reviewed for potential weakness. You may want to consider, for example, if your application is better protected by a WAF (Web Application Firewall) as compared to a more typical Firewall (whether a NGFW, enterprise, etc.).
A critical part of threat awareness is also having visibility into the events and exploit attempts against the systems you are tracking. This analysis traditionally falls within the realm of SIEM and SIEM-like products. The best of these accept input from a wide range of vendors using a wide variety of mechanisms, and then correlate those events together looking for sophisticated and multi-vector threats. This can significantly reduce the amount of information that needs to be consumed or hand-correlated by your SOC or NOC.
Another key consideration of an effective threat awareness implementation is looking at solutions that have the potential to take mitigation actions without administrative intervention. Next generation SIEM solutions become a key component of implementing an effective multi-vendor security fabric architecture.
Finally, information generated by SIEM tools is also critical to the continuous refinement of your threat awareness positioning. These systems can inform IT organizations of critical issues they may not have previously been aware of, allowing them to take countermeasures before a breach occurs.
Once you have an understanding of where your risks are, you can make better choices about what types – and more importantly, what sources – of threat intelligence are most applicable, and hopefully, most useful to your organization.
Here are three critical takeaways from this discussion:
• Identify your threats, and take into consideration that they may be different for different platforms
• Evaluate your capability to be informed that a threat is taking place, who gets this information, and whether they are empowered to act on that intelligence
• Develop a plan to implement compensating controls to fill identified gaps in your threat awareness strategy.
Related: Distinguishing Threat Intelligence From Threat Data
Related: What is the Difference Between Information and Intelligence?
