Yellowstone Ranch 2.0: Protecting Your Multi-cloud and Hybrid “Herd” with Trust Boundaries
by Mal Fitzgerald
Like many of you, I’ve been sucked into the Yellowstone series. Having grown up and lived my entire life in a congested corner of Massachusetts, the series may as well have taken place on the moon. But I’ve also found the challenges on the Dutton Ranch surprisingly relatable to the challenges we face as network defenders. One challenge is keeping a herd of cattle healthy which they do, in part, by creating boundaries around them and continuously monitoring them. In this way, when a single member of the herd becomes sick the entire herd isn’t lost.
We have the opportunity to do the same thing to protect our organizations by creating trust boundaries within networks.
Trust boundaries consist of logical entities such as a physical location, an area within that location like a data center or the finance department, a country, a block of IP addresses, a group of users, the identity of the device, or the application in use.
At a high level, the steps we go through as we work with clients to create trust boundaries, include:
- Identify the participants in your environment – the devices, users, data, and applications.
- Monitor the activity of these participants to establish a baseline of behavior that is normal or expected.
- Create an alert on each of these assets to inform you when activity is not compliant, so you can investigate why that behavior has changed and take action as required.
With trust boundaries in place, you can validate that your policies are correctly segmenting network activity and enforcing controls across your environment. While implementing trust boundaries sounds straightforward, I see teams struggle to gain an understanding of what they have, what it should be doing, and what it is actually doing given the dynamic nature of their environment.
Networks are now an evolving collection of multi-cloud plus on-prem infrastructure, applications, data, devices, and users. While critical, it can be a struggle to comply with Zero Trust guidelines, industry best practices, or internal compliance requirements, including data access management or network segmentation based on expected application behaviors. The CloudOps, SecOps, and NetOps teams I work with have to deal with far too many blind spots due to the massive gaps in coverage in their existing security tech stack.
- Traditional Cloud Native tools are built specifically for the provider’s individual cloud offering thereby forcing your team to learn, manage, and maintain rules sets across multiple tools in your multi-cloud environment. Additionally multiple tools means multiple data sets, requiring you to try to stitch together diverse data sets, or potentially miss key risk factors that may be present in multiple cloud providers at the same time.
- In the cloud, you should be setting boundaries as you build the infrastructure you need. But how do you validate that the security controls have been set up correctly and that nothing has changed? Given that 80% of data breaches are attributed to cloud misconfiguration issues, clearly that process isn’t happening reliably.
- Endpoint Detection and Response (EDR) solutions have demonstrated clear value, but not every device can support an agent. IoT devices and legacy operational technology (OT) assets typically don’t support the additional code which means there can be hundreds or thousands of devices that go unmonitored. Not to mention devices you don’t control or that are in remote locations. Additionally, EDR is concerned about processes on the device, not network telemetry.
- Your SIEM is only as good as the logs it receives based on how it is configured, updated, and maintained. This means a SIEM can be bypassed, some assets may not be set up to send logs to the SIEM in the first place, outdated correlation directives may ignore important alerts, or it receives so much raw data that it becomes a time consuming and arduous process to generate actionable information.
- Zero trust network access (ZTNA), while great as another layer of defense, can be breached – whether by manipulating the help desk, due to MFA fatigue or any number of reasons. Suddenly a new device is on the network and can move laterally and teams have limited visibility into what is happening because in a Zero Trust architecture (ZTA) almost all network traffic is encrypted.
- Network Detection and Response (NDR) uses deep packet inspection to monitor network traffic but due to the cost and complexity of deployment and decryption, it’s not used in the cloud or everywhere in your on-prem network. Usually, NDR is just in data centers and at prime north-south points of concern. You only get information on what’s happening as traffic passes through points where you have a packet acquisition device. As you move further and further away from your core networking stack, you become much less likely to have the needed DPI sensors in place, therefore missing out on key data needed in investigations.
The Netography Fusion platform eliminates the coverage gaps because it provides network visibility and telemetry throughout the entirety of your multi-cloud and hybrid environment and not just at specific choke points or data centers. You can have a conversation around the behavior happening out at remote networks, within and across different clouds, and all the way down to a specific set of applications. From a workload 1,000 miles away to the three specific machines that handle your SAP application – you can create trust boundaries around what devices, users, and applications should be doing and what should never be happening, and have a rule set to confirm that behavior.
Looking at your network from an asset perspective and the nuance of behavior, Netography Fusion addresses the contours of your environment to detect malicious activities and ensure compliance with policies. For network defenders, these types of boundaries are straightforward to set up and enforce and, bonus, you don’t have to deal with 1,400 lb. animals!