In a recent article on NETASQ, Richard Stiennon provides a “brief history of firewalls and the rise of UTM”.   I have a couple problems with his conclusions.  However, Richard does a good job describing how the firewall market has evolved over the years and gives his analysis of where it is heading.  He has had a ringside seat to this history and provides a good 15+ year history in 3 paragraphs bringing us up to today with the recent appearance of Next Generation Firewalls.

My first minor disagreement with Richard’s view and definition of a UTM.  I do agree the “bad reputation” UTM received in the early days was well received.  In my view the UTM market was created by a class of firewalls attempting to disrupt the established firewall vendors by throwing more features in the same box.  These solutions lacked effective management and did not scale to enterprise needs.  Because of this, UTM has become synonymous with “SMB firewall” in my view.  For this reason, I don’t consider a Check Point firewall with an IPS “blade” a UTM any more than I considered the Check Point firewall with VPN functionality in 1998 a UTM.  And I certainly don’t consider a Palo Alto Networks firewall a UTM.  The advancement of the NG firewalls was a new way to manage access (users and applications) not another commodity security product consolidated (crammed) onto the same box.

But that critique is pretty petty as it is just a name.  Richard’s basic history that the firewalls of today do more than the firewalls of yesterday is true.  And it is part of the reason that the demand for FireMon and firewall management solutions in general continues to increase.  New security functionality does not necessarily translate into better security.  It must be effectively managed.

Here is my major critique: the history of consolidating security functionality into the firewall is not necessarily the path of firewall innovation in the years ahead.  The market drivers of data center consolidation, virtualization and cloud computing are changing the role of the firewall.  But, unlike Richard, I don’t think this necessarily means stuffing more into the firewall.  In fact, it may mean just the opposite: purpose-built firewalls for purpose-demanding situations.

Take for example, the web-hosting DMZ infrastructure.  We wrote about this not long ago here.  A general-purpose firewall only controlling http access between users and web servers is not doing much but slowing down access and barely tapping the capability of the firewall.  However, a firewall with specific knowledge of web access embedded in a load balancer could be very interesting in this scenario (see F5′s recent announcement).

