Posts Tagged ‘appliances’

Microservices and Modern Production Environments Are the Achilles’ Heel of SecOps

Posted by

Microservices and the increasing popularity of service-based architecture have catapulted Linux from the coder’s tinker toy of yesterday to the most popular platform on the planet today. It’s no wonder that modern Linux is fast becoming the defacto operating system of production environments and powering the “software is eating the world” phenomenon. It’s simple and open for easy integration and has become extremely stable in its modern state. Perhaps most importantly, open source enables the quick and easy deployment of multiple platforms across multiple clouds to serve multiple business channels. In fact, users can go from a mobile device to the cloud without ever touching any physical infrastructure within their own environment.

Meanwhile, container technology is further accelerating this drive, as DevOps push their standard data formats to the cloud. Container technology enables instant scalability and improves collaboration between development and operations teams. This next generation platform approach enables developers to build, host, store and deploy applications or websites on a highly scalable production infrastructure for web, mobile and backend solutions. Of course, this makes securing the production environment more critical than ever.

The New Cyber Security Gotcha

But as with most good things, there’s a catch. While the simple plug-and-play nature of next-generation infrastructure and modern production environments ensures that no one is left behind in the age of microservices, security in this brave new world just might be the fly in the ointment. This modular approach to delivery and infrastructure, which spans multiple clouds across various modern production environments, brings with it borderless networks as well as a different set of risks and vulnerabilities than those associated with more traditional approaches.

Current Solutions Fail in Modern Production Environments

The overarching problem is that too many cyber practitioners are applying five-year-old security models to this newly evolving and transformative technology. There are three main reasons existing tools are inadequate in modern settings:

  • Traditional security relies on using a unique IP address as a stable and unique identifier for each asset it’s charged with protecting. But, many short-lived containers share a single IP address, so the appliance can’t identify assets.
  • Traffic between containers on the same host never touches the network, thereby removing a vital source of detection data.
  • End-to-end encryption is becoming more prevalent and soon (with TLS 1.3) today’s appliances won’t be able to intercept encrypted out-of-band traffic.

Further, in the world of Windows, the easiest way for a hacker to persist is by leaving behind malicious executables, which is where most Windows security focuses. In the Linux world, executables are far less portable with vastly less predictable runtime environments. Such executables generally get compiled on each system on which they run. In Linux, there are so many small useful and universal tools that a hacker doesn’t need to leave much behind – often just shell scripts. So, the old approach of detecting bad executables no longer suffices.

Million-dollar Questions

The current technological shift toward modern production environments and cloud-based infrastructure brings unprecedented opportunity, but also raises new questions that every organization must answer about their current and future security practices. For example, where does an appliance fit in? Do we really want a heavyweight virtual appliance that might cause new bottlenecks? How much more would it cost to split off traffic for an out-of-band appliance in the cloud? And if appliances provide less visibility, does that mean more clean-up costs?

A New Approach Is Critical

Capsule8 is developing the first threat prevention and response platform that’s purpose-built for cloud-native infrastructures. Our approach is to protect an organization’s assets across networks, systems, containers, bare metal, and clouds by addressing the diverse and complex nature of modern next-gen platform architecture and mircoservices. We believe the best approach is to look beyond traditional detection methods and instead focus on activity. By detecting the effect of an intrusion, security operations teams will be freed of the burden of monitoring for signatures or intrusions themselves and instead be able to focus on detecting and shutting down attacks in the instant they happen.

This pathway will provide real-time, container-aware visibility, and prevention across clusters. By focusing on the impact, Capsule8 will also provide automated attack resilience via real-time forensics and recovery, so that any piece of code that comes under attack in a stateless workload can be instantly frozen and replaced. With an API-first approach, Capsule8 is developing a single distributed engine for all rules and analysis that is open, flexible, extensible, and extremely simple to integrate.

Empowering the Digital Transformation

