Author: MetaFlows Marketing

How to Stop Malware in the Cloud

Moving digital assets to the public cloud reduces costs and increases productivity, but it poses some new information security challenges. Specifically, many IDPS that were designed for the on-premises network come up short when deployed in the public cloud. Public cloud providers have built-in security layers to manage information security using their own security monitoring infrastructure to address this problem, but these built-in monitoring services are one-size-fits-all and may miss crucial customer-specific security requirements or user account compromises. This leaves cloud-based assets more vulnerable to data breaches.

And the threats are there. An April 3, 2019 article in ZDNet mentioned that over 540 million Facebook records were exposed on AWS. In 2017, 57 million Uber customer records were compromised because hackers extracted Uber’s AWS credentials from the company’s private GitHub account. Public cloud offers no tools for monitoring the network data that would have detected and prevented these breaches.

Why public clouds are difficult to secure
Public clouds are great when it comes to providing shared compute resources that can be set up or torn down quickly. The cloud provider offers a basic software interface to provisioning storage, servers and applications, and basic security monitoring that runs on top of that interface at the application layer. But the application layer runs on top of the network, and the network is the only place where certain classes of dangerous security breaches can be detected and prevented.

Clouds restrict users from inspecting or logging the bits that go over the network wire. Inspecting a public cloud at the application layer can give customers information about what the network endpoints are doing, but that’s only part of the picture. For example, breaches due to users’ misbehavior are only visible at the network layer by observing the communication patterns that are inconsistent with company policies. The cloud’s built-in monitoring services would not be aware of this misbehavior because they do not monitor network behavior on behalf of the enterprise. Importantly, if malware or a rogue application somehow makes it into a cloud instance or remote VM hosted in the cloud, cloud-native monitoring services may not detect malicious behavior at the network level. Because customers don’t have access to the bits being transmitted, they’ll never know the malware is there.

So what’s a cloud customer to do? Adding NG firewalls from third-party vendors to public cloud deployments adds the ability to customize the inspection of all the bits flying by, but fails to detect communications within the cloud (i.e., between a web server and a database) or lateral communications (for example, a compromised host trying to spread within the internal cloud network between VMs). This leaves blind spots that can allow malware to execute without the user’s knowledge. Lastly, when there is a breach, in most cases, cloud customers can’t even quantify, precisely, the number of records or the amount of data  exfiltrated.

As it’s not feasible to deploy hardware on a public cloud provider’s premises, the way to eliminate these blind spots lies with software that can implement a virtual tap and monitor traffic at the network level. Today, only MetaFlows offers multi-function software that will address these needs.

A New Way to Secure SSL/TLS Traffic

Secure Sockets Layer (SSL) and its successor, Transport Layer Security (TLS), are the primary means of securing traffic between web browsers and web servers. Organizations need to detect and prevent network-based compromises that can be carried through SSL/TLS traffic, but many legacy solutions present problems. SSL/TLS interception is usually achieved by proxying the encrypted sessions through an in-line security device or software daemon which terminates the SSL/TLS session, decrypts the content and re-encrypts it before communicating with the intended recipient. Some issues associated with such in-line architecture include the need for an in-line device and the related cost, latency increases, decreased network availability and potential security exposure. In this article, we’ll look at a new way to inspect SSL/TLS traffic that does not require an in-line device and thus overcomes traditional challenges.

The SSL/TLS Attack Vector
Any exploit that can be carried out in regular traffic can be carried out over SSL/TLS. Because the session is encrypted, it makes exploits harder to detect. Sometimes, the same exploit can be carried out over SSL and non-SSL. SSL can hide applications that the enterprise doesn’t want, such as peer-to-peer systems or instant messaging apps. Most organizations have policies in place that prevent certain content from being posted to public sites, and they want to be able to enforce these policies about what can travel on the network. But SSL-encrypted traffic makes it difficult to enforce those policies.

In terms of malware, a network analyst can’t find virus exploits or other attacks that use SSL/TLS to communicate. The alternative is to monitor endpoint addresses, but endpoint addresses change frequently, leading to false positives and false negatives. In addition, users may use SSL/TLS to download executables, and it’s difficult to block that traffic if it can’t be detected. For example, most phishing and pharming attacks occur in SSL/TLS traffic.

Traditional SSL/TLS Monitoring
The traditional method of dealing with this challenge is to buy an in-line device that decrypts SSL/TLS traffic, inspects it, and then re-encrypts it. There are two key issues with this approach:

Increased latency – because there’s a box in the middle of the traffic that has to decrypt, inspect, and encrypt the data stream before passing it onto the server, the user will experience higher latency in the connection. SSL/TLS inspection device manufacturers try to mitigate latency by adding processing power to their systems, but this increases the cost of the device. In-line inspection devices can cost from $20,000 to $150,000, depending on processing capacity.

Reliability – If the in-line device fails, so does access to the network. And the in-line device needn’t fail to interrupt network access. Browser-server configurations change frequently, and these devices aren’t always up to date, so they can deny legitimate traffic. In addition, the in-line device is responsible for the cryptographic keys that enforce security on the connection. These cryptographic keys may not be configured correctly, and misconfigurations can also interfere with network access.

In virtualized networks, users could implement SSL/TLS interception functionality with in-line software appliances. This approach compounds the problems mentioned above because virtual software appliances have limited CPU capacity to handle multiple real-time traffic flows between the clients and the servers. Public key decryption and encryption are very CPU-intensive, and the traffic can easily overwhelm the in-line software system when the software is inspecting traffic from multiple endpoints to multiple servers. The need for decentralizing this in-line approach in virtual environments would significantly increase costs and compound the reduced availability and security concerns of this architecture.

Endpoint SSL/TLS Monitoring
Here’s another approach: Passive SSL/TLS inspection. Instead of running the inspection capability in the network, it can be run in the endpoints. This is accomplished by running an agent on each endpoint to collect traffic in clear text (before/after it is encrypted/decrypted for transmission/reception over the network), and by sending those results to a server-based or virtual machine-based sensor for inspection and correlation.

Basically, the agent is a transparent tap into the endpoint’s traffic, and it makes a memory copy. This passive SSL/TLS inspection occurs on the endpoints before the traffic is encrypted and sent to the server, so it doesn’t interfere with traffic between the client and server at all.

This approach has several advantages. There’s no increased latency because the agent doesn’t interfere with the network traffic. If the agent stops working for some reason, it doesn’t interfere with the endpoint user’s activity. The agent also has nothing to do with the cryptographic keys, so there are no security or configuration issues.

Passive SSL/TLS inspection addresses the major problems of in-line inspection, maintains the one-to-one relationship between the endpoint and the server, and enables network analysts to see what’s being transmitted over secure sessions. As networks become increasingly virtualized, endpoint SSL/TLS inspection will be the only way to see and react to network exploits conducted via encrypted tunnels between browsers and web servers. Passive TLS/SSL is available today as a software subscription service from MetaFlows Inc. for any Linux distribution, Windows 10 and Windows Server 2016.