Bill Cheswick, a pioneer in internet firewalls got, besides establishing what we today know as the perimeter firewall, famous for the below quote to describe his ideas on perimeter firewalls:
A sort of crunchy shell around a soft, chewy center.
The quote and metaphor is still used a lot by security professionals around the world, to describe the state of the internal network behind the perimeter firewall.
A crunchy shell in the 1990s was exactly the thing you needed to be more secure from the threats found at that time. A lot of it was attacks against servers, buffer and heap overflows on services directly exposed to the internet when not consumed directly from the internet. People could easily DoS or even better, hack, those services. Exposed sendmail servers been a huge target at that time. Everything was exposed and routed, it is hard to imagine today. The perimeter firewall did a great job and shielded the vulnerable services from the evil internet and helped to secure them from the outside world. The internet grew exponentially and threats changed quite significantly and we all know that most threats today focus on endpoints rather than datacenter services as a entry vector.
Segmentation in general and microsegmentation in particular is addressing this and tries to make it harder for compromised client endpoints to spread in the network and cross boundaries.
Inbound and outbound policy
When you think of segmenting your network for security reasons, there are two directions where you can write policy. One direction is into a segment or workload. What it does is it will control access to the segment or workload and control who or what is able to connect to a service.
The other direction is outbound traffic. This is much harder to control if you think about it, because you have to know much more than in the case of inbound traffic. If you think of a inbound traffic rule, you normally know the service and most of the times you may also know who and why the should be able to access that service. Sometimes it may be easy, you just let anyone inside your “trusted” environment access the service.
Outbound is much harder, so a common technique is to leave outbound services open with a allow any rule. This is one of the defaults in most modern datacenter firewalls and helps you to keep things working. To write outbound policy inside your data center or infrastructures including cloud and containers is very hard. You often miss the data to write this kind of policy effectively, especially the visibility, communication patterns and dependencies you need to know to write that policy.
Why is outbound policy so important?
Let’s check how outbound policy can help you to make things much harder for attackers and how they work.
Limiting Lateral movement
If an attacker is in your network, be it by compromising a endpoint client through spearfishing or automated attacks a proper outbound policy will be able to limit the attacker to move further, gather reconnaissance data or explore your network further. This is a common scenario and most attackers will leave a number of traces in your network if your logging and alerting infrastructure is working.
It will also be able to at least slow down automated attacks, worms or some ransomware that rely on spreading themselves further by doing network connections to vulnerable services in your organization (like e.g. Wannacry did).
Limitation of blast radius
Blast radius is a term used to put a metric around the threat that a malicious actor or software can spread in your network. This has been a key element of many malware campaigns, especially with ransomware like Wannacry.
It is very important to limit blast radius to the bare minimum in order to limit the impact of breaches like that.
Making data exfiltration much harder
Let’s take a look at a couple of methods to exfiltrate data:
- network protocols like FTP
- upload via C2 server
- exfiltration using cloud infrastructure
- data hiding using legitimate services like DNS
- exfiltration using intermittent hops inside the organization that have more rights
All of this can be limited by using outbound policy, not only on the perimeter, but also much closer to the application. Because what happens if you could smuggle data out by moving it to assets that have much better access to e.g. your network proxy and can use email, HTTPS or plain HTTP to smuggle data out.
By keeping the outbound policy at the lowest privilege level - or need to connect level - the impact can be dramatically.
Other uses of outbound policy
If you think how we use the network now compared to 10 years ago, everything has changed and there are not many things that you can not use with a REST API. APIs are considerably harder to protect and the daunting task of writing outbound policy will get even harder if you consider API endpoints a part that you need to protect.
Examples for this are:
- Usage of S3 buckets
- Usage of storage services like DropBox, Box or OneDrive
- Usage of paste services like PasteBin
There are a couple of ways you could limit this, many APIs nowadays reside in cloud infrastructure, so why not allow access to all of AWS IP ranges? Bad idea, but i saw this at a couple of companies. It is easy to implement with a perimeter firewall though, maybe you can even inspect the traffic and filter on the L7 protocol. Most people will now use a proxy service, often in the cloud. Parts of this are also addressed by CASB solutions.
The key point here is that most people miss the underlying data to limit access to those services more effectively. You will not find a single organization where network or security people know how external APIs or services are used.
This is sometimes known by application owners that create and maintain or operate those services. A lot of times even those people do not know all the services that are needed for this application. So getting visibility into their connectivity to the outside is key to limit this to a “need to connect” only.
Where to go from here?
Implementing strict whitelists on outbound policy is hard, so my advice would be to:
- get visibility into data flows that are outbound to your applications
- get application owners to attest those flows
- write policy for it and test that policy as rigorously as needed
- enforce and validate policy
If you manage to limit most of the outbound connectivity you have done a significant step to limit the blast radius of incidents and this will pay out in the long run. There is a huge amount of breaches that got public that show how effective limiting outbound policy would have been.
What do you think, what are the challenges of writing outbound policy, what limits you from limiting your applications?