While these features are impressive and critical to navigating the modern Linux production environment in a safe manner, they would be of little use without automation. Capsule8 is working to enable “self-driving defense.” Just like self-driving cars manage the boring parts of driving, while you relax, Capsule8’s solution will elastically scale to your environment and team – just like containers – while eliminating alert fatigue and managing the easy parts of the drive on its own. This will enable security analysts to focus on the unknown twisty mountain roads rather than trance-inducing stretches of well-travelled highway.

Until now, such production security has been a pipedream – only available to major players like Facebook and Google, who have the resources to build their own security into their own production environments and deploy it as they see fit. Capsule8 will bring a level-playing field to bear by offering full production environment security to any organization looking to modernize.

Threat Protection Appliances Are as Valuable to Security as Your Toaster

Posted by

Nothing in the IT security community is as widely deployed and universally reviled as Anti-Virus. But, threat detection appliances, including intrusion prevention appliances, application firewalls and advanced threat protection appliances should be almost as reviled. These appliances are nearly as useless as they are toxic. They do a horrible job finding problems and ultimately create more costs for security organizations than they save by crippling organizations with false alerts.

Protection is Impractical

In terms of security, detection appliances have never been effective, since the network makes a lousy location for any kind of security hub from the outset. Few network protection devices can even prevent attacks, much less respond to them – and most appliances are simply used for detection – even those with rudimentary prevention capabilities. In theory, an Intrusion Prevention device can drop a connection before letting the bad stuff through, but, in practice, that seldom happens.

In most enterprises, security detection appliances are sitting off to the side, only capable of looking at a copy of network traffic as opposed to the actual network traffic itself. Organizations choose this less-than-ideal setup to avoid the inevitable network latency issues, which otherwise occur when a single point of failure such as an appliance gets flooded or has a bug, for example.

That’s not to say that a network appliance can’t respond to an attack in progress in any way. If an appliance determines that a particular network connection is malicious, and there is complete confidence in the appliance’s judgement, then an organization can have the device signal something that is in-line, such as a router or firewall. That device can then take action by killing the connection or blacklisting the offending IP address.

The problem with that scenario is that there often isn’t enough context at the network layer. If a network appliance tries to make fast decisions, it’s going to produce an extraordinarily high number of false positives, making its judgement suspect.  Whenever there’s any doubt about an appliance’s judgement, it shouldn’t be trusted to make decisions whether to take action. Action in such circumstances could affect legitimate connections, which could have catastrophic consequences for the entire business.

Appliances: What’s Really Happening

While old-school devices (e.g., traditional Intrusion Prevention Devices) sacrificed accuracy for speed, today’s more sophisticated appliances do a better job of processing available data, so which gives vastly superior results with far fewer false positives.

The typical “next gen” security detection appliance (such as an “advanced threat detection” appliance) tries to give as good an answer as possible about whether the connection represents an attack by simulating the end destination of the traffic to predict whether anything malicious will happen. This is done by running a copy of the traffic into a specialized virtual machine, and then monitoring the simulated outcome. If something malicious is found at the destination in the virtual machine, then there’s reasonably high confidence that the connection represents an attack. The goal of this approach is to limit false positives to the point where the organization can respond to every event. Some organization may even be willing to automate that response, by killing the connection if a suspected attack is detected in time, for example.

While this class of a device tends to reduce noise, it doesn’t eliminate “false negatives,” which allow attacks to sail through without being noticed. In fact, some believe they make the false negatives problem of appliances even worse.

If an attack works against an actual end user, yet not in the virtual environment, it could easily be overlooked by an appliance. Imagine a company buys an appliance and configures it to test network traffic by sending it to a virtual machine running Windows 10, but the traffic being tested only runs its proper course if running on Windows 9. In that case, if the network traffic’s destination is a user’s desktop that is running Windows 9, the attack can easily be successful, since the appliance won’t find the problem (because it’s running Windows 10).