And virtualization is another fast-moving market that will stretch the bounds of firewalls.  While embedding switches in firewalls has been around for a while in UTM devices and will remain a key feature of these SMB devices, it is much more likely for security to get integrated into switches in the enterprise.  Last week, Nicira made public their recent work to manage virtual switches (great read: http://nicira.com/en/platform-for-innovation).  One advantage of creating a software abstraction layer above the physical wires is that it allow “rules” to move with the virtualized network port.  And they are certainly not alone.  Juniper has similar visions and commented on Nicira’s work here.  And Cisco has similar visions with their Nexus 1000v.

But this dynamic network of controlling access per port (and a port that moves around in the network as VM’s move) is not asking for some new type of security similar to a cramming a new feature into a UTM.  The vision of the dynamic network is demanding dynamic management of security technology we already understand: control access based on application, user, port, protocol and networks.  It is also demanding high-performance, not frequently associated with bloated UTM features.

In all cases, complexity is increasing.  Whether it is the increase in features being added to firewalls or the demand to control access at a more granular level, the complexity of the technology is increasing.  And this increase in complexity will demand new management solutions.  As great as the new technology is, unless it is properly managed, it won’t provided the intended security.

Despite being one of the older security technologies, firewalls are still the most utilized network security control in the enterprise. As Gartner noted in its last Magic Quadrant, “firewalls have long provided the most cost-effective means of protecting vulnerable PCs, servers and infrastructure from external attacks to enable secure business use of the Internet.” One of the many operational challenges in managing firewalls is that business units are constantly requesting new access through the firewall. While most security teams are quick to accommodate a business unit’s request, very rarely do these same teams audit whether a requested access is still required 6 months, a year or even 2 years after the request is processed. Many of these requests are for a temporary access that ends up remaining in the firewall policy for years.

At FireMon, we have seen customer environments where as many as 70% of the rulebase was not being used. These unused rule can significantly degrade the performance of a firewall, and can potentially introduce risk into the environment by allowing protocols or networks access into your enterprise that are not needed. As the NIST guidelines for firewall policy state “generally, firewalls should block all inbound and outbound traffic that has not been expressly permitted by the firewall policy—traffic that is not needed by the organization.” Allowing unused rules to remain in a policy goes against this central tenant and represent an open risk to the organization.

Fortunately, FireMon Security Manager makes it easy to identify unused rules within your firewall policy. Within the list of devices in the Security Manager client, a user can simply right click on any firewall device, select reports and then Unused Rules Report. The pop-up box that appears allows you to specify a date range or previous number of days to show unused rules within that time frame. Users can also select if they would like the report output to be a PDF, Web Page or XML data. Clicking Finish will produce the report, which will show unused rules for both the Security and NAT rules on the device. Security Manager also enables users to setup the Unused Rules Report to run automatically on a daily, weekly,monthly, yearly or custom time frame. This automated report can also be emailed to any number of recipients. A common best practice among many Security Manager users is to have the Unused Rules Report emailed to them the 1st of each quarter showing which rules went unused for the last 90 days, reviewing the access with the business unit that requested the rule (which is identified by Security Manager using the Policy Planner tool) and removing the rule if the business unit has no valid justification for continuing to have the rule within the policy.

By leveraging this simple but powerful report within Security Manager, security managers can ensure that their firewalls are not introducing any unnecessary risk to the organization or negatively impacting the firewalls performance by unnecessarily increasing the size of the rulebase.

FireMon announced today, what we here in the company have known for a while now, 2011 was a spectacular year for us at FireMon and we are so proud that we want you to know.  Some of the highlights of 2011 for us:

• 50% year-over-year sales growth in firewall management solutions to enterprises while continuing to achieve profitable business operations for the year.
• Dramatic new customer growth with over 80 new Fortune 1000, government, healthcare, financial services and service provider customers including enterprises like Accor, American Automobile Association, and EarthLink and MSSPs like GBprotect.
• Acquired Saperix Technologies and patented risk analysis software developed at MIT Lincoln Laboratory that quantifies risk by identifying both critical threats and the most effective countermeasures.
• Expanded international operations in EMEA and Asia-Pacific with new executives and technical resources in the United Kingdom, France, Germany and Australia.
• Increased focus on business and technology partnerships with the addition of proven security industry channel management and business development executives.

The best part of all of this great news though is that we think this really positions us to make 2012 an even better year.  We are poised to really take off as a result of additions to both our team and product line up.

As the people who virtually invented the firewall management space, we are very excited to see firewalls, through the introduction of “next gen firewalls”, become hot again. Security device management and scenario based risk management are two of the most important issues facing organizations. We are uniquely situated to offer solutions and answers to these issues.

In the meantime congratulations to everyone on the FireMon team for a job well done.  But most of all a huge thank you to our customers and partners, for without you all none of this would be possible. Thanks to all of you and here is to a great 2012!

In our first post on accurately measuring & scoring risk, we examined the holistic network approach many enterprises take around managing risk. This approach is to run vulnerability scanners against parts of their network or the network in its entirety at some predetermined interval. In both cases, scans are run, vulnerabilities are identified and possibly prioritized based on asset value, patching activities are scheduled over the next month or quarter, and the event repeats itself. As we noted, this approach over-simplifies the complex task of risk, as different threats and different assets define different risks.

The answer to this dynamic risk challenge is clear. Organizations need to operationalize risk into their daily security activities, and not make risk management simply a set event that occurs at predetermined intervals. As changes occur to the organizations risk posture based off of the business activities noted in our last post, or larger corporate events such as M&A or moving to the cloud, security organizations need to be able to dynamically and easily analyze this change to their risk posture in real time. To effectively do so, a tool that provides the ability to create different risk scenarios is required. Scenarios enable an organization to address each different threat to their assets as changes occur.

In the previous post, we provided the example of a business unit requesting VPN access to a new business partner after the predetermined scan had already been run. Leveraging a tool that provides the ability to create different risk scenarios, the security team would be able to create a new scenario to identify the new connectivity from the business partner into their network. To truly be effective, the tool would not only need to be able to identify this new connection, but have the contextual awareness of the firewall policy, network topology and any other network security devices that might be traversed between the front and back end systems involved in this new connectivity to accurately identify any potential vulnerabilities that are introduced from this new partnership.

FireMon Risk Analyzer is just that tool. Risk Analyzer enables administrators to create different scenarios: VPN connectivity to new business partners, connectivity to a cloud provider, a new data center coming online. Combined with Risk Analyzer’s full network topology and security policy awareness (which can be continually updated in real time via FireMon Security Manager), end users are able to identify new risk scenarios, proactively identify the new risk introduced from the scenario, and virtually apply remediation to ensure that the most effective remediation is completed with the least amount of effort. Multiple scenarios can be created as different threats or business events are identified, and as changes occur to the configuration or connectivity within the scenarios, end users can easily and immediately re-run the scenario within Risk Analyzer to asses how these changes affect the true risk posture of the organization. Risk Scenarios enable organizations to achieve the goal of operationalizing risk into their everyday activity.

Today at the Juniper Networks Global Partner Conference, FireMon was honored to be invited to participate in the keynote address. FireMon’s President & CTO, Jody Brazil, joined Juniper’s CEO Kevin Johnson to demonstrate FireMon Risk Analyzer running on Junos Space. We at FireMon are thrilled to be partnering so closely with Juniper. The Space platform represents a significant development in terms of network programability and extensibility. FireMon Risk Analyzer leverages the rich real time configuration data provided by Junos Space to maintain the most accurate and update network topology within Risk Analyzer. FireMon also announced that while the current release of Risk Analyzer supports hooks into space, the release of Junos Space 12.1 would see the release of Risk Analyzer running natively within Junos Space. FireMon and Juniper will continue to work closely together to create the most accurate and real time risk analysis and remediation tool for Juniper environments, with many more exciting developments to come throughout the year.

The most recent post on our blog noted that understanding your organization’s exposure to risk is no small task. I have seen enterprises attempt to manage risk through feel or intuition, or simply reacting when executive leadership has read about the latest breach of the week and wants assurance that they aren’t at risk for the same calamity.  Fortunately, enterprises today are attempting to analyze and measure risk under a more formal process. Many attempt to do so by running vulnerability scanners against parts of their network or the network in its entirety at some predetermined interval. In both cases, scans are run, vulnerabilities are identified and possibly prioritized based on asset value, patching activities are scheduled over the next month or quarter, and the event repeats itself. Some organizations might even take the results of these efforts and assign a score, value or state to their risk posture.

Image via Wikipedia

The holistic measurement of risk described above simplifies risk within today’s networks. Truly understanding your actual risk posture is much more complex. Different threats and different assets define different risks. Risk is also constantly changing, constantly in flux in the enterprise environments we work in today. With M&A activity, strategic partnerships being formed or abandoned, new data centers being brought up, data centers being consolidated or IT functions being moved into the cloud, risk is a never ending moving target in most enterprise environments. Considering the standard process where an organization runs a vulnerability scanner at set intervals and scores their risk posture based off the actions completed from this event, it’s easy to see how this score is not truly reflective of the true state of the organizations risk.

Consider the example where a security group may run an enterprise scan at the beginning of each month and then schedule remediation actions for the next three weeks. In the second week of the month, a business group requests a new VPN connection to a newly formed business partner. This access requires connectivity from the new partner network to a DMZ web server farm that is protected by a firewall cluster. The web farm is a front end to an internal financial database that is protected by another cluster of firewalls. The monthly process that the organization follows does not allow them to react to the new variable that has been created within their risk posture. Furthermore, even if the organization were to scan against this newly created connection, the scanner would simply be blocked by the firewall clusters. The scanner does not have awareness of the firewall configuration policy and the context of how data flows through the networking devices, firewall and any other subsequent network security controls related to the web server front end and the back end database servers. This speaks to the importance of factoring the full context of network security controls and data connectivity when analyzing risk, as we have previously covered in this blog.

Analyzing and scoring risk based solely off the enterprise wide scanning or patching efforts doesn’t provide an organization the most accurate measurement of what their true risk posture is. In the second part of our post, we will discuss a better approach to gain a more accurate and real-time awareness into what an organizations risk state truly is.

Adam Ely wrote a nice article on Dark Reading (“Tech Insight: What to Do When Your Business Partner Is Breached”) about how to respond when you become aware of a breach of a business partner.  He discusses a very broad array of activities and responses you should consider immediately, on-going and post a breach.

One thing that jumped out at me was the brief mention of understanding your organization’s exposure.   Adam wrote,

“As you’re starting to piece together what occurred, it’s time to understand your organization’s exposure. You’ll need to fully understand what service the partner provides to your organization, the data it possesses, and how you are connected to each other. A breach of a third-party email provider has a different impact than breach of a two-factor authentication vendor. Understanding the total exposure will help you define the risk associated with the breach, the actions you must take, and how fast you must move.”

“Understand your organization’s exposure” is no small task.  In some cases, its too late to mitigate, in others, it could be a massive exposure waiting to be exploited.  For example, if the business partner provides a billing service for you, all the records they posses about your customers may already be exposed.  In another case of an application development provider, they may have connected access to critical assets in your organization that are now exposed to a new threat. In all cases, it is important to understand how you are connected to each other to monitor and mitigate any further proliferation of the breach.

Understanding the risk from a business partner whose “threat” value must now be seen as heightened post-breach, can be a very big project.  Sadly, in many enterprises, even the layer 3 network diagram is not up to date to provide an accurate picture of partner connections, let alone a complete picture of access.  And, as Adam points out, time is not on our side in this instance.  Quick and effective response to this new threat is critical to limiting the propagation and impact from a partner breach.  Understanding “exposure” from this threat is the key to this response.

Risk Analyzer is designed for just this purpose.  With a threat in mind, understand the exposure of your network from this threat.  Remediation activities like prioritizing vulnerability fixes, mitigation activities like blocking access to some connectivity until resolution is achieved and limiting impacts by actively monitoring (perhaps network recording) all access from the breached partner are all good responses if you understand your exposure.  Getting a clear picture of what is exposed is still the first step.

Adam continues to discuss much more than just the technical next steps, including contract negotiation and breach disclosure steps.  But heeding his advice to understand your exposure and act fast to limit the impacts are key in handling this situation.

Vulnerability…”I do not think it means what you think it means.”

Continuing our series of posts on Risk, I wanted to next shine a light on one of the most misunderstood or better yet, misused terms in security, vulnerability.  What does vulnerability mean to you? How is it connected to Risk?

While vulnerability is certainly part of any risk analysis the term has been co-opted out of all proportion to most of the security and risk management space. This is partly due to the great job that the vulnerability management and patch management vendors have done in bringing vulnerabilities to the forefront of our risk management activities. But as we said in our earlier post, there is more to Risk than vulnerability.

Rather than reinvent the wheel I wanted to go back to what many consider a seminal piece on the subject. Jack Jones’s, An Introduction to Factor Analysis of Information Risk (FAIR). Jones perhaps said it best when he wrote,

A final point is that there’s a tendency to equate vulnerability with risk.  We see a frayed rope (or a server that isn’t properly configured) and automatically conclude that the risk is high.  Is there a correlation between vulnerability and risk? Yes.  Is the correlation linear?  No, because vulnerability is only one component of risk.  Threat event frequency and loss magnitude also are key parts of the risk equation.

So, in spite of this, why have so many gone off the deep end on vulnerabilities? I imagine it is due to highly publicized and severe vulnerabilities that keep being disclosed on a frequent and regular basis along with the fact that it is the best “measured” factor in security today (see CVSS).  Using a baseball analogy from Moneyball, measuring vulnerabilities to infer risk out of context from threats, other security countermeasures, and other risk factors is similar to tracking the stat “at bats” as a key metric to measure wins.  Related, yes.  Direct correlation, no. Just because there is a vulnerability doesn’t mean it will be exploited, that it can be reached and it is worth exploiting. So in measuring risk, it is critical to measure more than just vulnerabilities.

I am not suggesting we stop assessing and measuring vulnerabilities.  However, with risk based products like our Risk Analyzer, I hope we start including some of the other factors that need to be included in our analysis so that we can start measuring risk more completely.

Vulnerability is not Risk.  Inconceivable!

In our previous posts in the series on Risk (“Why Risk” and “Risk is the Yardstick”) we have spoken about why risk matters.   We have looked at risk in the context of information technology and we have looked at risk as the yardstick to measure the state of an organizations security.  Which begs the question: If Risk is the yardstick to measure the state of our security, how do we measure it?

As stated in the previous posts on risk, for too many organizations risk has been tied to a vulnerability and patch management program.  Vulnerabilities are a piece of the puzzle and both regular vulnerability scanning and a mature patch management system are  important, there is much more to managing risk effectively. Other factors need to be figured into the analysis.  Some of these factors are:

1. Vulnerability – This is perhaps the most confusing term used in reference to Risk due to years of inconsistent usage in the industry (more on this in an up-coming post).  For the purpose of this post, we will consider a vulnerability an exploitable weakness in an asset.
2. Reachability - By reachability we refer to the ability of a threat to access (reach) a known weakness (or vulnerability).   Put simply, “Can an attacker reach the vulnerable asset to exploit it?”  This may entail an analysis of how a known vulnerable asset can be reached. What path would be taken to reach the asset?  It can also include scenarios where multiple vulnerabilities, assets and exploits are used in concert to reach a higher value asset. An example would be attacking a low value asset to reach another higher value asset.  Many of the existing security technologies including firewalls, IDP, proxies, content filters and more are implemented specifically to prevent Reachability from a threat to an asset.  Taking existing technologies into account is critical when trying to measure the effectiveness of the security efforts.
3.  Asset Value – To measure an “amount” of risk, you must measure the impact of the loss.  In IT terms, it is common to refer to the value of the asset.  This could be the physical value, an opportunity-loss value, the value of the data stored on the system, or the loss value if customer data were stolen. This is big topic, but it is critical to understand that is part of risk measurement calculation.
4. Threats – Where the threat originates, the motivation of the threat and the capability of the threat are all factors that affect the risk to an asset.

Of course there is more to measuring risk then these few paragraphs, but hopefully this will give you some insight into the factors that must be figured into measuring risk.

The end of the year is always a crazy time at FireMon and likely most companies.  We are busy wrapping up end of year business while making plans for next year.  Even with all the activity, I can’t help looking back at the year that was.  And what a year it was!

It seems like many years have passed since February when we changed our name from Secure Passage to FireMon.  Since then we acquired a powerful Risk Analysis technology, doubled the number of employees, opened offices in London, France, Germany and soon Australia and released Risk Analyzer.  And once again we have set a new company record for anual sales.  It has been a great year!

Thank you to all our customers and to all the great people at FireMon that make it happen.  It is great to work with such talented and quality people.  I look forward to seeing everyone next year!

Happy New Year!  2012 is going to be fantastic!