Posted on Apr 17, 2015

Automated Trust is Not an Oxymoron (when it comes to security)

Realize it or not, the unstoppable force of machine-to-machine, device, and ‘thing’ connectivity is in our faces every day. Twenty-four hours go by and another 14 Million devices come online for the first time. A hefty number of these devices are being connected to enterprise networks, and an astonishing number are being added to the Industrial Internet, which is the convergence of legacy and modern automation systems onto TCP/IP networks. For enterprises, the connectivity explosion is fueled by expanding partner and customer ecosystems, new business models calling for the cloud, and don’t forget plethora of mobile devices they need to support.

With respect to the massive surge in all these connected devices, recent surveys reveal that both end users and IT professionals rank cybersecurity as their top concern with this trend. They ought to be concerned. The fact is that enterprises and organizations have very porous perimeters, yet are still relying on traditional perimeter security models using IP and MAC as identifiers. It’s an understatement to say that our defensive lines are falling short under the sheer volume of configuration options that accompany this exponential growth in device connectivity. To expect manual (human) processes to address these configuration changes is unfathomable. Increasingly, you hear a lot about the need for ‘trust’ to bolster cybersecurity. I agree wholeheartedly, but would qualify that we require ‘automated trust’.

The recent revelations about China’s Great Cannon are a case in point. The Great Cannon report by Citizen Lab concludes with a call for end-to-end encryption. Without end-to-end encryption, data can be modified in-flight. However, encryption is easy, but the hard part is setting up the appropriate trust relationships on either end of the encryption. The recent blacklisting of a Chinese Certificate Authority (CA) illustrates this point, and the need for moving beyond the browser-based SSL/TLS trust model is shown by attempts like public-key pinning, Google’s Certificate Transparency project, CRLSets, OSCP, and others.

To Err is Human
Human error is inevitable, which is why automated trust is essential to achieve security. It is the only way to deal with what is no longer a tractable problem for humans. Automation, however, can also make a lot of things go wrong at once; therefore automation systems must be secure by default so errors are much harder to make. This is like building safety controls into industrial automation systems. Security must be impossible to bypass under normal operations. To achieve this, Tempered Networks’ has created a solution that is operationally-focused, not in terms of policy expressions, but in terms of what users are trying to accomplish. These operationally-focused statements are then turned into policy whitelists that enable trusted communications between the specified operational systems.

Standards play a vital role in our efforts to build well-tempered networks, and we are honored to lead some of TCG’s efforts to secure our nation’s business critical infrastructure and information. Government also plays a critical role in promoting adoption of these standards as best practices. Ultimately, industry plays a vital role by innovating and adding value while responding to realities on the ground.

Our Participation at RSA 2015
On Monday, April 20, we’ll be participating in TCG’s demonstration showcase, along with PulseSecure, where we demo our unique solution for implementing cryptographic overlay networks (CON).

The next day, April 21, Tempered Networks will be sponsoring SecurityCurrent’s inaugural Security Shark Tank – featuring the Security Sharks where cutting edge

Security vendors have 15 minutes to pitch to a room of seasoned security executives committed to protecting enterprises and government organizations in the United States and around the world.

 

Posted on Mar 4, 2015

ISP private networks are getting a lot of play these days, and we know that they are certainly an option organizations may evaluate in considering network security vendors. To make a fair evaluation, it’s important to get a full understanding of what we’re talking about when we propose using an ISP as a
cyber-security service.

The ISP private network offering is an outsourced mix of private APN, MPLS, network ACLs, VPNs, and firewalls, and varying levels of integration and service offerings around these technologies. The private APN is a wireless network segregation mechanism, similar to a VLAN or a WiFi SSID, and is used to allow the cell phone to bind a client to a particular network with specific properties and services; the private APN can also be tied into wired infrastructure with MPLS. Note that these segregation mechanisms do not natively provide integrity protection, confidentiality, authentication, or authorization. Within these APNs, additional segmentation mechanisms like Access Control Lists (ACLs) and VPN encryption can be layered within the APN.

