One thing you tend to get with a move to the cloud is a flat network. You have a virtual network perimeter, but inside the network, you’ve got no points of control unless you put them there by hand. If you logically group your workloads along the lines of an old-school tiered architecture, you can put in virtual appliances such as next-gen firewalls, but you have to do this manually and it’s not a setup that really delivers on your need to scale workloads dynamically. At the end of the day, this means security remains a drag on the business and no one wants to be “the guy” who slows things down.

This was all spelled out in a great article that recently appeared on SearchSecurity.com. In the article, Dave Shackleford spelled out his laundry list of what’s wrong with a non-cloud approach to securing cloud infrastructure:

1. Flat networks abound
2. No native monitoring of east-west traffic
3. Limited routing control
4. Network access control is often primitive
5. Inline intrusion detection are difficult to implement
6. Content-based inspection capabilities are scarce

He goes on to point out that it’s possible to remedy some of these ills using some of the native capabilities in cloud environments, such as security groups in AWS and network security groups in Azure. While I agree that it’s possible to tighten up a network this way, there are some important ways in which this approach falls short when even mildly stressed. The primary issue is complexity—lots of workloads and lots on interconnections among them—and this has to be countered with automation. You simply must have automation to handle the process of configuring the microsegments that connect all the workloads on your network.

Bottom line: you need to get the logic of your security controls expressed directly in the interconnections of your network architecture. Again, you could in theory do this by hand using the tools I’ve mentioned, but if your infrastructure is of any size or complexity at all, you really need the next level of tools to automate this. Not only that, but you need these tools to dynamically follow the changes in server workloads on your network on an ongoing basis and readjust policies and microsegments on the fly.

As ShieldX is deployed, it automatically creates a summary of your workload assets and then uses a machine learning algorithm to discern what kinds of processes are running on each workload. If your organization uses containers and has developed a discipline of tagging your workloads, these tags are used to directly and automatically deploy policies to govern the microsegmentation of your network. Otherwise, the grouped workloads are presented to you in a user interface that makes it easy to express policies for kinds of workloads.

From all of this, logical tiers are created and dynamically updated so that the tiers continue to govern communications among workloads as workloads scale up or down within various tiers. This elastic tiering is unlike anything offered by any other vendor and—another unique characteristic—this is done without the need to deploy agent software onto each workload.

Why does it matter whether software agents are used? For one thing, in legacy situations it sometimes just isn’t possible. Perhaps more importantly, this runs counter to the very idea of containerization, where you want one service or function encapsulated per container (and often isn’t possible even if you don’t care about the aesthetics of it). Either way, you wind up with a microsegmentation capability that leaves critical workloads out of the equation.

ShieldX doesn’t use agents. It also doesn’t rely on the manipulation of ACLs, the problem being that ACLs are an inherently IP-address-centric approach. More agile microsegmentation is possible using approaches such as Cisco Underlay Networks and Azure User-Defined Routes.

To conclude, the ideal multi-cloud solution would:

• Automate and continuous discovery of assets.
• Autogenerate security policy.
• Auto deploy controls to fulfill dictated policies.

Without this level of automation, security teams continue to exist in a perpetual hamster wheel. The cloud—along with cloud native solutions—bring the promise of automation and economics that traditional vendors have failed to leverage.  In the old days, IT teams manually managed networks but eventually migrated to SDN.  Now, with ShieldX, its security can enjoy the same level of agility.

When we recently saw TLS 1.3 approved, what we really saw was the introduction of best-of-breed security capabilities end to end. This latest iteration of what was originally known as the SSL protocol addresses security shortcomings from the previous version and significantly reduces latency with abbreviated and simplified handshakes. It’s more secure and it’s faster: win/win.

As you might expect, the ShieldX Elastic Cloud Security platform can transparently proxy TLS 1.3 connections and thus customers may use the platform to secure both server and client workloads with inbound and outbound proxying. ShieldX supports all aspects of the protocol and works with popular implementations such as NGINX, Google Chrome and Mozilla Firefox.

Perfect forward secrecy

A concern for key-exchange frameworks like TLS is whether future compromises of a secret key will expose prior communications. Perfect forward secrecy (sometimes just called forward secrecy) means that your session keys will not be compromised even if the private key of the server is compromised. Forward secrecy thus protects past sessions against future revelations and this is now part of TLS: session setup now only supports key exchange modes that provide forward-secrecy. Key exchange methods that don’t provide forward secrecy (non-ephemeral Diffie-Hellman, for example) are deprecated.

While this is great, one important note is that better encryption makes inspection via an inline proxy essential to prevent encrypted threats from passing into internal infrastructure unnoticed. A previous blog entry, for instance, looked at inline proxy when defending against Petya malware variants.

