Security Policy Management Maturity Model and the Benefits from Moving Up the Ladder: Part 2 of 4

In my previous post on the security policy management maturity model, we examined level 1, or the Initial level, which means you’re either not managing security policies at all or are at an extremely basic level that is fully manual. If you took some of the tips to heart regarding policy analysis automation, then you may now be at Level 2, or what we refer to as an Emerging organization.

If your organization has reached this level, you have addressed the lack of security policy visibility by automating policy analysis and tracking changes across all of the devices in the network and/or data center. However while you have made significant improvements, your automation efforts are still mostly tactical and are limited to point-in-time efforts such as audits or cleanup projects. As an emerging organization, you have yet to automate security change management and you cannot ensure continuous compliance. Below are the detailed characteristics of organizations at this level of the maturity model.

• Congratulations! You now can automatically monitor and alert stakeholders of policy changes:
  Visibility improvements from the Initial level are dramatic, with automated tracking and notifications when rules are changed, which is helpful for audits and for identifying the origin when troubleshooting connectivity or risk issues.
• Simpler IT audits, but you only have point-in-time compliance:
  You now can automatically generate reports that demonstrate compliance with a myriad of regulations, standards and/or corporate policies, instead of conducting manual audits that can take weeks for just one firewall. While audits are faster and more accurate, your organization will typically fall out of compliance in between audits due to frequent changes.
• A more optimized and tighter security policy:
  Unused rules and objects, covered, duplicate, expired rules and much more can be quickly discovered. Rules may also be reordered for optimal performance. Risk and severity in the firewall policy is now understood, with the ability to identify overly broad rules where “ANY” is in the SRC, DEST, SERVICE, APP or USER fields and tighten those rules without impacting business requirements. This gets your rulebase cleaned up and tightened at a point-in-time, but again, security changes make this irrelevant in the future.
• Change happens and you’re still not there in terms of automation and accuracy:
  There may be process review and improvements underway, but still little to no process automation or firewall-aware intelligence that can significantly improve the speed and accuracy of making changes. Many changes need to be redone and out-of-process changes are performed, which lead to trouble – 76% of respondents in the State of Network Security 2013 survey reported that out-of-process changes resulted in application and/or network outages. Additionally, your security teams don’t know if changes are executed in accordance with the defined security policy.
• Lack of understanding of business impact from security changes:
  In a recent survey on Examining the Impact of Security Management on the Business, the majority of IT professionals (53%) report that they have limited visibility into the impact that network security changes have on critical business applications. Oftentimes the result is an outage to a critical application or possibly the network as two-thirds have suffered unexpected outages or disruptions during data center application migrations to public, private or hybrid clouds.

Wanna keep moving up the ladder? Here are 5 tips for doing just that:

1. Make sure your security and network teams are aligned and agree on change management processes. From there you obviously need a way to enforce this process.
2. Integrate risk and compliance analysis to the change process BEFORE making the change – this is key because changes oftentimes take you from a secure and compliant policy and infrastructure to an insecure and non-compliant one.
3. Measure the time required for each step of a change request to identify bottle necks.
4. Conduct reconciliation between requests and actual changes made to identify out-of-process changes.
5. Assess the value of automation as part of a firewall and network aware change process.

In our next blog, we’ll move on to the Advanced Level.