How to be a security policy management saint, not a sinner

When it comes to security, the devil truly is in the detail. Even the largest organisations with the resources to deploy the most advanced, next-generation, flux-capacitor powered products, are getting breached. Why? Because all too often, fundamentals of security policy management are neglected, meaning security processes are inefficient, which in turn leads to vulnerabilities.

So how do companies update their approaches to developing truly effective security policies, and avoid the pitfalls of placing too much faith in new products or technologies? I believe it’s important to go back to basics when devising and managing security policies. To do this, it’s useful to look at what I call the ‘Seven Deadly Sins’ of security policy change management. By understanding these sins and the actions that lead to them, they can be avoided, making the organization more secure, more agile and more responsive to change.

Focusing on plumbing instead of applications
The first sin is looking at security from a network-centric viewpoint (IP addresses, ports, protocols, VPN tunnels and so on) instead of taking an application-centric approach. Instead of looking at the purpose, the focus is on the pipework. So it’s important to invert this thinking, and ask why does this connection need to be there? Why has network access been granted, and what business application does it support?

Not removing old firewall rules for dead applications
When deploying an application, we create rules and define access rights. But those rules and rights often live on, long after the application has been decommissioned. Unrequired access is often kept in place because of the fear that removing it from the network could break something else. The old adage that “if it ain’t broke, don’t fix it” does not apply here: access that is no longer required piles up and creates unnecessary clutter, making an attacker’s life a lot easier, and your audit preparation team’s life a lot harder. So review and remove old rules that applied to old applications.

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 functions properly, and an applications team to support the business applications. Typically these teams work independently of each other: they speak very different languages and so don’t communicate very well, because they have different reporting structures and goals. This all 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. Therefore, it’s vital to bring teams together to show how their work impacts on that of other teams, and to find ways to communicate better.

Documentation drought
No-one likes doing the paperwork, but it is critical to security. If a rule isn’t documented, we won’t know (or remember) why it’s in place – and it will be a challenge to know how to manage changes that affect it. In addition, poor documentation makes for very awkward audits. Trying to work out rules months or years after implementation with an auditor looking over your shoulder is even less fun than doing the paperwork in the first place – so invest the time in documenting your rules.

Not recycling 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. This creates clutter and confusion, as other members of your IT team try to work out what each means, and how they differ. Recycling isn’t just for your home – it’s good for security rules, too.

Cowboy changes
Many organisations have ‘cowboys,’ who make changes that are out of process, and without the required approvals. While these may be done with the best intentions, such ad-hoc changes can have disastrous repercussions. 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 – so it’s vital that changes are made and noted according to the established procedures.

Fat finger 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, there’s a risk of making mistakes that could leave you vulnerable to attacks or outages. For example, an administrator in one company that we worked with accidently typed port 433, instead of port 443, when making a firewall rule change. Without a way to automate processes or catch these errors, there’s a real risk of introducing mistakes and wasting time on activities that could be done faster by policy automation software.

So with the right processes in place, and by looking at security from the perspective of the business, organisations can avoid these sins and reap the virtues of better agility, and protection for their critical assets.