“The United States can pay any debt it has because we can always print money to do that. So there is zero probability of default.” – Alan Greenspan
There is a well-understood concept in our industry (coined by Ward Cunningham) called technology debt. Said simply, it is the idea that technology is placed into the market in an incomplete—albeit functional—state and engineering development teams will, over time, get around to correcting the issues through software or firmware updates before the product becomes instable or unusable. It’s not unlike finance: as long as debt can be serviced (interest paid), the enterprise remains solvent.
Debt, itself, is not necessarily a bad thing. But, what happens when debt accelerates out of control? Imagine this debt was your security policy (how you express the rules than manage security in your enterprise). We have hit an inflection point in the industry where the amount of security policy debt—i.e., the expression of security enforcement actions such as firewall rules and IDS signatures—has most enterprises wondering if they can continue to service the debt (keep adding and subtracting) or if the organization will grind to a complete halt.
In today’s hyper-charged cyber environment, a reckoning has arrived. Is adding additional security policy to the data center making us more or less vulnerable? Is our infrastructure and network security so complex, so brittle that we are both less secure and hamstrung from moving quickly?
Like other forms of technical debt, security debt must be paid down. A change to a firewall rule has implications for the underlying network (VLANs, zones, subnets, ACLs), technologies that are fragile, inter-connected, and require considerable rework. To illustrate, consider a typical 4-tier application: load balancer, web servers, application servers, and database servers.
From a network segmentation and security perspective, you would need:
• 4 VLANs to separate the tiers
• 4 security zones
• 4 different changes to the firewall rules
• 4 new subnets.
That is sixteen security-related changes to segment that one application. To segment 10 applications, you need 160 security-related changes. And still, you get NO isolation with the VLAN.
I recently met with the IT leadership of a large corporation who explained they had millions of firewall rules. Can you imagine the security policy debt they carry?
To reduce security policy debt, IT teams must take the following steps:
– Look for software that automates and simplifies manual policy management. At scale, the problem is beyond what the human mind can solve in most organizations.
– Look for opportunities to retire old policies. Perhaps there could be a trade-in approach where every new security policy requires teams to retire 2 old ones.
– Adopt whitelisting and targeted solutions. Advances in InfoSec technologies make it possible to embrace whitelist models, which lowers the overhead and speed to deploying new applications. Moreover, when considering application security for compliance, for example, it is important to focus on the specific types of vulnerabilities and attacks and not the omnibus approach of traditional IDS systems (20,000 Snort signatures).
– Push on organizational silos. Security policy debt can begin to accrue at the beginning of the application life cycle. Creating hard lines among DevOps, infrastructure, and security teams, can force security teams to “add” security afterwards.
– Create dynamic controls. Intelligent software systems can remediate or quarantine vulnerabilities or breaches faster than people, especially in highly complex environments.
Ultimately the reduction of security policy debt leads to a more agile and secure enterprise.
Related Reading: The Technical Debt Bubble and Its Effect on IT Security
