Attacking Ransomware

Gas, toilet paper, ransomware and the business WAN

The ransomware attack on the Colonial Pipeline business WAN raised cybersecurity consciousness in a similar way as the COVID-19 pandemic outbreak raised awareness of our fragile supply chain. Turns out that gas in your car and toilet paper in your bathroom are pretty important. 

So I got quite a few questions about how the Colonial Pipeline business WAN could have been fortified so as to have thwarted the ransomware attack. Those are the wrong questions. 

Note: I am using "business WAN" as an umbrella term for the combination of SD-WAN and MPLS-WAN architectures, firewalls, passwords, VPNs, private circuits, IPS/IDS, SWGs, proxies and the multitude of structures which are bolted-together to try to provide secure networking.

Let’s revisit C-19 for a moment. Not just what did happen with toilet paper and other supply chains. Let’s also look at what didn’t happen. At the start of the pandemic, we were very concerned about 'work from home' security. After all, many of us would be outside of the protection of our secure business WANs, exposed as mainly unprotected targets on insecure home networks. Results?

1. Well, here is what didn’t happen. Of the hundreds of millions of us working from home, outside of the business WAN, none of us were victims of any type of cybersecurity attack which caused us to pay millions in dollars in ransom, or caused our business to stop being able to serve customers.
2. And what did happen? Our 'secure' business WANs have been constantly breached by highly damaging attacks which have leveraged vulnerabilities in SD-WAN, firewall, VPN and WAN management software. The breach of the Colonial Pipeline WAN, costing them millions in ransomware (some may have been recovered via government intervention), was the rule, rather than the exception (experts expect 65,000 similar ransomware attacks to hit US businesses this year).

So, combine what did happen with what didn’t happen, and it helps shine a light on the fact that the business WAN itself is the problem. The traditional business WAN is a vulnerable, valuable and obvious target for ransomware and other attacks. Can you fortify it? To a degree, but that’s not the best question. For a vulnerable, valuable and obvious target, the first question should be: can we eliminate the target. Most targets can’t be eliminated, so we need to defend them. But we have been taken it for granted for too long that the business WAN falls in this category – we can go on the offense – we can proactively eliminate the target. This is the single most effective thing we can do to mitigate the ransomware threat.

Business WANs are too valuable…to ransomware and other attackers

Businesses no longer use software. Businesses are connected software. If you are breached, then you are not 'just' suffering internal type consequences. Your entire business ecosystem - including your customers, or your entire connected supply chain, may be damaged. This is why the Colonial Pipeline and JBS each recently had to pay millions of dollars in ransomware to try to quickly get back to full operation after their WANs were breached.   It is also why they were targeted - cyber attackers are attracted to business WANs because that is where they can cash in. It is why you generally were not targeted when working from home – if an attacker can get into your home network, but not your corporate network, are they going to get millions of dollars of ransom from you? Probably not so they are not as incentivized to attack you there. Remove the WAN and we remove a very attractive ransomware target.

And we need to move quickly to eliminate the business WAN, because they are getting even more valuable. We are moving towards a world of massively distributed, AI-infused software, hyperconnected across administrative domains by APIs and microservices. That hyperconnected world is predicated on a foundation of secure networking. If the business WAN can be used to breach that foundation, then it couldn’t be more valuable…to ransomware and other cybersecurity threats.

Business WANs can’t be adequately defended

It is one thing to be valuable and defensible. It is quite a different thing to be valuable and indefensible. The latter results in the ransomware attacks we have seen. Despite $150 billion in security spending this year, we are losing the cybersecurity war. High profile breaches such as Colonial Pipeline, JBS, Ireland’s health system, Sony, Target, Equifax and Marriott are just the tip of the iceberg. We will continue to lose the war if we don’t change our strategy. In the case of the business WAN, the best strategy is to eliminate the battlefront entirely, because it is inherently insecure. Let’s not fool ourselves - we have proven we can’t defend it. This is because the SD-WAN / MPLS-WAN based architecture was built for a different world.

Business WAN architectures provide access before fully identifying, authenticating and authorizing each connection. This wide open architecture is like trying to control fans at a World Cup finals match by first letting everyone in the stadium, without checking for tickets, and then trying to find and eject anyone who entered the stadium who didn’t actually have a valid ticket. Except in our case the stadium (WAN) can hold near infinite people (software), the people have thousands of doors via which to enter (recent attacks have used doors like compromised passwords, Slack accounts, SD-WAN devices, firewalls), the people can be anywhere, and those people can come or go in milliseconds.   

