Building an Early Warning System: Deploying the EWS
Now that we have covered the concepts behind the Early Warning System, it’s time to put them into practice. We start by integrating a number of disparate technology and information sources as the basis of the system – building the technology platform. We need the EWS to aggregate third-party intelligence feeds and scan for those indicators within your environment to highlight attack conditions. When we consider important capabilities of the EWS, a few major capabilities become apparent: Open: The job of the EWS is to aggregate information, which means it needs to be easy to get information in. Intelligence feeds are typically just data (often XML), which makes integration relatively simple. But also consider how to extract information from other security sources such as SIEM, vulnerability management, identity, endpoint protection, network security, and get it all into the system. Remember that the point is not to build yet another aggregation point – it is to take whatever is important from each of those other sources and leverage it to determine Early Warning Urgency. Scalable: You will use a lot of data for broad Early Warning analysis, so scalability is an important consideration. But computational scalability is likely to be more important – you will be searching and mining the aggregated data intensively, so you need robust indexing. Search: Early warning doesn’t lend itself to absolute answers. Using threat intelligence you evaluate the urgency of an issue and look for the indicators in your environment. So the technology needs to make it easy for you to search all your data sources, and then identify at-risk assets based on the indicators you found. Urgency Scoring: Early Warning is all about making bets on which attackers and attacks and assets are the most important to worry about, so you need a flexible scoring mechanism. As we mentioned earlier, we are fans of quantification and statistical analysis; but for an EWS you nee a way to weight assets, intelligence sources, and attacks – so you can calculate an urgency score. Which might be as simple as red/yellow/green urgency. Some other capabilities can be useful in the Early Warning process – including traditional security capabilities such as alerting and thresholding. Again, you don’t know quite what you are looking for initially, but once you determine that a specific attack requires active monitoring you will want to set up appropriate alerts within the system. Alternatively, you could take an attack pattern and load it into an existing SIEM or other security analytics solution. Similarly, reporting is important, as you look to evaluate your intelligence feeds and your accuracy in pinpointing urgent attacks. As with more traditional tools customization of alerts, dashboards, and reports enables you to configure the tool to your own requirements. That brings us to the question of whether you should repurpose existing technology as an Early Warning System. Let’s first take a look at the most obvious candidate: the existing SIEM/Log Management platform. Go back to the key requirements above and you see that integration is perhaps the most important criterion. The good news is that most SIEMs are built to accept data from a variety of different sources. The most significant impediment right now is the relative immaturity of threat intelligence integration. Go into the process with your eyes open, and understand that you will need to handle much of the integration yourself. The other logical candidate is the vulnerability management platform – especially in light of its evolution toward serving as a more functional asset repository, with granular detail on attack paths and configurations. But VM platforms aren’t there yet – alerting and searching tend to be weaker due to the heritage of the technology. But over time we will see both SIEM and VM systems mature as legitimate security management platforms. In the meantime your VM system will feed the EWS, so make sure you are comfortable getting data out of the VM. Big Data vs. “A Lot of Data” While we are talking about the EWS platform, we need to address the elephant in the discussion: Big Data. We see the term “Big Data” used to market everything relating to security management and analytics. Any broad security analysis requires digesting, indexing, and analyzing a lot of security data. In our vernacular, Big Data means analysis via technologies like Hadoop, MapReduce, NoSQL, etc. These technologies are great, and they show tremendous promise for helping to more effectively identify security attacks. But they may not be the best choices for an Early Warning System. Remember back to the SIEM evolution, when vendors moved to purpose-built datastores and analysis engines because relational databases ran out of steam. But the key to any large security system is what you need to do, and whether the technology can handle it, scalably. The underlying technology isn’t nearly as important as what it enables you do. We know there will be a mountain of data, from all sorts of places in all sorts of formats. So focus on openness, scalability, and customization. Turning Urgency into Action Once you get an Early Warning alert you need to figure out whether it requires action, and if so what kind to take. Validation and remediation are beyond our scope here – we have already covered them in Malware Analysis Quant, Evolving Endpoint Malware Detection, Implementing and Managing Patch and Configuration Management, and other papers which examined the different aspects of active defense and remediation. So we will just touch on the high-level concepts. Validate Urgency: The first order of business is to validate the intelligence and determine the actual risk. The early warning alert was triggered by a particular situation, such as a weaponized exploit was in the wild or vulnerable devices. Perhaps a partner network was compromised by a specific attack. In this step you validate the risk and take it from concept to reality by finding exposed devices, or perhaps evidence of attack or successful compromise. In a perfect world you would select an attack scenario and
