Easy There Cowboy…

Many organizations have processes in place for making security policy changes. (An alarming number of companies do not, but that’s a subject for a different post.) These processes are often presumably enforced by ticketing systems such as BMC Remedy, since company policy dictates that a ticket must be opened for every security policy change request. Why presumably one might ask? Well, when you think about it, nothing really prevents a firewall administrator from making changes to the policy without opening a ticket.

I recently spoke to a security manager who used the term “Cowboy Changes” to describe such actions, and I must admit that I took instant liking to the term. Cowboy changes are seldom done with bad intentions. For example, a security administrator may need to quickly grant access to a critical application (in between a thousand other tasks on his plate) and in his eyes there is no time to wait for the full approval workflow.

But cowboy changes do not come without a cost. From a security perspective, cowboy changes may introduce risk (ad-hoc changes are often overly permissive since nobody takes the time to understand the most optimal way of adding a rule. “ANY” is guaranteed to work.) From an operational perspective, lack of documentation as to why this rule was added and who approved it makes the firewall ruleset much more difficult to manage and audit.

Organizations must therefore ensure the ability to perform reconciliation between security policy change requests and actual changes – that is ensure that each request was implemented as approved, and that each change has a request associated with it. This can be done manually, by comparing firewall logs to tickets from the change management system, or automatically, if you complement your ticketing system with solutions such as FireFlow which are designed for security change management.

And as for the cowboys, this should help them to herd those changes back into a documented system.