Last week, Tufin’s Chief Security Architect, Michael Hamelin, had an article appear online in Computer Technology Review called “Crafting a Firewall Maturity Model.”  Click here to view the article on line, and the full text is below.  Stay tuned for more from Michael!

Crafting a Firewall Management Maturity Model

by Michael Hamelin

Over the years, many have proclaimed the death of the firewall, but it has yet to happen. In fact, with the advent of next-generation firewalls and the availability of mature solutions that automate firewall management, the firewall is undergoing something of a renaissance.

If you have ever looked at a firewall rule and wondered how it got there, or have been afraid to delete or modify a firewall rule because you were concerned you might break something ,then you might want to think about elevating your organization’s firewall management efforts to a higher level.

Regardless of whether you have one or 100 firewalls, creating a repeatable, sustainable process for firewall management can bring immediate time and cost savings and improve an organization’s ability to manage its network security risk and compliance posture. The maturity model below can help. The stages are based on evaluating how almost 1,000 companies have improved firewall management within their organizations – where they started, how they moved forward, and how they measured their own improvement.

Because these stages should apply to any business of any size in any industry, there is no finite set of requirements to advance from one stage to the next. The idea is that you can use this model to help gauge where your organization sits on the firewall management maturity curve and how to move it along.

Stage One: Immature

At the lowest end of the scale are companies with no method to the madness. Changes are made as they come, and the process is mostly, if not completely, manual. For example, suppose a company pushes out seven new rules and changes to 30 objects within existing rules; mistakes could be not only explosive but also difficult and time consuming to correct. How do you know you’re in this bucket? Well, if you answer “yes” to more than three of scenarios listed below, then chances are you’re at level one and you can benefit dramatically from process improvements.

• You look up a change and have no idea why it was done or who did it.
• You look at a rule and wonder how it got there.
• Team members don’t know why rules are on the firewall.
• Everyone is afraid to make a change to anything that exists.
• Every new rule is added to the top of your rule base.
• Firewalls are slow – rule bloat causes the device to take a long time to install a policy.
• You/your team spend a lot of time making sure changes work.
• A noticeable number of changes need to be redone.
• You are afraid to acknowledge what is not being done.

Stage Two: Emerging:

Emerging companies are those that are starting to put some structure and reporting around their firewall monitoring and change management efforts. Process automation is already underway and those involved are interested in making improvements.

Instead of wondering why a change was made or what might happen if they delete or move a rule, firewall admins at emerging companies spend their time determining if a new access request should be met by changing an existing rule instead of crafting a new rule, or if changes can be grouped by service or destination.

Emerging companies are likely to be using Excel and/or Word to manage changes. With some degree of audibility, they have visibility into metrics such as how many new rules, new objects, changed rules and modified objects occur during each change window. While they have much less security and compliance exposure than immature companies, they can still benefit from additional process automation. Here are some signs you are at this stage:

• Too much time is spent looking up data in spreadsheets.
• Documentation is messy and filled with errors.
• While there is more confidence around implementing changes, there are still concerns that deleting rules will break something.
• Optimization is welcomed – it’s understood that rule bloat is simply the nature of having mature systems and it’s a good thing to start streamlining them.
• Attention is given to change management processes – since ticketing systems don’t account for the details for firewall changes, admins start to track them themselves.

Stage Three: Mature:

For the most part, mature companies have already implemented three things:

1)   An automatic system for monitoring configuration changes with accountability info. Basic items such as who made each change on every firewall and when they made it are documented and auditable. Firewall rules can be automatically analyzed for risk and compliance, and the benefits of automation are quantifiable – at least anecdotally.

2)   An optimization strategy. Teams are in maintenance mode, as opposed to undertaking a major initiative to clean out the rule bases, and have the people, process and technology resources needed to execute.

3)   Automated or semi-automated firewall change management processes. There are set change windows and an established (ideally automated) workflow process for change management that includes risk and compliance analysis for any given change request.