When I think of ISPs, I think of network connectivity as being just another utility, like power and water. However, I have four main cautionary reservations around these same ISPs providing cybersecurity services:
1. Risks and challenges of ISP lock-in
2. Benefits of an independent layer of security
3. Appropriate levels of visibility, auditing, governance, and change control
4. Standards-based solutions that are open and vetted

First, let’s discuss the ISP as a network utility. Tight integration with the utility looks good on some levels, but what about an event that forces you to change utilities? With power or water, hooking up to a new utility is easy: there are standards around electrical interconnects and plumbing. We have great standards around Layer 2 and 3 network communications. But when a complex and proprietary security architecture is tightly integrated into the core network layer, the switching costs (no pun intended) to a new ISP get very high. Also, any one ISP has only limited geographic coverage, and the integration boundary between providers (and indeed our own corporate networks) is complex, expensive, and slow to change. These realities lead to vendor lock-in, hidden costs, and long-tail risks. The need to drop in a new network can come at any time, particularly in disaster recovery scenarios, and we need an operational model that smoothly accommodates these dramatic changes.

Second, there are plenty of proof points to justify an independent layer of security sitting between critical infrastructure components and the critical network communications layers that connect them. Network components have patch and obsolescence issues just like industrial automation equipment. Weak link-layer encryption algorithms (2G GSM), rogue cell tower attacks, and recent breaches at the encryption layer of the mobile network level all reinforce this point. More than ever, cyber-security is an ongoing process and must be positioned as a highly dynamic and flexible defense-in-depth approach to protect, detect, and respond in a virtuous cycle with both operations and the network.

My third point ties into the defense-in-depth model. A key aspect of implementing defense-in-depth is having a governance model that is appropriate for your organization. This is not a fixed line in the sand, but rather a continuum along which your organization will move back and forth. Without the appropriate visibility, use of ISP private networks will lead to gaps between the ISP and operations that are similar to the IT-OT divide that is present in many industrial enterprises today. For example, what does change management look like when the asset owner needs an ACL change to allow the SCADA system to poll data from a new pump station? Do you submit change requests to the ISP, including revocation? Can you do this on your own? Where is the audit trail? How about troubleshooting and having the appropriate level of role-based visibility and control into the connectivity and security configuration?

Finally, when considering the technologies we deploy to strengthen the operational integrity and availability of our critical infrastructure, we must avoid security through obscurity. Rather, we should discuss architecture models, protocols, and implementation standards in open forums so they can be vetted, solve real problems, and evolve as necessary. These standards exist, but is the ISP using them for security? Unfortunately the answer is no; otherwise, you could mix private APNs from multiple providers out of the box. This is a great topic for discussion, and with the ongoing escalation in the threat environment, its importance is recognized from the shop floor to the top floor. Tempered Networks is committed to bringing the conversation to the forefront. Along with Polk County Utilities (Florida), we will be presenting a peer-reviewed, accepted paper to discuss this very topic at the ISA Water / Wastewater symposium in August 2015.

Posted on Jan 8, 2015

The Internet was never engineered with security in mind. IPv4 was built for resilience and reliability, not security. There are a lot of bad people who take advantage of this fact and plenty of good people who simply make mistakes. The software and security industries set about to fix this problem by encrypting communications with protocols like SSL/TLS, HTTPS, SSH, SLADP, DNSSEC, IPSec, etc. Problem solved, right? Wrong. Unfortunately these protocols on their own do not move the needle very far, and maybe even move us in the wrong direction. As it turns out, adding encryption to communications is the easy part. Adding trust, on the other hand, has to this point been an intractable problem.

Why is there a problem with trust? Two reasons: First, currently, access to apps and IPv4 communications are both tied to the same piece of information: the IP address. We do not have a cryptographic identity to use for communications, which is why we have to login to every “secure” application like banks, email, and medical records. Second, there is no good way to manage trust relationships. Trust on the Internet is largely a leap of faith.

Sure, the communications are encrypted. But with whom are they encrypted? Does it matter if you encrypt your password over the network if it’s going directly to an adversary? Attribution on the Internet is nearly impossible today. The browser-based trust model of hundreds of trusted CA certificates does little to assert trust and assurance for the underlying communications. Case in point is the Diginotar CA hack.

