Dan's Take

The 7 Deadly Sins of Security Policy Change Management

Committing one or more of them could significantly damage your IT environment.

• By Dan Kusnetzky
• 03/27/2015

Nimmy Reichenberg, VP of Marketing and Strategy for AlgoSec, recently stopped by to discuss what he calls the "seven deadly sins of security policy change management." While at first I thought  this was going to be a catchphrase-heavy, useful-insight-light discussion, I was wrong. Reichenberg offers a number of thoughtful points worth considering.

Here's a quick review of what Reichenberg describes as the "Seven Deadly Sins."

1. Focusing on the "plumbing" instead of on the business applications
2. Not removing firewall rules for decommissioned applications
3. Tolerating or encouraging ineffective communication between teams
4. Failing to document enough (or at all!)
5. Not recycling existing firewall rules and objects
6. Permitting "cowboy" changes
7. Making manual "fat finger" input mistakes

Dan's Take: Time for a Reality Check
If we take a moment to consider the logic behind Reichenberg's simple statements, we see what can be seen as the IT operational reality behind today's complex computing environments, and even further, into the complex business environments behind them.

Focus on the Plumbing
A focus on plumbing, i.e. adopting a network-centric view, is often easier than really understanding the IT workloads supporting an enterprise. Rather than taking the time to understand what each and every business unit, department or workgroup is actually doing, their business requirements and how critical the data they're managing is, it's simply quicker and easier to just look at the wiring in the wall.

AlgoSec believes that a focus on getting to know the real business requirements and how they've been addressed using IT services is critical to the overall security posture of an enterprise.

The IT Dance Around the Firewall
An enterprise's firewall can be a very useful tool to make sure that only authorized access is made to its applications and data. Problems arise when a complex application is changed or totally turned off, and the access rules and policies enforced by the firewall aren't changed as well. The network operations staff may not have been informed of the change, and therefore didn't modify the policies. It's also quite possible that the operations staff was too busy fighting other fires to address what might be thought of as a non-problem.

If the changes weren't made, the enterprise is left with holes in its security and an overly complex environment that's more difficult to manage. Once again, it appears that having a set of policies and processes in place could prevent this from happening.

The Enterprise Tower of Babel
Enterprises often segment their business operations into business units or departments with the goal of more tightly focusing on the business requirements of each portion of the business. This can be a more efficient way to deploy internal resources to maximize revenues while minimizing duplicated functions and, thus, higher cost structures. But this approach often creates silos of information, expertise and, in AlgoSec's view, a big opportunity for security problems.

Since the enterprise often has a single shared network, it would be wise for the networking and security staff be aware of what the other is doing, including future plans, so each can quickly address changes.

Failing to Document is Documenting the Enterprise's Failure
We all know that developers and operations staff would rather be doing their jobs and addressing day-to-day challenges than writing easy-to-understand and use documentation that clearly describes what's what and who's who. While they all know the value of being able to look up how things were done in a wiki or book of documentation, they're seldom incentivized by management to create these valuable repositories of enterprise experience, knowledge, and -- one would hope -- wisdom. I remember having to go through a spaghetti code set of COBOL, Fortran and RPG programs that made up a working system while I was working as a programmer analyst at a hospital early in my career. What should have been an easily accomplished task turned into months of work.

In the end, I chose to re-write pieces of the code rather than trying to figure out how the previous, and long gone, developer had done her job. It's easy to understand why AlgoSec included this on this list of sins.

Rationalizing Rirewall Rules and Objects
This clearly is related to the documentation and collaboration problems. In this case, developers or network administrators found it simpler to create a new policy or new network object rather than looking up what had been done before.

While working as a software consultant for Digital Equipment, I once had to help a client that had more than 10 different names for the same database server. Each of the names was used in a different part of the organization to describe how to access the same database. Can you say "opportunity for disaster?" I knew you could.

Getting to the point
AlgoSec has put its finger on several challenges that are straightforward to address if all business units and departments of the enterprise communicated with one another; followed the same processes; took the time to document what they're doing; and made it a point to check and recheck changes before they were committed and pressed into service in a production system.

The company has developed technology designed to address these challenges and put them to rest -- for now. Unfortunately, in a world focused on endless cycles of cost and staff reduction, some of these simple changes are never completed.