Firewall administrators at mature companies have made significant strides on the operations side and are focused on fine-tuning  – especially when it comes to change management. However, despite process automation, they still lack business context. There is little or no communication with the business units, which is why change management is still difficult.

Stage Four: Highly Mature:

Highly Mature organizations have successfully implemented structure around their firewall operations and change management efforts. Instead of looking at the risk stemming from a single firewall, teams are assessing the risk posed by groups of firewalls, risk per zone, etc., and spending less time per change. All the details surrounding where to place a change in the rule base are automated and executed within established change windows, and changes on a firewall are automatically reconciled with ticketing systems.

The time and motivation exists to assess change management processes for business risk.  Firewall administrators see themselves not just as engineers but also as contributors to the business. As a result, they are better equipped to respond to business changes via new compliance ands risk-related rules or processes.

For example: A business decides it is going to start processing credit cards and the firewall team should be able to understand how that will impact them. Where do they need to store the Personally Identifiable Data (PII)? How will they protect it? When should they start with quarterly PCI audits?

Other signs you have arrived at stage four:

• Firewall audits are fully automated, and no longer dreaded.
• You start hearing terms like “continuous compliance” used regularly.
• You can easily communicate about progress and improved integrity of systems.
• Because there has been positive feedback, teams are motivated to communicate improvements.

Highly mature companies understand the impact IT can have on the business. Investments in IT Security, unlike most other areas of IT, are not intended to generate revenue and, as a result, in some organizations are perceived as a financial black hole. However, firewalls are core technology, and with the advent of next-generation firewalls are just as relevant now as they were 15 years ago, if not more so.

Sometimes, good business simply involves applying common sense. In other words, why invest in a new set of less proven security technologies when you can dramatically improve the performance of and ROI on an existing investment? Investing in firewall management can deliver transformative results – especially if yours is a stage one organization — and can set the standard for how IT Security can and should function within a business context.

So why wait?

Michael Hamelin is the Chief Security Architect at Tufin Technologies (Burlington, MA). www.tufin.com

Tweet This Post

Managing access to confidential information and application resources via firewalls is the foundation of network security, and firewall audits are central to any mature network security process. However, relying on security and network experts to review rules across multiple firewall zones and different firewall products is proving to be costly and ineffective. Few will dispute that when it comes to network security, automating best practices to reduce operating costs, complexity, human error, and streamline processes is a good thing.   However, in what we call the age of Continuous Compliance – brought on by the reality that point-in-time audits done hastily to meet reporting deadlines rarely – if ever – deliver any security or compliance benefits once that point in time has passed, automation becomes more than just good.  It becomes essential.

Case in point: a November 2011 survey from Tufin of 100 firewall managers revealed that only 1.3% of configuration changes that cause network downtime or pose a security breach are identified during the quarterly audit, yet almost a third of the respondents spent 3 to 7 days per quarter of valuable network security team time on firewall audits (Disclosure: I work for Tufin). Organizations receive precious few benefits for the level of resources spent on manual firewall audits. This  is proving to be an inefficient approach to maintaining a secure network and if you do the math, an extremely inefficient use of skilled security personnel.

In general, best practices in security are mandated in standards such as the PCI DSS, DISA Information Assurance Support Environment, or healthcare’s HIPAA.   Most if not all of these regulations – and many others, either specifically mandate or implicitly require firewall audits.

The best practices of firewall audits are based on expert reviews of changes made by network and security administrators. In theory, errors are caught, corrections are made, and compliance is re-established as a result of the audit. In practice, errors are seldom caught and operational costs climb, in great part because audit teams discover security issues in firewall protection from manual audits at a very low rate.

As the discipline of IT security continues to evolve, knowing where and when to automate can make or break a CISO’s career – not to mention the morale and effectiveness of their compliance and IT operations teams. One of the important ways security teams gain efficiencies is to apply technology to evolve audit processes from disruptive quarterly or yearly events to daily standard operating procedures. The technology exists today to automatically verify compliance as firewall rules changes are implemented – ensuring continuous compliance with tight security and fewer calls to the security service desk.