Imagine for a few minutes that there is a ‘Facebook for Internet communications’. You become “friends” with services you trust. Think about the act of becoming friends – it is a very intentional, willful act. And this relationship can be broken at will when the friendship changes. What if you were only friends for a very specific point in time in order to accomplish a specific task, such as coordinating a time and place to exchange critical information? On Facebook, a friend’s profile gives you a lot more information than just a name or a phone number; you get photos, friends of friends, a past history of events (in some of which you were a participant), you get a profile with sufficient context that it becomes much more difficult to spoof. (OK, social media profiles are spoofed all the time so this metaphor only goes so far, but ultimately we’re talking about cryptographic identity “profiles” that are much, much harder to spoof.) The point being is that we need a social media-like way to express and manage the way we trust and communicate with other entities on the Interwebs.

The easy argument is that bad stuff will still make its way into our computers, and this will certainly be true for some time to come. But we need a path forward, and I have zero confidence in a “flag day” when everyone will flip over to a secure version of the Internet. We need a migration path that lets us begin to move on from the limitations of number-based (IPv4) communications to identity-based (e.g. context-based) cryptographic profiles. The good news is that there is precedence for this new behavioral model. Who uses a phone book to look up a friend anymore? We use social media and the contexts and tight relationships that are defined in this realm.

At Tempered Networks, we are building the foundational elements of a secure Internet. We are doing this by inserting a cryptographic identity into the communications stack: the Host Identity. This on its own only gets us so far. The exciting but challenging step is orchestrating trust between these identities. We do this today for securing critical infrastructure and information, but it will soon be coming to all communications near you. We will bring encryption and trust to your Internet of Important Things.

Posted on Dec 2, 2014

Now that we renamed the company to Tempered Networks, people have been asking me what we mean by "tempered". It's really a reference to "well-tempered", which means treated so as to develop the desired degree of hardness and elasticity. At Tempered Networks, our mission is to instill that hardness and elasticity into our customer's networks. We do that with a suite of products that implement virtual private overlay networks that work across existing public and private infrastructure.

So what makes a network well-tempered? Communication is only allowed between things that are supposed to communicate with each other.

Common network security schemes often focus on a "zone defense" - creating DMZs and inner zones with firewalls in between, and then allowing traffic between the zones to enable networked applications that actually span across the zones. These perimeters end up being more porous than necessary and difficult to maintain.

By comparison, in a well-tempered network we create groups of hosts that are allowed to communicate, independently of where or on what LAN the hosts are on, or on how they are interconnected. Hosts can simultaneously be in multiple groups. Tempered Networks calls these groups "overlay networks" - a simplified way to express otherwise complex network policy.

For example, suppose we have a big machine in a factory. That machine needs to communicate with the process controller, in a different part of the factory. But maybe it also needs a communication path to the engineering offices where the programmers work. And the techs need a way to get firmware updates from their staging server to the machine. And the analysts in the QA department down the road want to collect statistics. And the InfoSec team needs access to the logs. Of course, each of those teams talking to the machine will be talking to other machines also, and to other parts of the company. QA department talks to the supply chain system but InfoSec does not. And it may all be changed next week!

With the Tempered Networks overlay approach, we might define one overlay network just for this one machine. Everything that talks to the machine is in the overlay network (and in other overlays for other machines). The above paragraph becomes a nearly exact specification of an extremely specific policy. The overlay network transcends VLANs and addressing schemes, and spans across firewalls, NAT, public networks, WAN, VPN, etc.
This approach hardens networks by enabling fine grain control over policy, while keeping them elastic, with a safe and simple way to create new secure communication paths across the enterprise. That's what we mean by a "well-tempered" network.

Posted on Nov 20, 2014

It’s not just a great song by Tower of Power; the Host Identity Protocol (HIP) is a game changer in network communications. Let’s get some of the technical details out of the way and then discuss what it means:

