If you want to remain connected—and protected—the cloud is the only way. Why? There’s a ubiquity and cohesiveness to the cloud. It connects geographies. It connects devices. It’s where information sharing happens, and can happen at scale. In fact, the cloud is the only place that can provide the scale and elasticity (without the capital expense) that’s required in a connected world where new devices are appearing by the dozens daily.
Ultimately, information sharing will enable the best protection because, like it or not, all of these devices, no matter their form or consumption model, will get hacked. And when that happens, the cloud is the best place to dissect attacks and relay resulting solutions. In short, it’s what security intelligence is all about.
When it comes to being connected, there are three things to consider:
1. Expect your devices will be compromised. Hacking is inevitable. From a cloud perspective, it’s about taking the time to learn and understand the characteristics of normal—across a large number of devices—in order to be able to detect abnormal. And what makes the cloud so attractive is that it’s a hub of security intelligence gathering and offers the quickest route to identifying deviations, especially at scale.
2. Once a device has been compromised, then what? Technologies that can identify device characteristics or “fingerprints” can also, after a compromise, define the altered behavior. For example, if you know what a smart meter normally looks like, you’ll be able to see patterns of deviation emerge. From a security remediation perspective, there are now certain brute-force actions you could take (e.g., taking the device offline), but, eventually, it will be the cloud that offers more automation and options for self-healing of connected devices post infection.
3. Sharing is caring. The fabric of security intelligence comprises learning from what’s happened in one corner of the universe and sharing that data—which includes what form of remediation worked—across multiple enterprises, service providers, partner organizations, customers, etc.
When we think cloud, we don’t think racks of servers. We think virtualization. That’s because a super scalable virtualized environment is the only mechanism that can keep pace with this Internet of Things world. But what this environment needs is not only super scalable security that maps to connected devices, but it also needs processes that can protect the virtualized infrastructure itself against outside-in threats.
For attackers, compromising individual connected devices is interesting. However, what’s going to be more challenging for them is getting to the cloud master who’s controlling the “puppet” devices. Sure, content providers will continue to get attacked, but it’s the cloud-ready data centers—which represent the fabric for all these devices—that are becoming the more lucrative targets. Hackers will go where the money is; consequently, we need to be cognizant and prepared to protect these targets by forming vertically integrated platforms (from next-gen firewalls to Web deception) that can withstand volumetric Distributed Denial of Service (DDoS) attacks, protect against malware, and prevent data leakage.
Then, taking that vertical integration a step further, what we ultimately need is something that can adapt and respond to a variety of schemes (volumetric and targeted application-level DDoS, phishing, SQL injection attacks). Solutions today have been very static in nature. Kind of like, “Let’s lock and load on a layer 4 firewall. Let’s turn on IPS with these sorts of signatures. Let’s turn on Web app firewalling.” Then we hope and pray and walk away.
The better solution is to bind these services into a chain. Start off by learning the nature of the attack (just like we were learning the definition of the devices for baseline and deviation) and then change and adapt the security posture based on what’s been learned.
For example, let’s say you only turn on application identification. Then you start seeing a bunch of SQL queries. Maybe you look at the IP reputation and see that the IP source address is based out of some unusual location. At that point, you may have an alarm kick about queries coming from a geography that’s notorious for these types of attacks. From there, if you think this may be the genesis of a SQL attack, you could turn on the next level—perhaps a Web app firewall with the SQL engine enabled.
In the old world, you might have ignored this or awakened someone in the middle of the night to check on it. Service chaining offers the flexibility to call unique functions into real-time execution and remove them once their value ceases to exist.
For example, by calling in the Web app firewall with the SQL injection engine, you’re asking to inspect this traffic a little more, see if it’s a real attack, and figure out if you need to do something about it or, to the contrary, determine if it’s a false alarm that can have you go back to your normal execution path. Making the appropriate adjustments to a service chain can give you a higher degree of accuracy and alert you when a true attack has been detected, as well as let you share the information with other organizations or cloud service providers.
It’s time to take advantage of the cloud and the value it brings through security intelligence, virtualization security, and service chaining to detect, stop, and prevent breaches.