The complexities of modern networks are often simply too much for a human to decipher without assistance. Not only do the best security experts have to interpret rules languages across vendors such as Check Point, Cisco, and Juniper Networks, but they must also translate application-based rules from next generation firewalls (such as those from Palo Alto, Check Point,  SonicWALL, SourceFire) to ensure compliance with security policies across the organization. The concept of independent validation of firewall configurations is a good one – the best practice is now to have a security expert craft the new rules and then automate the impact on firewalls to ensure continuous compliance.

Seeking continuous compliance via automation of firewall management has the additional benefit of preserving the valuable time of security experts. Instead of expending critical resources conducting manual reviews of firewall rules that are unlikely to result in improved security or enhancements to compliance, security teams are able to contribute to the business in more productive activities. Too much time – the 3 to 7 days per quarter mentioned in the survey builds up to more than one month per year – is spent conducting ineffective audits and producing documentation for compliance reports. As with many IT disciplines, finding ways to automate activity is the key to freeing time for skilled resources to be more effective. Automating the best practices of firewall compliance returns direct cost savings to the organization.

With automation, organizations discover dangerous configuration changes before the business is exposed to security incidents, generate compliance reports whenever required by the regulations, and shift audit approaches to expert reviews of the security strategy more than manual reviews of firewall rules.  Seeking continuous compliance moves the business closer to the goal of integrating security into business operations with fewer deviations from compliance that can put the business at risk. Spending significant security resources to find security problems only 1.3% of the time doesn’t make sense – if that is your ratio, then automating firewall management is a no brainer.

Shaul Efraim, Vice President of Marketing and Business Development

Tweet This Post

By Eric Ogren, The Ogren Group

The shift to virtualization, with most organizations virtualizing more than 30% of their applications, challenges the means by which security teams implement firewall-based foundational controls. Organizations are embracing virtualization for obvious cost savings benefits when applications share server and infrastructure resources. In fact, many enterprises continue to re-architect networks to consolidate data centers, applications and IT services. For instance, the rapid provisioning of applications – running in a matter of minutes on a virtual server for a task that would take weeks with physical architectures – necessitates a rapid evolution in the security lifecycle management of firewall rules.

Virtualization forces firewall rules to change more dynamically than ever before with applications spinning up and being decommissioned upon user demand. The firewall must now manage additional complexities in a virtual environment to quickly accommodate connectivity and access requests at the speed of business without creating security holes. Here are a few ways that firewall rules management is helping to secure virtual data centers:

• Streamline firewall rules management workflow by automating the checking of compliance rules before a manual review. Security and network teams can be overwhelmed with requests for modifications to the firewall rules sets. Firewall rules management can automatically validate that requested changes do not violate corporate security policy or compliance mandates. In some cases the manual review overhead can be eliminated with a “compliance acid test” saving time and money.
• Reduce the complexity of managing rules as firewalls are consolidated into virtualized servers. Organizations are placing multiple instances of firewalls on individual virtual servers, adding significant complexity to firewall rules management. For example, organizations deploying Check Point VSX need to deploy rules changes while evolving the virtual architecture, and must manage multiple firewall rule sets existing in a single security device. This is a new challenge for security teams – having the right tool for keeping effective firewall rules within a sophisticated device, tracking and auditing changes, and managing workflows associated with firewall lifecycles is critically important.
• Although organizations prefer to keep applications within a data center to avoid changing IP address assignments, the use of VMware vMotion across data centers and geographies – perhaps to support a mobile work force using smartphones and tablets – requires consistent firewall rules to avoid disruptions in business. Firewall lifecycle management can help security teams ensure that users can access applications, and that applications do not fall out of compliance, as capabilities such as vMotion shift applications. This capability becomes particularly important in high availability and disaster recovery scenarios.

