Security and Network Topology

PETER WELCHER | Solutions Architect 

This post was triggered by a Cisco product blog: “When it Comes to Compliance Requirements – Topology Matters!”  

This blog looks at Cisco products and then considers what an extreme version of that might look like, providing an alternative examination of security requirements and the topics in the previous blog from a different angle.  

Cisco and Topology 

The Cisco blog starts by noting what we have all noticed about the world of Zero Trust: putting software agents on end systems (à la Illumio or Elisity) directly secures endpoints. However, that does not address all security/endpoint use cases.  

In particular, end systems cannot use the agent (vendors, contractors, OT/IOT devices, mainframes, cloud, some or most VMs/servers/apps). Hence, agentless enforcement points, AEPs, more commonly called firewalls, are deployed. 

Cisco Secure Workload (“CSW”) uses topology agnostic “Scopes” to define application groupings and parts of the network topology. They fit into a scope hierarchy, and you map firewalls to workload scopes (or vice versa).  

If it helps: CSW is the product formerly known as Tetration.  

We assume you have defined a security policy in Secure Workload. Once you’ve defined the topology (“Topology Awareness”), Secure Workload pushes only the relevant policy to the Secure Firewall Management Center (FMC) and out to each firewall in parallel.  

For example, in the datacenter, you might have common/shared services, production, and non-prod, each with different firewalls controlling access. In such a design, the Prod firewall does not need rules involving destinations outside Prod.  

The point of all this is to align your firewall rules with your policy, and to only push relevant, necessary rules to each firewall, to optimize resources and performance.  

Some Background 

No, I haven’t used CSW. I looked hard at Tetration during its initial 1-2 years of popularity, as some of the laborious deployment aspects became visible (and Cisco started improving that aspect). At that point it apparently became much less visible as a product: many hesitated to begin the journey. Although it really is a key tool, especially with cloud and potentially rapid changes to apps.  

The problem Tetration encountered is us: most organizations have little documentation of all their apps and servers, let alone what ports and traffic flows they use. And yet, all that is needed to secure the apps! This is a cost consideration: few organizations budget for the effort required, which could consist of a couple full-time staff, but few would expend the budget to keep up with documentation on a recurring basis! 

Anecdotal evidence within BlueAlly confirms this. We have done at least one project where it took a couple of people during the span of a calendar year to get a respectable inventory of apps at one large company’s data center. (Admittedly, I’m not sure what percent of their time they spent on this task—some time was inevitably waiting for responses from application owners, etc.)   

My impression is that a lot of that time was spent identifying app owners (if they still existed) and gathering data about the apps, like server/VM IPs, ports, etc. CSW/Tetration probably could have helped with that, but it was not an option at the time.  

I want to say that gathering such data was a historical problem and is no longer an issue, but it isn’t. Gathering the necessary information is time-consuming and costly, and I would argue you do not have actual security without that. This includes change tracking as apps and app deployment evolve, e.g., parts of apps move to the cloud, with firewalls that show up as an app breaking, analysis, and then adjusting firewall rules for new ports. 

Handling data gathering with the mindset of “well, that’s what they told me (without verification) five years ago about that app” is NOT real security. It may be that nobody really owns the problem because it was not budgeted and staffed for, and the network team ended up stuck with it because … firewall rules. It takes effort and time (and mild risk of breaking the app) to remove unnecessary rules and tighten up security – none of which is in the budget.  

Anecdotal evidence says that a few organizations are NOW taking app security more seriously, backing that up with a budget.  

Going back to my historical observations, most of the use cases I have seen have long sets of firewall ACL rules, with little organization or readability. Rules are undocumented, and have no dates of creation, owner, or maintenance history associated with them. For that matter, rules relating to a given endpoint may be scattered in the ACL(s), rather than all together. Logical groupings and names rather than raw IPs may also be mostly absent.  

Rules are forever—servers and apps may be retired, but does anyone tell the firewall admin? For that matter, when new servers and apps are put into production, how well are the flows and security needs documented? Hasty afterthought, perhaps?  

Discussion 

We all probably think about application security in terms of flows. You may have noticed this from my prior blogs. The key is application flows, and where enforcement occurs in the path of each set of flows.  

CSW allows the administrator to define related groups of apps and app flows (addresses, TCP/UDP ports, etc.), and give them names and groupings meaningful to administrators and the required security. It also groups applications or app components, and then lets you describe at a high level what groups of flows are allowed to each app/app group, and what the relevant enforcement point(s) are. Which, when you think about it, is what we allegedly are doing when we write firewall rules but perhaps more structured. 

Musing on the question: “why should a human have to define the topology?” I was thinking in terms of physical connectivity. Well, determining the physical topology is an interesting (as in complicated) problem. It would entail network discovery, possibly across vendors and internal boundaries, and some intelligence about purpose. It’s hard for automation to supply the purpose part! 

Secondly, security needs to be concerned about logical relationships and boundaries. What needs to be enforced, where, who owns what, and similar questions. 

I don’t have a conclusion to this part, other than CSW appears to help deal with some of this complexity.  

What If? 

Yeah, so automatic modeling of network topology is hard. VRFs and tunnels add to that complexity.  

Suppose a program could do all that. Wouldn’t it be cool if it could also trace flows and verify that each flow passes through SOME enforcement point somewhere? To make sure we didn’t miss something? CSW might help us simplify our mental model and think through things, but how can we be SURE?  

Enlightenment! The discovery and modeling, and flow parts, are what Forward Networks does. I’m not so sure about the check every possible class of flows part, especially to identify flows that do NOT pass through an enforcement point or do pass through one but are subject to no port-specific rules, just an allow any port rule perhaps.  

Lingering questions: 

• Would this really be useful or necessary? 

• Is there a way CSW or Forward Networks could be used to do this? 

Links 

• Cisco Security blog “When it Comes to Compliance Requirements – Topology Matters!”: https://blogs.cisco.com/security/topology-matters  
• CSW: https://blogs.cisco.com/security/secure-workload-and-secure-firewall-unified-segmentation 
• CSW: https://www.cisco.com/site/us/en/products/security/secure-workload/index.html 
• Forward Networks: https://www.forwardnetworks.com  
• Forward Networks: https://gestaltit.com/tech-field-day/sulagna/finding-security-exposures-and-risks-from-network-data-with-forward-networks/  

Conclusion 

Tightening security is necessarily an ongoing task, partly because it was likely skimped or ignored for years. The ideal CMDB-like app inventory info consists of what was referenced above: a list of apps, and for each, a description of the servers, or VMs, and associated server groups the app lives on, and ports that need to be allowed for access (per app component, server, or VM). What are the ACL/security rules for the app, who built them, when, and when updated. (And who sanity-checked and then tested them: I’ve seen source/destination reversals creep in.) 

What’s on YOUR security enforcement wish list?  

How large is the gap between what you’ve got and what you ideally should have? (Granted, you may not want to be stuck with doing the monitoring and enforcement.) 

What needs to be identified to senior management as a security concern that requires budget and staffing to address? What would be the incremental improvement steps and the associated costs and timelines?  

Disclosure Statement