Cybersecurity in 2017: Automation, Adversaries and Orchestration
Threat intelligence sharing among vendor and industry peers has come a long way, and in 2017 there will be more opportunities than ever to demonstrate its value; especially as conversations around sharing intelligence between the public and private sectors continues.
Crossing the Last Mile With Threat Intelligence
Security vendors and white hat researchers continuously seek new indicators of vulnerability. Once found, they convert them into prevention and detection controls and deploy them as quickly as possible. This is called actionable intelligence. The problem for the past decade is that most network defenders take days, weeks or even months to finish the last mile—if they do it at all.
What is needed is an automatic way to make the journey. Instead of analysts reading intelligence reports, deciding that the intelligence is pertinent to their environment, crafting prevention and detection controls for their deployed systems, and then deploying those controls, network defenders will, in the future, rely on automated systems which do that for them. They will have to trust that the automation will not take the network down.
Adopting the Adversary Playbook Model
For the past decade, sharing indicators of compromise has become a best practice for the network defender community. The problem with that approach is that, many times, the indicator of compromise has no context. It is typically a collection of known bad IPs, URLs and file hashes that network defenders need to block. Unfortunately, most times, network defenders associate those IPs, URLs and file hashes to a specific point in the adversary attack life cycle. If they configure a block for that indicator of compromise, they leave room for the adversary to find a way around the block by using some other method. A better way is for the network defender community to share indicators of compromise associated with specific adversary playbooks.
A playbook is the collection of all the indicators of compromise associated with a specific attack campaign – or attacker. In this model, network defenders are not blocking at one point in the attack life cycle; they are deploying blocks at every stage of the attack life cycle associated with the attacker. If attackers run into a block and find a way around it, they will immediately run into the next block, and the next block, and the next block. This playbook method does not give the attacker the option of finding a way around a block. The playbook model allows network defenders to block not simply one point in the attackers’ campaign but all points that the attackers must negotiate in order to be successful. If the attackers want to be successful, they must design an entirely new attack campaign.
For the past 25 years, network defenders have been deploying numerous products from various security vendors to stop attackers from penetrating their environments. The network defender community laughingly call this “vendor in depth.” Over time, the number of point products that network defenders have to maintain has exponentially grown. That number can be between 15 and 150 point products, depending on how well-resourced your organization is. In my experience, you pay for a point product three times:
1. You pay for the box
2. You pay for the person who can maintain the box
3. You pay for the person who can understand the data coming off the box
Multiplying the number of product points by three creates very expensive and complex security demands. Network defenders have been calling for the security vendors to orchestrate their point product deployment for them.
There are two approaches to doing this. The first is to use a single platform to orchestrate most of the services you would normally get with a collection of point products. In other words, put all the services into one unified platform. This approach is tricky because it goes against everything the network defender has learned over the past 20 years: it demands the network defender trust one vendor or a small collection of vendors and abandon the vendor-in-depth philosophy.
The second approach is to use a third party vendor to manage the point product collection. But this will be difficult to pull off. Keeping up with the changes of over 150 security vendors is a herculean task.
So, ultimately, orchestration is needed. The network defender community will choose one of these solutions or something else that emerges that has not been thought of yet. Orchestration is coming, it just may not happen as early as 2017.