Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


10:30 AM
Connect Directly
E-Mail vvv

7 Deadly Sins Of Security Policy Change Management

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

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.

Originally a software engineer and then a product manager for security products, Nimrod (Nimmy) Reichenberg now heads global strategy for AlgoSec. Nimmy is a frequent speaker at information security events and a regular contributor to industry publications including Security ... View Full Bio

Recommended Reading:

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
Marilyn Cohodas
Marilyn Cohodas,
User Rank: Strategist
3/17/2015 | 9:05:34 AM
Confession time...
Let'ts start a thread about what's the biggest sin in your enterprise. Who wants to go first?
Inside the Ransomware Campaigns Targeting Exchange Servers
Kelly Sheridan, Staff Editor, Dark Reading,  4/2/2021
Beyond MITRE ATT&CK: The Case for a New Cyber Kill Chain
Rik Turner, Principal Analyst, Infrastructure Solutions, Omdia,  3/30/2021
Register for Dark Reading Newsletters
White Papers
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2021-04-17
A command injection vulnerability has been reported to affect QTS and QuTS hero. If exploited, this vulnerability allows attackers to execute arbitrary commands in a compromised application. We have already fixed this vulnerability in the following versions: QTS Build 20210202 and later Q...
PUBLISHED: 2021-04-17
An SQL injection vulnerability has been reported to affect QNAP NAS running Multimedia Console or the Media Streaming add-on. If exploited, the vulnerability allows remote attackers to obtain application information. QNAP has already fixed this vulnerability in the following versions of Multimedia C...
PUBLISHED: 2021-04-16
jose-node-esm-runtime is an npm package which provides a number of cryptographic functions. In versions prior to 3.11.4 the AES_CBC_HMAC_SHA2 Algorithm (A128CBC-HS256, A192CBC-HS384, A256CBC-HS512) decryption would always execute both HMAC tag verification and CBC decryption, if either failed `JWEDe...
PUBLISHED: 2021-04-16
jose-node-cjs-runtime is an npm package which provides a number of cryptographic functions. In versions prior to 3.11.4 the AES_CBC_HMAC_SHA2 Algorithm (A128CBC-HS256, A192CBC-HS384, A256CBC-HS512) decryption would always execute both HMAC tag verification and CBC decryption, if either failed `JWEDe...
PUBLISHED: 2021-04-16
Portofino is an open source web development framework. Portofino before version 5.2.1 did not properly verify the signature of JSON Web Tokens. This allows forging a valid JWT. The issue will be patched in the upcoming 5.2.1 release.