7 Deadly Sins Of Security Policy Change Management

It’s no surprise to security pros that managing the ever-growing world of network security policies is becoming more and more demanding. As we've seen with the recent data breaches at Anthem and Sony, we are facing more threats, greater complexity, and increased demand for both security and application connectivity.

While shiny new technologies that claim to fight and block the latest threats are popping up like mushrooms after the rain, many companies are failing to update their approach to security policy management in order to keep up with growing business and security challenges. They are guilty of what I call the “Seven Deadly Sins” of security policy change management.

Sin 1: Focusing on the “plumbing” instead of on the business applications. Often, when we think about network security, we are quick to adopt a network-centric (IP addresses, ports, protocols, VPN tunnels) instead of an application-centric approach. We look at the path, rather than the purpose. Documentation often focuses on the plumbing level, too, and frequently the reason why network access was granted appears as an afterthought in the comments field or on an auxiliary spreadsheet—or it may not be noted at all. Only at a later stage do we think about what should in fact be the most important question: why is this rule actually in place? What business application is it supporting?

Sin 2: Not removing firewall rules for decommissioned applications. When we deploy an application, we create rules and define access rights. When we decommission an application, though, the reverse seldom happens. Unrequired access is often kept in place because we fear that removing it from the network could break something else. While that may seem to fall into the “if it ain’t broke, don’t fix it” category, the opposite is actually true. Open access that is not required for any business purpose piles up and creates unnecessary clutter, making an attacker’s life a lot easier, and your audit preparation team’s life a lot harder.

Sin 3: Tolerating, or worse, encouraging ineffective communication. Maintaining a large IT infrastructure requires multiple teams: a security team to define and enforce policies, an operations team to make sure that the network is available and operates properly, and an applications team to support the business applications. Typically these teams care very little about each other. They speak very different languages and do a terrible job of communicating with each other. There are a lot of reasons for this: different reporting structures, cultural differences, and different goals. That makes it hard for one team to see the network and its challenges the same way as another, which introduces mistakes and makes for lengthy lead times for processing changes.

Sin 4: Failing to document enough (or at all)! Let’s face it, documenting is probably the least enjoyable part of IT work for most people, but it is critical. If a rule isn’t documented, we won’t know (or won’t remember) why it’s in place. And, if we don’t know why it’s there to begin with, it will be a challenge to know how to manage changes that affect it. In addition, poor documentation makes for very awkward audits. You can’t say to an auditor ... “well Bob wrote it, and he left two years ago.” You must to be able to answer with certainty when asked why a rule exists. Trying to figure it out months or years after implementation with someone looking over your shoulder is even less fun that documenting it initially.

Sin 5: Not recycling existing firewall rules and objects. This happens all the time. One person calls all the database farm IP addresses “DB_srv.” A few weeks later, someone else creates “dbserver” for the same addresses and, a couple of months after that, someone creates “databasesrv” for the same purpose. Not only does all that duplication create clutter, it confuses the heck out of your teammates who may try to figure out why all three were needed and what differences exist between them.

Sin 6: Permitting “cowboy” changes. Every organization has “cowboys.” You know, those administrators who fire up the firewall console and make a change, completely out of process, and without the required approvals. While this may be done with the best intentions (e.g. an ad-hoc change that needs to be performed quickly) it can have disastrous repercussions. (There is a reason why a process was put in place.) According to AlgoSec’s 2014 State of Network Security Survey, 82% of organizations suffered an application or network outage as a result of an out-of-process security change.

Sin 7: Making manual “fat finger” input mistakes. To err is human but to forgive is not in the nature of IT systems. So if you’re manually coding or processing changes, you run the risk of making mistakes that could leave you vulnerable to attacks or outages. An administrator in one company that we worked with accidently typed port 433 instead of port 443 when making a firewall rule change. Let’s just say it was not a good day for him. Without a way to catch errors or automate processes, you run the risk of introducing mistakes and wasting time on activities that could be quickly done by software.

Mitigating these deadly sins requires process, visibility, and automation. But It’s an effort that will improve both security and business agility.