Why such an open architecture - one that seemingly invites problems such as ransomware? Because it was designed for a different world. The initial design assumption of the WAN was you can’t get in the soccer stadium – you would have to be ‘in the office’ to access the WAN, on a company provided computer, etc. But that design assumption is invalidated now that our business software spans many edges and clouds, as any node on the Internet can potentially access our WAN. In the past 25 years, the number of nodes in large scale business networks has effectively gone from hundreds to billions. Yes, billions. Any Internet connected node – even an IoT device such as an Alexa, Nest or Ring - is now essentially a virtual node on your business network (or at least can potentially reach your network), meaning that you have billions of attack surfaces. Adding to that attack surface, and making it a moving one, your business software is changing from monolithic apps to composites of hyperconnected microservices and APIs distributed across many edges and clouds.

As if it wasn’t bad enough that your attack surface has been multiplied by 10 million in this new world, the need for speed continues to increase. I stated above that modern businesses no longer use software – modern businesses are connected software. More specifically, modern businesses rely on two critical aspects to best serve their customers: hyperconnectivity (hence the increase in attack surfaces) and speed. The result of this increased need for speed is we are orders of magnitude faster in developing, integrating and delivering software (today’s CI/CD paradigms). Despite all our good work in the DevSecOps arena, this speed and hyperconnectivity makes it difficult to minimize damage since vulnerabilities or 'bad' software (ransomware etc.) can often spread as fast and effectively as the 'good' software. If the bad software can find the weak spot, then it can spread laterally from there and do so very quickly to many connectivity surfaces. Well, it can if there is a WAN to spread across…

Our business WANs – built for an entirely different business environment and application topology – are cracking at the seams. We are barely holding them together despite clever engineers and $150 billion per year of spending. Meanwhile the challenge is getting even more difficult, and the costs of breaches are skyrocketing. Ransomware is just the most recent example. There will be many others. Business WANs are too vulnerable and too valuable. It is time to change our strategy.

The app is the new edge

The first challenge in replacing the business WAN is to acknowledge that it is absolutely necessary in order to mitigate threats like ransomware, and to win the overall cybersecurity war. The second challenge is to adequately replace the WAN. Business WANs simplify the challenge of connecting users to apps, and ensuring those connections are reliable. How can we do that without the business WAN? As always, let’s start with the business challenge and topology. What has changed and where are we going? 

1. Business WANs were designed to connect sites. The dominant topology was sites such as branch offices and private data centers, paired with monolithic apps and a slower speed of business, defining a relatively small, static and centralized number of “edges” to connect. Business networking was therefore designed to connect these edges – to connect these sites. Given the topology, we could then bolt-on secure networking infrastructure to form a business WAN – firewalls, SD-WAN appliances, VPNs, proxies, IPS/IDS, private circuits, passwords, proxies, etc. Bolted-on secure networking could essentially provide reliable app connections for users by connecting the sites where each resided. If you don’t believe this architecture is dead, then ask yourself how many connections go from branch to branch these days (even before C-19). Almost none and yet SD-WANs and MPLS-WANs were designed for branch to branch, site to site traffic…
2. Now our topology is completely different. Our dominant topology will be composed of AI-infused applications, billions of IoT devices and mobile users, all distributed across the Internet. Again, businesses don’t just use those apps – businesses are those apps. We therefore have a new design requirement: the app is the new edge. We need secure-by-design, reliable connections anywhere the app (microservice, API) goes. Bolting on business WAN structures to connect sites doesn’t work when we are talking about billions of dynamic apps, users and devices, distributed across the Internet.

So what can go anywhere the app can go in our new topology of connected supply chains, multitudes of underlay networks, and multi-provider API surfaces? There is actually only one answer. Software which is part of the app - adding code to the app which results in the app gaining the ability to establish secure by design, reliable application connections, from anywhere to anywhere. Only code can keep up with code. Only secure-by-design is secure enough at the speeds of modern business (connected software). When the app is the new edge, and it is everywhere, it better be secure by design.

Built-in replaces bolted-on: secure by design, app-embedded networking

Secure by design is critical because app distribution and speed will continue to increase as distributed compute models become more prevalent (different parts of each workload processing across different devices, edge compute and clouds), and as machine learning (ML) and artificial intelligence (AI) results in apps being even quicker and even more dynamic - taking actions based on model predicted states of the future. Day two security – the bolted-on type paradigm of today – is not secure, nor economically or architecturally viable at these types of distributions and speeds (keep in mind that the attackers are increasingly AI-infused, distributed software as well).

Secure by design is the opposite model of today’s insecure by design business WANs. Sometimes the best defense is a good offense. In this case, secure by design is the offense - rather than play defense against ransomware and other attacks on inherently vulnerable business WANs, we play offense on a secure by design foundation. Here are some of the key pillars of a secure by design application connection architecture:

