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.

Operations

3/16/2015
10:30 AM
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
100%
0%

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
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Marilyn Cohodas
50%
50%
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?
44% of Security Threats Start in the Cloud
Kelly Sheridan, Staff Editor, Dark Reading,  2/19/2020
Zero-Factor Authentication: Owning Our Data
Nick Selby, Chief Security Officer at Paxos Trust Company,  2/19/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
6 Emerging Cyber Threats That Enterprises Face in 2020
This Tech Digest gives an in-depth look at six emerging cyber threats that enterprises could face in 2020. Download your copy today!
Flash Poll
How Enterprises Are Developing and Maintaining Secure Applications
How Enterprises Are Developing and Maintaining Secure Applications
The concept of application security is well known, but application security testing and remediation processes remain unbalanced. Most organizations are confident in their approach to AppSec, although others seem to have no approach at all. Read this report to find out more.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-8818
PUBLISHED: 2020-02-25
An issue was discovered in the CardGate Payments plugin through 2.0.30 for Magento 2. Lack of origin authentication in the IPN callback processing function in Controller/Payment/Callback.php allows an attacker to remotely replace critical plugin settings (merchant ID, secret key, etc.) and therefore...
CVE-2020-8819
PUBLISHED: 2020-02-25
An issue was discovered in the CardGate Payments plugin through 3.1.15 for WooCommerce. Lack of origin authentication in the IPN callback processing function in cardgate/cardgate.php allows an attacker to remotely replace critical plugin settings (merchant ID, secret key, etc.) and therefore bypass ...
CVE-2020-9385
PUBLISHED: 2020-02-25
A NULL Pointer Dereference exists in libzint in Zint 2.7.1 because multiple + characters are mishandled in add_on in upcean.c, when called from eanx in upcean.c during EAN barcode generation.
CVE-2020-9382
PUBLISHED: 2020-02-24
An issue was discovered in the Widgets extension through 1.4.0 for MediaWiki. Improper title sanitization allowed for the execution of any wiki page as a widget (as defined by this extension) via MediaWiki's } parser function.
CVE-2020-1938
PUBLISHED: 2020-02-24
When using the Apache JServ Protocol (AJP), care must be taken when trusting incoming connections to Apache Tomcat. Tomcat treats AJP connections as having higher trust than, for example, a similar HTTP connection. If such connections are available to an attacker, they can be exploited in ways that ...