HIP allows consenting hosts to securely establish and maintain shared IP-layer state, allowing separation of the identifier and locator roles of IP addresses. HIP uses public key identifiers from a new Host Identity namespace for mutual peer authentication. The protocol is designed to be resistant to denial-of-service (DoS) and man-in-the-middle (MitM) attacks. When used together with another suitable security protocol, such as the Encapsulated Security Payload (ESP), it provides integrity protection and encryption for upper-layer protocols, such as TCP and UDP. HIP has matured over 15 years of research, development, and deployment from companies like Boeing, Verizon, and Ericsson, as well as research institutions around the world.

The drawbacks of the dual use of the IP address cannot be understated, and are largely responsible for many of the Internet’s security and networking problems. With HIP this pattern of misuse is corrected, and the upper layers of the stack can now use a Host Identity in their socket APIs instead of an IP address. HIP then establishes secure communications between cryptographic identities, and binds local and remote application interfaces to these identities. At layer 3, IP addresses are still used for network delivery and routing. With IP addresses used to locate but not identify hosts, HIP enables seamless mobility (changing addresses), multi-homing (using multiple addresses), and switching between address families (IPv4/IPv6) while maintaining secure sessions. Extending to the extreme edge of the network, HIP Diet Exchange (DEX) enables HIP for extremely low-power, resource constrained IoT devices. Individuals can also use HIP with anonymous Host Identities, so the Internet can finally deliver anonymity when you need it and trust when you demand it. In summary, HIP embeds authentication, integrity, and authorization at the application level for free, without breaking the existing socket API!

November 19, 2014 is a remarkable day for HIP. After many years of development, testing, and consensus building, HIP RFC 5201-bis was just approved by the IETF as a proposed standard. This is an important step; however, the true measure of a standard is adoption and there are a number of challenges to supporting a new protocol like HIP. HIP allows us to gracefully and gradually embrace the path of Software Defined Networking. Based on 7 years of R&D at Boeing and now working with Fortune 500 clients, Tempered Networks discovered that we can enable HIP secure communications while performing a very vital function: protecting critical infrastructure and information. The Tempered Networks HIPswitch provides a migration path for non-HIP-enabled endpoints to “get” HIP. Over time endpoints will have HIP embedded in the protocol stacks, much like TCP/IP, ESP, and DNS support are built-in to any operating system.

By the time HIP is widely deployed, the challenge of the Internet moves from one of routing to one of orchestration. Orchestration enables highly dynamic definitions of network trust relationships at the identity level, along with routing and policy definitions at Internet scale. This is what we’re setting out to build at Tempered Networks. And that’s HIP!

Posted on Nov 13, 2014

BlackEnergy (aka Sandworm) malware is another ICS game changer. It could be another watershed event like Stuxnet, highlighting the nightmare scenarios faced by modern industrial enterprises: loss of control/view reconnaissance, data exfiltration, and latent attack. How did we get here? BlackEnergy attacks GE Cimplicity, Advantech, and Siemens WinCC Human Machine Interfaces (HMIs) by leveraging vulnerabilities in Windows and vendor software. The attack vectors are primarily network-based, but air-gapped or perimeter-protected networks can be penetrated via removable-media.

What are some of the obvious discussion points? The HMIs are quite simply exposed to communications networks that are far too open! Patching is always problematic in ICS, which makes the software on these HMIs difficult to keep updated, especially when ICS vendor certifications of the patches are required. The testing cycles are lengthy and system downtime is disruptive. Once a successful attack is in play what can we do to prevent communication back to command and control (C&C) servers under the control of the attackers? What can we do to mitigate this general class of problems? The obvious first step is to make the ICS devices disappear from view. Not an air gap, but a trust map. We must retrofit high assurance communications into ICS networks to “cloak” ICS devices from everything, except between trusted peers. Trust must be based on something much stronger than IP addresses, MAC, protocols, and ports. Network “trust relationships” must be defined cryptographically, but packaged in such a way to function at scale without breaking existing networks.

The hack of today is energy companies compromised by BlackEnergy. Notice how common these stories are becoming? We used to talk about hack of the year; then hack of the month. If you don’t see a disturbing trend, then you need to pay closer attention. The industry must step up to the challenge and disrupt this trend. It’s imperative that we raise the bar as high as possible to stop new infections and neutralize existing infections, while maintaining operational integrity and availability.

--David Mattes, Co-Founder and CTO