Improved TLS handshakes

TLS 1.3 does things more efficiently and with greater security. All session handshakes that include sensitive data will now be in encrypted form, supporting encrypted extensions (only “client-hello” and part of “server-hello” are exchanged in clear text). For further simplification, several handshakes such as “server-key-exchange” have been deprecated.

According to one cloud proxy provider, about 60% of web connections are from first-time visitors to a site, a situation which the improved handshakes in 1.3 signficantly speed up. For the 40% of connections where the site was recently visited and the previous connection is being resumed, 1.3 supports 0-RTT (zero-round-trip) reconnection. This decreases the time required in the returning-user scenario by not waiting for certain parts of the handshake to be fully returned before proceeding.

Better key and certificate handling

Several elements of key derivation and certificate exchange have been tidied up in 1.3:

• A new Key-Update mechanism is a more secure approach to refreshing the symmetric encryption key that doesn’t involve repeating the initial certificate exchange.
• Packet hashes are included in key calculations, making keys more secure than ever—what was an optional extension in 1.2 is now part of the base protocol.
• Key derivation/calculation doesn’t use packet fields that are exchanged in clear-text (TLS 1.2 and earlier protocols used to include client random and server random fields to derive keys).
• The protocol now uses HKDF (The HMAC-based Extract-and-Expand Key Derivation Function) for key derivation. Separate secrets and key blocks are generated/used to exchange SSL handshake and SSL application data.
• Going forward, available cipher suites have been pared down so that AEAD (authenticated encryption with associated data) ciphers like GCM and CHACHA-POLY are available and other prior options have been removed. AEAD combines both encryption and authentication into one step, rather than using a key and a separate message authentication code (MAC).
• TLS 1.3 supports a proposed extension that allows certificates to be compressed and exchanged in a new TLS session’s handshake. Since certificates can contain a fair amount of text information, they are good candidates for compression. Reducing the certificate size reduces the number of bytes exchanged and thus reduces latency.

Need for TLS inspection

As hinted above, inline proxy inspection of network traffic becomes more important than ever with TLS 1.3. Network threats continue to evolve, especially in their ability to evade detection and penetrate enterprises. Sending malicious data across encrypted channels is perhaps the easiest way to evade detection because many organizations continue to deploy and operate their security perimeter devices without inline, decrypted packet inspection.

Even in cases where organizations deploy TLS inspection, they frequently use it in tap mode or else enable a non-proxy mode by downgrading the security capabilities of their webservers to use RSA or other non-ephemeral key exchange methods. This not only breaks forward-secrecy, it also endangers end consumers by weakening the security capability offered by the protocol. (In the interest of completeness, note that application detection and classification that works based on the TLS SNI extension will continue to work.)

In almost all cases, though, enabling TLS inspection is an important first step. Using TLS proxy inspection provided by Shieldx Elastic Cloud security platform, enterprises may further leverage our “Indicators of Pivot” feature to detect and block advanced threats and lateral movements inside their network.

ShieldX was reviewed by our customer, Larry H Miller dealership group. Some highlights:

• For other security professions who are looking for something which is low in cost that does microsegmentation, they should look at ShieldX.
• With Illumio, you have to install an agent on every server, and you don’t have to do that with ShieldX, because it is agentless.
• What I like about it now is that it has a single pane of glass to view our networks and groups.

The full review is here: https://www.itcentralstation.com/product_reviews/shieldx-review-60870-by-branden-emia.

SC Media has published its February 2019 “cloud-based security management” group test which included a review of ShieldX’s Elastic Security Platform product. You can view the five star review HERE.

Some highlights:

• With the capability to have a single pane view into any environment, along with dynamic scaling, visibility and discovery across a multi-cloud infrastructure, this product is worth adding to the top of your list.Full stack protection is offered with FireEye, APP-aware ACL, DLP, malware detection, full-flow packet capture IDS/IPS threat detection and prevention, virtual tap, URL inspection for reputation and classification/filtering, unique anomaly detection, and micro-segmentation.
• Every workload and application in your data center will be fully mapped automatically without agents.
• Automating infrastructure, security and applications helps ensure microservices are inserted when and where they are needed. These microservices are inserted directly into infrastructures. This allows for automated intent-based security policies.
• Security Analytics has a unique component called Indicator of Pivot (IoP) which is based on kill chain methodology.
• With a fast time-to-value return after a quick 30-minute installation, operational efficiency increases visibility and discovery seamless across a multi-cloud structure with a single pane view into any environment using tools you know.
• WEAKNESSES:None that we found.