Security is still catching up to the demands of virtualization. Firewalls are particularly vulnerable in virtual environments because the speed of change is accelerated over traditional physical architectures, leading to increased risk of business disruptions and security incidents. Enterprises embracing virtualization can save themselves a lot of pain by checking out firewall rules management products.

Tweet This Post

By Diana Kelley, Principal Analyst, Security Curve

Think about how much your organization spends annually on firewall hardware, software licenses, and management. Now think about watching all that money washing down the drain because a single poorly implemented rule circumvented all of the other firewall-based protections. Sounds a little alarming, but if you’re a firewall administrator, you know how real that possibility is.

In a previous post we took a look at “shadow rules” and why investing in automated tools that help eliminate them can be a solid business, not to mention security investment. But eliminating redundant, outdated and ineffective rules is only part of the problem.  For many firewall administrators, the bigger challenge is handling the day-to-day requests for firewall rule changes without introducing vulnerabilities or exposure points.

Firewalls aren’t static sentries that are set up once and run without change for years. Most firewalls have a fluid set of rules and are frequently updated to support new services for the business. While there’s nothing fundamentally wrong with change, how that change occurs can have significant security repercussions. When an admin is being pressured to make a change outside of the normal change management lifecycle and without proper risk analysis, problems occur.

Consider a business unit owner that is in a rush to have a couple of ports opened on the firewall so an external software development company can set up and test their application on the company servers. Chances are the business owner doesn’t know the technical reasons why these ports need to be opened or the risk associated with allowing traffic through newly opened ports, he just knows the developer said to open them.  Because the owner doesn’t understand the potential risks associated with the change, he sees the firewall rules as nothing more than an annoying and unnecessary impediment to getting his application running.

This lack of understanding about how firewalls work can lead to requests for risky rule changes. For example, sometimes the application or business owner doesn’t know which ports should be opened or which services or servers the should be opened for, so they ask for overly permissive rules with ANY that allow all traffic, good and bad, through. Some permissive requests are allowed for a short time for testing purposes and are supposed to expire after the test window. Unfortunately, setting and managing rule expiration dates on multiple firewalls and routers is no easy task. So it’s not uncommon to find permissive rules that were supposed to expire weeks or months earlier, still in effect well after the testing period is complete.

If the business unit owner works in an organization with a robust change management lifecycle, he will need to submit the change request and follow certain procedures to have the change approved and implemented. A typical change management process includes writing up the business justification for the change request, a technical assessment of direct or indirect impacts from the change, and an analysis of the risk trade-offs. For example some of the questions that may be answered during this process include:

• Will the change cause the company to be in violation of a legal or industry mandate?
• Will the change put other systems in the organization at security or business continuity risk?
• Can the business requirement be met with an alternative solution?

Following a set process, like the one outlined above, gives firewall admins time to participate in the process and perform risk analysis before a change is accepted. Unfortunately this process goes awry in two very common ways: 1) The admins are not included in the risk assessment phase or 2) they are not given enough time to complete a thorough analysis. Worst case, for the sake of speed – the change is approved without any kind of formal process and the firewall admins must implement them immediately. Arguably, one of the main reasons admins and risk analysts are “left out” of the risk assessment phase is because their analysis takes too long or their recommendations are seen as too restrictive to the business.

So how can a firewall admins speed up their decision time, provide better insight into corporate risks associated with firewall configuration changes, and get back into the assessment phase?

First, security professionals need some way to model potential changes to the network environment before implementing them. This goes well beyond firewalls because a network is comprised of multiple layers of systems and services, but firewalls are the first line of defense. Any time a change is proposed, be it a new service coming online, a change to a different database platform, or a set of firewall rules to allow for communications to and from these new services risk assessment should be completed.

Having tools to help with this kind of modeling speeds up the process and may catch things a human couldn’t on their own. Tools and techniques here include network topology and mapping, penetration testing and scanning, log analysis, and the risk consoles of IT-GRC solutions.  For firewalls specifically, administrators can use a tool that parses the existing rule set against one with the proposed change and identifies potential areas for exposure or if any of the new rules causes an inadvertent override of existing ones.