1. Secure identification. Our new strategy needs to securely identify the app, the user, the device and the networking nodes (to the granularity of securing APIs and microservices). Not what site you are physically at (or seem to be at). Not IP address based identities. Not VLANs. Actual security identity such as combinations of the private key / public key cryptography solutions, biometrics and root of trust solutions used successfully in non-network domains. 
2. Authenticate before connect. Leveraging our secure identities, we need to authenticate each requested application connection before we connect it. Again, the opposite of today’s business WANs (which inherently connect nodes at layer two or layer three, and then try to authenticate). No auth = no data path.
3. Least privileged access authorization. Each authenticated, authorized app is granted its own ephemeral connection, accessing only what it needs to access. For example, a single microservice or API in a single cloud. Policies can therefore be enforced at app session level granularity as well, e.g. access granted (or revoked) on specific combinations of state, location, time, posture checks, etc.  
4. App session level microsegmentation. Each app makes its own unique, ephemeral connection, can only access what it requires, and is logically isolated from every other session. This isolates any damage, by design. If an app session is breached, then that breach can’t be used to attack laterally through the business WAN (the business WAN is not there), such as we see with ransomware. Combining microsegmentation with least privileged access has massive security benefits across a variety of use cases beyond containing ransomware including: separating OT, IoT and IT environments; isolating APIs and microservices; separating supply chain partners; enabling vendors to remotely manage their software without accessing anything else. 
5. Outbound only. An ideal architecture enables devices to only make outbound connections to identified, authenticated, authorized sessions. This means the devices can be fully shielded from any unknown inbound requests. Combined with the attributes listed above, this flips the firewall paradigm into a far more secure model – instead of trying to figure out what to block (mainly reactively), we only allow what we have properly identified, authenticated and authorized. We go from defense to offense.
6. Great user experience (UX). Wait, what’s UX doing in a secure by design list? Look at VPNs as an example. VPNs were perceived to be secure for their initial use cases. But the UX was horrible. App performance would suffer, they were hard to use, they were difficult to administrate and manage. Result? Most businesses figured out how to avoid the VPN. They created complex webs of exceptions, workarounds, configurations, backdoors and side doors to keep apps such as voice and video off of the VPN. The bad UX of VPNs meant that the net result was more complexity, and a solution which was insecure by design. If a solution is truly secure by design, then the UX has to be great. This includes controls, visibility, management and reporting. This includes optimizing the performance of the app itself – making sure each app connection is reliable with minimal jitter, packet loss and latency.

Most zero trust networking solutions don’t go far enough

Given the hype around zero trust networking, I know many folks are thinking: what about zero trust networking? Isn’t it the answer? There is a simple litmus test – does the zero trust networking solution preserve the business WAN or not. If it preserves the WAN, then there still is a very valuable, vulnerable target, and therefore the zero trust solution hasn’t gone far enough. Said the other way, the ransomware can still spread.

A complete zero trust networking solution – one which eliminates the WAN – means that successful attacks only breach single app sessions. Take the Colonial Pipeline ransomware attack. Was it caused by a compromised password? That's not the root cause of the massive damage – the compromised password was just the door which the attacker used to take advantage of the business WAN vulnerabilities (remember, there are now millions of those doors for ransomware and other attacks to choose from). If the compromised password was used in a full zero trust, no WAN, app is the new edge architecture, then the specific app would have been compromised. And nothing else. No lateral movement of the ransomware through the Colonial Pipeline WAN to get their critical business data. Meanwhile, if the compromised password wasn’t available to be the vehicle into the business WAN, then the attack would have found another vehicle (as we have seen in countless attacks). So, could zero trust have limited the damage in ransomware attacks like Colonial Pipeline, JBS and Ireland’s health care system? Yes, but only if it is full zero trust, embedded in apps, eliminating the ability for attacks to spread through the WAN. To be clear, even a full zero trust architecture is not magically resistant to all attacks, but it does inherently simply our job in containing the damage.

Notes regarding the ‘eliminate WAN’ terminology:

1. The underlay networks are still there – but they can’t ‘connect’ any sessions which have not been properly identified, authenticated and authorized as described above. The underlay networks can be important from aspects of UX, e.g. if the app embedded secure networking can choose between multiple high performance, low latency underlay networks, then we maximize chances of high quality connections.
2. In fact, once the app-embedded secure networking is taking care of the security, it means business WAN liabilities can become assets. Take firewalls, VPNs and WAN management software for example. All three have been breached mercilessly and are liabilities in an architecture which depends on them for security. But can they serve as additional layers of security if a breach wouldn’t result in a Colonial Pipeline or JBS type situation (since there would be no WAN for the attack to spread across)? Yes, if leveraged properly. Since a journey towards app-embedded, fully zero trust networking can be a long journey, properly utilizing those types of legacy business WAN structures as part of the transition can be important.

