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?
COVID-19: Latest Security News & Commentary
Dark Reading Staff 6/1/2020
Stay-at-Home Orders Coincide With Massive DNS Surge
Robert Lemos, Contributing Writer,  5/27/2020
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Current Issue
How Cybersecurity Incident Response Programs Work (and Why Some Don't)
This Tech Digest takes a look at the vital role cybersecurity incident response (IR) plays in managing cyber-risk within organizations. Download the Tech Digest today to find out how well-planned IR programs can detect intrusions, contain breaches, and help an organization restore normal operations.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2020-06-01
Python-RSA 4.0 ignores leading '\0' bytes during decryption of ciphertext. This could conceivably have a security-relevant impact, e.g., by helping an attacker to infer that an application uses Python-RSA, or if the length of accepted ciphertext affects application behavior (such as by causing exces...
PUBLISHED: 2020-06-01
modules/security/classes/general.post_filter.php/post_filter.php in the Web Application Firewall in Bitrix24 through 20.0.950 allows XSS by placing %00 before the payload.
PUBLISHED: 2020-06-01
An Insecure Temporary File vulnerability in FortiClient for Windows 6.2.1 and below may allow a local user to gain elevated privileges via exhausting the pool of temporary file names combined with a symbolic link attack.
PUBLISHED: 2020-06-01
An improper input validation in FortiAP-S/W2 6.2.0 to 6.2.2, 6.0.5 and below, FortiAP-U 6.0.1 and below CLI admin console may allow unauthorized administrators to overwrite system files via specially crafted tcpdump commands in the CLI.
PUBLISHED: 2020-06-01
In QuickBox Community Edition through 2.5.5 and Pro Edition through 2.1.8, the local www-data user has sudo privileges to execute grep as root without a password, which allows an attacker to obtain sensitive information via a grep of a /root/*.db or /etc/shadow file.