This class of problem was first discovered for Network Intrusion Prevention by Ptacek and Newsham in 1998. While “next gen” technologies are capable of more accurately modeling the systems they’re trying to protect, this problem will never go away when protecting from the network. Even when companies attempt to force all systems onto a single “gold” image, exceptions tend to quickly come out of the woodwork. For example, users within development and technical organizations may often find themselves in need of software that isn’t on the gold image, or they may need to run older software for testing purposes. Also, the gold image approach tends to only work for desktops.

Making things worse, the “black hat” community can get their hands on the same appliances, and reverse engineer the virtualization technology and detection techniques it uses. Then, they figure out how to detect whether they’re running on such a device. Once they’ve done that, their real-life attacks will go unnoticed on the appliance, while still reaching the intended target.

In the “advanced threat detection” appliance space, this problem is prevalent. A dirty secret in the appliance sector is that the majority of detections from these devices are discovered on machines that have already been infected, which are then beaconing out to external command-and-control infrastructure. If instead, these appliances had detected the actual inbound threat, the attack might have been prevented.

Alert Fatigue: Poor Detection Quality

Drowning in alerts is perhaps the single biggest problem IT Security organizations face.  Even after all the raw data coming from around the network goes through a best-of-breed correlation and analysis engine, there is still an overflowing sea of information. These besieged engines generate so many alerts that organizations can’t possibly and cost effectively provide proper review for every priority alert they would like to investigate.  As it turns out, the vast majority of alerts are likely to be false positives anyway. Even the best talent can often and easily miss real incidents when pouring through so much superfluous data.

Imagine the proverbial needle in the haystack, but multiply the number of haystacks so that the entire state of Kansas is covered in hay. Now you can begin imagine the scope of the problem. Sure, you might find an occasional needle or two – especially with some ingenuity. But, there’s virtually no chance that you could tractably look for them all even if you wanted to. That aside, your vigilance is likely to wane for at least a haystack or two, which is all it takes for one devastating needle to puncture your organization.

Security appliances are – particularly more traditional devices – represent the single biggest contributor to alert fatigue by far.  When you’re limiting your investigation to network traffic and trying to get work done as quickly as possible, you don’t have enough context to make good decisions. So, if you want to err on the side of caution, keep in mind that appliances will give you plenty of reason for caution, while uncovering few actual problems.

If we are serious about eliminating the problem over alert-fatigue, we must move beyond appliances and begin managing all of our detection at the machine-level. On a machine we can see what’s happening on the file system, what’s happening in memory, what’s happening in the OS, and even what’s happening in the application (for common applications). That’s far more telemetric data to isolate signals and ignore noise (assuming we use all that data wisely).

Many of the “next-gen” approaches live in a poor middle ground; they try to simulate the machine, but generally can’t afford to create an accurate or effective simulation. If an organization is trying to protect a thousand servers, how many appliances would be needed to thoroughly simulate every inch of network and each bit of traffic that crosses? The answer is about a thousand appliances, which is far too cost prohibitive. Most organizations prefer one appliance to protect hundreds or even thousands of machines, which is clearly insufficient.

The Future: Will Be Worse

The standards community is finally embracing the less is more philosophy as it prepares to launch TLS 1.3. This new protocol will ensure there aren’t straightforward back doors to subvert end-to-end encryption. Right now, most security appliances rely on those back doors as a means to provide detection (they need to be able to see the decrypted traffic). The new standard is going to require IT organizations have man-in-the-middle for every hop if they want their security appliances to work. That will add massive latency and expense, so most people won’t do it, and appliances will become even less reliable as a result.

Additionally, the rise of containerization and micro-services will exacerbate the situation further, since putting container-to-container traffic on the same machine is well beyond the reach of any appliance.

Security appliances may seem better than anti-virus, because they occasionally provide some value and don’t add as much attack surface. On the other hand, Anti-Virus software doesn’t drown organizations in an ocean of spurious reports. Besides, at least AV now has credible alternatives, unlike an appliance. Security appliances are not worth the silicon they’re printed on and should be cursed in the same breath as Anti-Virus.