0 MPH to 100 MPH in 2 seconds

Going from today’s business WAN architectures to tomorrow’s full zero trust architectures will not happen in two seconds. It will be a journey measured in months or years for most companies, and it will include both app-embedded secure networking (built into the app by the developer) and business-level controls and structures (such as identify and policy) across all the apps. Think of it as layers of security – in the same way that (virtually) all websites use SSL/TLS today (built into the app by the developer), while businesses still put other layers of security on top of the web sessions (proxies, inspection, gateways, etc.). The difference however is we go from bolted-on to built-in: the structures are all done as code, in a secure-by-design architecture.

In the meantime, we still need to deal with ransomware and other threats. So we do need to fortify the WAN as we go on that journey, in a manner that both helps the journey and improves security in the meantime. Again, the undeniable goal – the North Star - needs to be a full zero trust architecture (we acknowledge there is no such thing as a secure business WAN for today’s business leads). I reiterate that goal because otherwise we will get sidetracked in fortification of the WAN and end up losing the cybersecurity war. However, keeping that destination front and center, there are a few best practices we can adopt as we journey towards Polaris:

1. DevSecOps practices attempt to identify vulnerabilities before they get into production (during the build, at integration or in lower (non-prod) environments), and to insert safeguards into coding, integration and deployment processes. These DevSecOps practices can help contain the spread of successful attacks. 
2. Disaster recovery (DR) techniques can help minimize post-attack damage - implementing architectures, systems and processes to be able to 'cut over' to known good states (if you are not regularly running your business from a secondary cloud to prepare for a DR scenario, with plenty of snapshots of prior data and app states to revert to when you realize your last (n) snapshots are corrupted, then you likely will *not* smoothly cut over to "backup data" following an attack). This one is particularly important for ransomware. If a business had a truly resilient, available environment of known good data to operate from, then ransomware attackers would not be encrypting *the* data, but would be encrypting one copy of the data. Not nearly as impactful.
3. Greenfield initiatives – new apps, APIs, cloud, IoT deployments, etc. – are great opportunities to go zero trust from the start. APIs in particular, given their rapid rise in number and importance, and their inherent vulnerability if they are part of a WAN or exposed to the Internet, should be made into secure by design APIs, from the start.

Eliminating the business WAN can help turn the tide in ransomware and the overall cybersecurity war

Seemingly each day there is yet another high profile victim of inherently insecure business WANs. The attack vectors vary – recent, highly damaging attacks have targeted firewalls, SD-WAN devices, compromised passwords and WAN management software. Ransomware is one example of many. Almost all the attacks are damaging because they spread laterally across the trust architecture of the SD-WAN or MPLS-WAN – once the attacker (software) is inside the WAN then it can go just about anywhere. It is time to eliminate the WAN, replacing it with zero trust app connections, built into the app. This reduces the attack surface, strengthens each target, isolates any successful attacks and makes each target much less valuable. Eliminating the business WAN also disincentivizes the attackers – it drives their costs way up, and their rewards way down.

Historically, it has been difficult for businesses to invest in the most secure solution. Mainly because security was seen as a cost center – an expensive insurance policy. Not everyone invests in expensive insurance policies. This is changing now that businesses are connected software – we are getting to the opposite state in which a business can’t afford not to invest in maximum security. In fact, the recent ransomware attacks have shown that cybersecurity insurance can be counterproductive. Leading businesses are going to invest in flipping the field - going from defense to offense - moving to a secure by design architecture.

As importantly, the more severe consequences of a breach also mean businesses who can avoid breaches can be at a competitive advantage. What type of competitive advantage would an ISV, SaaS or solution provider enjoy if it could ensure their services cannot be used by attackers to breach their customers? Those solutions mean that even if ransomware or other attacks hit their app, the attack can’t spread laterally through the WAN. On the other side, what type of competitive disadvantage is a rival ISV, SaaS or solution provider at if the app, service or solution they provide could be the conduit for the next multi-million dollar ransomware attack? Providers are going to go on the offense too - the winners are going to ensure they deliver great user experiences, rather than be a potential attack surface for ransomware.

Eliminating the WAN is a long journey. Now is the time to start if we are to turn the tide in the overall cybersecurity war, including preventing ransomware attacks from being able to spread across networks.