‘Have IT Your Way’: making network security change processes similar to ordering a burger

Burger King may have updated its slogan from ‘Have It Your Way’ to a more lifestyle-friendly ‘Be Your Way’, but the underlying message still stands. Order a burger, and they will deliver it exactly as you want it – while still following a standard, automated, quality and highly efficient process.

In my mind, these two elements – the custom order and the automated process – should also underpin the process of provisioning application connectivity and network security. By modeling the process for making changes to network access on the automated process used by fast food restaurants to deliver your burgers, your organization will benefit from greater efficiency, fewer errors and outages, and an improved relationship between the security, network and application delivery teams.

Food for thought

Today, most security teams follow a similar process when the application delivery team requests a change. First they note the application delivery team’s request. Then they determine which devices are in the path of the change, and then identify the security rules that need altering in order to support the change. And finally they make the necessary changes.  This is just like ordering your favorite meal combo, #3, from Burger King.

Sounds pretty straightforward? In practice it usually isn’t. For starters the application delivery guys’ talk in their own application-centric language like .net, java, app and database servers while the security guys understand security ‘speak’ – IP addresses, ports and protocols. As a result, application delivery requests often get ‘lost in translation’.

Second, most enterprise customers have thousands of firewall rules in place on their corporate networks (recently, a prospect told me that they had over two million rules!), making it difficult for the security team to wade through and figure out what to change and how, when implementing a request from the application delivery team.

Third, making changes is risky – a change can inadvertently cause an outage, create a security hole, or a compliance violation. You need to assess the impact of a change before you make it.

So let’s see how a ‘fast food’ model for handing an application connectivity change can help.

Choosing from the menu

First, you go into the restaurant and chose what you want from the menu. I’ll have a number 3, with Coke, large fries and extra sauce on the burger, please. The cashier then keys your order into the cash register, which then ‘translates’ it into a work order for the kitchen staff.  The same principle should apply when the application delivery team requests a change: the application delivery team makes a request for connectivity between application X and database server Y using MS SQL, which is keyed into the security policy management solution. The security policy management solution then automatically translates it into the right terms for the networking team (i.e. source, destination and service). 

Assessing the risk

Then, the cashier takes your credit card and swipes it. In a fraction of a second, the restaurant verifies that it has all the ingredients to provide you with the meal you’re purchasing, while your bank assures the restaurant that you can pay for it – so there is no risk involved in the transaction. All this happens automatically, and quickly so that you don’t hold up the next customer waiting in line.

For the IT security team, this is the equivalent of assessing the risk of a proposed rule change. Will it allow risky traffic, create a security hole, violate PCI requirements? If so, the request must be altered. If not, it can be approved for implementation. The security policy management solution should have the visibility and ability to automatically assess the impact and risk of every change before it is implemented.

Preparing your Meal

The next stage in the process is to prepare and assemble your meal.

For the IT security team this means creating an efficient workflow that properly handles the process of making the change. The first, “preparation” step is to identify all the ‘ingredients’ – the firewall and router devices in the path that require a security policy change to satisfy the application change request. This is no easy feat, even for small and medium networks, let alone Fortune 500 customers, and it can take many hours to complete manually. However a security policy management solution will do this automatically. Once the devices have been identified, we can then start to “assemble” the meal. This means identifying which rules need to be added, or how they need to be modified, and where they should be inserted, and then automatically implementing the changes onto the relevant devices.  Again, since most large organizations have thousands of firewall rules this process can be an extremely time consuming and complex – unless you use a security policy management solution, such as AlgoSec’s, to do this for you automatically.

The final check

At the end of the process your food is bagged and the cashier does a final check to make sure your order is right. Extra sauce? Check. Coca Cola? Check. Large Fries? Check.

Again, this final verification check should be performed automatically by the security policy management solution to ensure that everything the original stakeholders’ requested has been implemented correctly and completely.  This means that no unexpected outcomes have jeopardized the business’s security posture like adding “any” service vs the original “MS SQL” request which would allow application X to access the database server Y with all protocols. This would be a huge security risk!

Having it your way

By using a security policy automation solution, organizations can remedy many of the pain points that exist between application, network and security teams, to transform security policy change management into a streamlined process that resembles the production line at fast food restaurant, enabling everyone to have it their way, while transforming the business to become more competitive.