Bringing all of this information together into a single report, helps security and firewall professionals assess risks associated with proposed changes more quickly and accurately. To make this information even more valuable, translate the risk into business friendly terms before presenting them back to executives. While the statement “opening port 1025 is not advised because it’s not in official assigned use with IANA and has been associated with RPC vulns in the past” sounds like “dolphin” to most people, saying  “if we open that port, an external attacker could take control of our servers” is pretty easy for all of us to grasp.

Another way to speed up the risk assessment process, without sacrificing security, is to learn how changes impact the system over time. The first time a request is made to open a port like 1025 a long evaluation may be in order. But if the assessment has already been completed, when the second (or third, or fourth) request to open that port comes in, the response time can be reduced but re-using relevant data from the previous assessments. By keeping a record of known and fully vetted requests for future reference, efficiency and cost-reduction are realized through re-use of existing knowledge rather than by skipping the knowledge gathering step altogether.

Tweet This Post

A few weeks back I wrote an opinion piece that appeared in SC Magazine, exploring the idea of a global standard for network security.

I wanted to point to it on our blog for two reasons.  First, for space reasons, the editors cut the final third of the article, that included some tips on what people could do NOW while waiting for traction for such a standard to occur.  Second, is that the conversation was continued by Fidelis Security Systems CEO Peter George, whose initial op-ed piece got me thinking about a global standard in the first place.  Check out Peter’s response here.

Peter is right – it will take way more than security executives pontificating for such a standard to evolve. Unfortunately, it will likely take some sort of breach or similarly unpleasant qualifying event for a global standard to get the attention it deserves.  Why we need to be legislated into best practices or “doing the right thing” is a whole other issue, one that is worthy of further commentary, so stay tuned!

In the meantime, here are the tips – Hopefully you find them useful!

• Adopt and enforce regulatory compliance standards like PCI DSS, even if not bound to comply.  In addition to PCI DSS, models such as COBIT and ISO 27001/17799 provide clear and useful guidance for creating and implementing enterprise network security policies.  In instances where technical standards impact the duties of non-technical people, educate them on the reasoning behind the policy and the consequences of non-compliance.
• Run regular network security risk compliance reports - Since the network is always changing, you must be able to assess risk and vulnerability at any given time – for all relevant network security devices. Automated security risk reports instantly evaluates the current level of risk and typically displays a security score along with scoring on a prioritized list of risk factors.
• Implement the industry’s best practices for maintaining network infrastructure. These practices can help you create security policies that are secure, up to date, and easy to understand and maintain. Use solutions that allow choosing from a list of vendor and industry specific best practices and select the ones that you want to implement in your organization.  Regular auditing will give you instant visibility into your compliance level along with valuable mitigation information to help you rapidly address the issues.
• Establish and enforce organizational compliance standards. The backbone of any consistent network security policy is the establishment of an organizational standard. Most organizations have a security standard in document, or even verbal form. But to make sure that the policy is carried out and enforced on a daily basis, you need a way to define and monitor it at the level of your network infrastructure.  Implement solutions that give you a simple way to translate your organization compliance strategy into a concrete policy that you can automatically monitor. Any time a configuration change violates the organization policy, alerts should be sent out so that you can maintain continuous compliance.
• Automate wherever and whenever possible:  As the first level of defense, network security technologies are, especially compared to other areas of security, mature.  Unfortunately, sometimes the cost of maturity is that the processes that worked in the beginning no longer scale.  That can lead to operational inefficiencies, which leads to network exposure and business downtime.  Across all layers of security, some of the most useful innovation is a function of automating manual processes or processes that are impossible to do manually (think SIEM.)

Like Bruce Schneier says, Security is a process, not a product.  But there are plenty of products out there that can help you implement the processes you need to optimize the way security functions in your organization.  Use them wisely!

–Shaul

Tweet This Post