The First Step in Firewall Review: Automated, Intelligent Identification

How many firewall rules exist in your Enterprise? 1,000? 10,000? 100,000+? Odds are, there are many, sometimes too many to count. So, when organizations face requirements like PCI DSS 1.1.7 (requirement to review firewall and router rule sets at least every six months), many know the review is a good idea but they are overcome by the magnitude of the problem. So, they do a sampling of the access rules in good faith or get through as many rules as they can by hand, and hope the auditor doesn’t dig too deep.

Policy Optimizer solves this problem. Because it is intelligently firewall aware, routing rules in for review is as simple as a Google search. Identifying every rule with a source or destination in the PCI zone with a powerful query allows all PCI rules to be quickly and easily routed into a workflow for review.

But that example barely scratches the surface of the intelligent identification capabilities in Policy Optimizer. Every rule that has a non-encrypted protocol and hasn’t been used in the last 60 days? No problem. Every access that was requested by the web hosting team and uses a high port? Easy. Every application access that now has a brand-new zero-day? Done.

Using these powerful controls Policy Optimizer overcomes the first hurdle in reviewing access: finding a needle in a haystack. Once you can identify what needs reviewed, then the workflow takes over. I’ll talk about that in my next post.

For Security to Succeed We Need More Silo-Busting

In my role as editor-in-chief of DevOps.com I hear, read and write a lot about the need for all the various constituents of IT to work more closely together.

As such, I’m always happy to hear about a new efforts aimed at breaking down existing barriers to that end, or what I like to call “silo-busting”. So when I saw FireMon’s recent launch of its new Policy Optimizer module, and its ability to bust down silos, I’ll admit it brought a smile to my face.

blog.shimmypic.07.14

Policy Optimizer specifically breaks down existing silos across different sectors of IT in determining what firewall rules are either out of date, no longer necessary or even  security risks. Much of this silo-busting is accomplished via automation – which is added music to a DevOps advocate’s ears.

Why is all of this silo busting and automation so important? The short, real-world answer is that today’s speed of business will accept nothing less.

A more detailed answer is that in today’s world:

  • Changes – including changes to code – happen multiple times a day
  • “Web-scale IT” measures servers and instances in the tens of thousands
  • Security must keep up or be left behind, always playing catch-up
  • Automation and cooperation among Devs, Ops and QA is a necessity

And of course, breaking down silos is a key ingredient in successfully addressing these realities.

I’ve been hearing that we need security to be “built in, not bolted on” almost since I first got involved in the security industry over 15 years ago; that security needs a seat at the IT table.

Policy Optimizer is just the kind of solution that fulfills this specific need. It provides the means for security to work with the rest of the IT team in a way that makes sense and allows business to move forward with the velocity it needs.

Now before we declare “mission accomplished”, let’s not get ahead of ourselves. We still have a long way to go to better integrate security into IT and truly bust down the involved silos. We need developers to have a greater sense of ownership when developing secure applications.

Just thinking firewalls for a second, it would be great if developers gave some thought as to who, when and what types of access users will require when building an application. Giving developers a say in setting firewall rules, for instance, makes sense.

Beyond the development team, how about working closer with the Ops folks too? Who knows the network better? Far too often the Ops team resides in a different silo than security teams and they thereby seem to work at loggerheads.

Again, this is why I like tools like FireMon’s Policy Optimizer and Risk Analyzer solutions. They give Ops insight into security decisions and policies.  Ops shouldn’t feel that security and risk strategies are devised using black magic. Shining a light on why security decisions are made, giving Ops input into the process is how you get buy in, how you really break down silos; most importantly, this demonstrates how we can tangibly change our security posture for the better.

For some organizations this is still a very alien concept. Security teams are almost thought of as audit teams and are purposely set apart from the rest of IT. To me, this perpetuates a culture of failure around security. All you have to do is glance at the headlines on a regular basis to see that the old way of separate security teams is not working.

We need new, more effective solutions and these solutions must take into account new ways of business. Megatrends like Big Data, the cloud and mobility have fundamentally changed the equation for many businesses. If security is to be relevant, it must adapt and evolve.

For me, breaking down the silos around the security team sounds the death knell of standalone security teams. I look forward to the day when instead of having a standalone security team, everyone in the IT department is part of the security team.  I don’t know if that will happen in my lifetime, but every step along the way, such as Policy Optimizer, is a step in the right direction.

Now, what can we automate next?

As Editor-in-chief of DevOps.com, a regular contributor to Network World, manager of the Security Bloggers Network and Chief Executive Officer at The CISO Group, Alan Shimel is attuned to the world of technology, particularly cloud, security and open source. Prior to his current positions, Alan was the co-founder and Chief Strategy Officer at StillSecure. Shimel is an often-cited personality in the security and technology community and is a sought-after speaker at industry and government conferences and events.

Gartner Security & Risk Summit: No Farewell to Firewalls

Every so often someone suggests that network firewalls are no longer necessary – typically based on the emergence of shiny new, “gotta have it” technology or the notion that this 20+ year old first line of defense – introduced at DEC in 1992 by Marcus Ranum – no longer matters.

However, if you listen to the experts – in this case leading industry analyst firm Gartner and their 14,000-plus clients – such claims are clearly misguided.

gaylord1

At the firm’s annual Gartner Security & Risk Management Summit nearly every session reinforced that firewalls, and more effective management of these inherently complex devices, are just as critical, if not more so, than ever.

From the summit’s opening keynote, stressing the need for CSOs to tie their efforts directly to business initiatives (and bridge IT silos with offerings like FireMon’s recently launched Policy Optimizer) – to breakouts dedicated specifically to corralling firewall policy and rule bases, the importance of stout firewall defenses was emphasized… repeatedly.

Sure, there was the point-counterpoint “Farewell to Firewalls” presentation in which Gartner’s forward-looking thought leader Dr. Joseph Feiman focused on the need for new applications-centric mechanisms, specifically embedded runtime application self-protection [RASP] capabilities.

But, as artfully advanced by Gartner network security guru Greg Young during the debate, and ultimately conceded by Feiman himself, the continued development and adoption of such emerging technologies will require continued reliance on firewalls.

Longtime Gartner risk expert Neil MacDonald’s session on “Continuous Advanced Threat Protection” hammered home the need for more proactive and context-aware management of network security infrastructure; MacDonald’s “Adaptive Security Architecture” emphasized that strategy must shift from traditional “detection” and “response” methodologies to more “predictive” and “preventative” tactics.

These observations validate FireMon’s vision that adding network security intelligence to existing cyber defenses can significantly automate manual processes and free security teams for other critical projects.

For further evidence, one needed to look no further than network security analyst Adam Hils’ overview of inquiry calls made by Gartner clients during the first half of 2014.

His hard numbers: a whopping 51 percent of the over 1,500 calls taken related directly to firewalls, and were divided between “my rule base is a mess, how can I clean-up and better manage?” and “next gen firewalls – should I migrate and how?”

The second place topic – IPS issues – only accounted for 22 percent of all calls.

So, there’s hard evidence that any predictions that firewalls are either yesterday’s news or increasingly less strategic are… highly overstated; the Gartner numbers simply don’t lie.

We update Gartner analysts regularly on our customer wins, real world ROI data and technology roadmap – and listen closely to the “pain points” they hear about from clients. These analysts understand precisely how valuable FireMon solutions can be in advancing your organization’s own network security posture.

So why take our word for it? Give them a call and find out for yourself.

More Than Just Change Management

If you are like most organizations, network security has one process that is the cornerstone of its business execution: the change management process. And the change process is necessary. It ensures that we can adapt our network security posture to the needs of an evolving business, and if we can’t do that, our businesses go out of business.

If you are like a lot of people, you have a love / hate relationship with the change management process. It is good at tracking things and ensuring tasks get completed, but it adds overhead and feels restrictive at times.

However, if you are a security-minded professional, you probably have another major concern with the change management process. Because it is driven by users, 99% of the time it is used to open up access. And if gone unchecked, with no other process to counterbalance it, the change management process causes access to grow indefinitely and complexity to skyrocket.

So, what is the yin to the change management yang? Conceptually, it is most certainly tied to the review and ongoing vigilance that security experts recommend. Access that is deemed appropriate today may be risky tomorrow based on an ever-changing threat landscape. Access that has gone dormant needs to be detected and removed. Compliance regulations mandate review activities, but manual review is difficult and time-consuming, and is often just given a cursory effort.

That is where Policy Optimizer fits in. Organizations need an intelligent way to identify what access needs review and to automate the process of reviewing it. Over the coming weeks, I’ll talk a little more here about our new module and how it can help organizations with large networks better accomplish their network security goals.

Newsworthy: Spotlight on FireMon

It’s always nice when industry watchers not only notice, but dedicate some digital ink, to your company’s latest public announcements.

That was just the case this week when Network World contributor Alan Shimel wrote up a piece on FireMon’s latest news – both the launch of our Policy Optimizer product module, as well as our recent equity investment by Insight Venture Partners.

nw.logo

As noted in his post, Alan does some consulting work with FireMon from time-to-time, listening to our ideas as we get close to bringing new features or solutions to market, and offering sage advice on matters of positioning, messaging and other related matters.

At the same time, we notice a distinct and even more discerning tone to Alan’s voice whenever he’s wearing his columnist/blogger hat, as kindly (though pointedly strategic) observations morph into objective, outsider’s view questioning.

So, while Alan is a trusted advisor, it’s gratifying that he felt both news items were matters of significant note. I’d encourage you to click through and read his entire piece, but to summarize:

On Policy Optimizer: “Policy Optimizer is really an automation tool for the rat’s nest that is firewall compliance rules… This is part of a broader theme I have advocated for some time. In order for security to be more successful, we need to get more people involved in security. Security – and yes, even compliance – is part of everyone’s job responsibility.”

On the Insight investment: “Terms of the sale were not announced. But with Firemon consistently posting strong quarter-over-quarter revenue growth, you have to assume the sale was at a healthy multiple of revenues… Congrats.”

So there you have it, kudos from a trusted industry expert who already knows our company well – yet who was still moved to write about it on the record.

For all the details on our recent announcements, click here to read the official releases.

FireMon Policy Optimizer: It’s All in a Name

Whenever you set out to develop a new product, one of the trickiest aspects is selecting its name, as typically any solution offers numerous benefits; the newly introduced FireMon Policy Optimizer module is no different.

So what does Policy Optimizer do exactly? For starters, Policy Optimizer is designed for use alongside the base FireMon Security Manager solution, and greatly complements, though operates independently of, its sister modules – Policy Planner and Risk Analyzer.

firemon_prod_overview_graphic_v11

While FireMon Security Manager addresses security device rules and policy management, and the existing Policy Planner and Risk Analyzer modules address intelligent policy workflow and change, and the combination of vulnerability data with network access intelligence, respectively, Policy Optimizer was born of the need to rapidly adapt firewall settings in response to changing conditions.

For example, whenever network security must respond to an emerging threat, changes in a business partner’s risk posture, or discovery of a troublesome firewall setting, Policy Optimizer allows those teams to research the impact on any affected device policies then connect with other officials to understand how to adapt enforcement.

Like all the best solutions, the genesis of Policy Optimizer lies directly in customer need, born of countless requests from large enterprises with a wide variety of related use cases.

The value of Policy Optimizer is clearly outlined by its moniker – to allow organizations to optimize (definition: to enhance or improve) alignment of firewall and network security device infrastructure. However, as anyone who has attempted to carry out or manage this process can attest, it’s a massive task with a huge range of related factors.

However, back to the notion of multiple benefits and use cases, Policy Optimizer was also created in response to enterprises that must review firewall policy compliance frequently to remain in scope with industry standards, notably PCI DSS.

Another key motivator was the continued growth of FireMon’s managed services provider (MSP) business. These providers are constantly seeking to transfer intelligence across accounts, and Policy Optimizer allows MSPs to query against established best practices to identify policies for improvement.

This may sound like a straightforward set of drivers, but the process encompassed is complex, remaining highly manual and fragmented at many enterprises today. Traditionally, operational security management, compliance teams and MSPs have been asked to improve device policies without any direct line of communication with key stakeholders – most importantly those officials that initially requested network access.

This lack of efficient workflow results in one of the most significant gaps in enterprise security management. Access requests are typically granted to support business needs then left in place for years, without ongoing review, based on the reluctance to affect changes that may interrupt critical services.

For their part, compliance/audit teams are asked to review policies every six months under PCI, and this process is so laborious that one FireMon customer had accounted 15 staffers to the process, full-time. That’s a massive investment to address a single compliance mandate, pulling resources away from other efforts.

Throughout Policy Optimizer’s development, FireMon management considered a number of potential names, including those related to policy assessment, rules review and rules recertification, among others.

The decision to adopt “Policy Optimizer” came from conclusion that this product serves so many customer needs and has such a huge range of inherent benefits that this bold, encompassing name was appropriate.

Anyone who manages network security, compliance audit prep, or related IT risk management would agree that optimization of firewall policies has a tremendous impact on improvement of network defenses.

Click here to read all about FireMon Policy Optimizer module – if you’re just such an individual or any element of network security is your job, you’ll be happy that you did.

We’d stake our name on it.

One Man’s Heartbleed is FireMon’s Opportunity

Vulnerability researchers scored major points last week by unearthing the so called “Heartbleed Bug” in the widely used OpenSSL cryptographic software library –truly a significant discovery given that the issue impacts a huge number of web sites, including those of most enterprises.

To underscore the severity of the issue, researchers involved have defensibly dubbed the vulnerability as “one of the most serious security problems to ever affect the modern web”.

As with the identification of many other such far-reaching software flaws, news of the discovery sent a lot of organizations running to address their newly apprised OpenSSL exposures. As of yet it is unknown if there have been any real-world attacks designed to exploit Heartbleed, but even if that is not the case, one can assume that such threats are currently under development.

heartbleed.logo

Another impact of the Heartbleed vulnerability – so named because it literally cuts so deeply in terms of its applicability – is that any software providers who somehow utilize OpenSSL in their products were forced to assess the impact of the bug on their customers.

Ironically, this legion of technology vendors also included many security solutions providers as OpenSSL is just so ubiquitous. It’s hardly a sign of incompetence when security experts get caught out by such a far-reaching issue, but, as the providers responsible for shutting the doors on attacks, such a situation is doubly disconcerting.

So, here’s the part where you’re expecting me to offer a mea culpa and claim minimal responsibility on FireMon’s part for getting sprayed by some of the Heartbleed fallout. We do, after all, use OpenSSL in our products.

Except that didn’t happen; instead of falling on our sword, here’s another place where FireMon developers find opportunity to give themselves a pat on the back. Once again, FireMon’s commitment to going the extra mile paid off – our platform continues to use the strongest encryption available to ensure the security of your data between client and server, and because of that, Heartbleed doesn’t impact our solutions.

Without seeming too opportunistic or taking pleasure in a misfortune that surely affected a lot of respectable software providers, I will note that at least one of our competitors was forced to issue a vulnerability bulletin as their version of OpenSSL was left open to potential attack. It is what it is, but, without gloating, FireMon did not have to do so.

Beyond that relatively straightforward observation, there’s actually a lot to talk about related to FireMon and Heartbleed. If your organization was somehow exposed to potential attack by the bug, our Security Intelligence Platform can rapidly identify just how and where systems and assets are at risk, and how to rapidly address those issues.

To be specific, using FireMon’s patented Security Manager assessment engine, along with its Risk Analyzer Module, enterprises can rapidly determine precisely where open access across their networks leave Heartbleed (CVE-2014-0160) exposed and reachable within their networks.

Further, Risk Analyzer will also recommend a prioritized list of patches that can by applied to protect against potential Heartbleed attacks, as well as prioritize remediation of all other known vulnerabilities.

Lastly, but perhaps even more importantly, as it is often easier and faster to restrict vulnerability exposure by changing network security device rules and configurations, FireMon can rapidly identify any existing policies that can be altered to prevent access without patching involved systems.

The ability of organizations to address Heartbleed using FireMon also highlights the frequently underappreciated aspect of how network security remain the most critical underlying layer of defense that today’s organizations rely on.

Even when Web security solutions, advanced threat detection or vulnerability management tools cannot address a previously unknown issue such as Heartbleed, altering network security defenses to account for potential attacks provides a direct and practical strategy.

If your organization is seeking methods to better defend itself against Heartbleed exploitation, or truthfully any such threats, get in touch with FireMon today. Not only can we help address this particular issue, our Proactive Security Intelligence solutions platform can dramatically improve all matters of secure network access management.

Identify and Remediate Shadowed Rules

Firewall policies are complex and can be difficult to manage because of the complexity.  One of the difficulties is evaluating what access a complex policy is permitting or denying.  Redundant rules can significantly hurt this process and not only make the policy unnecessarily complex, but also mislead the administrator as to how a policy will process certain traffic.  As such, it is imparitive to identify and remove shadowed rules.

What is a Shadowed Rule?

We previously discussed hidden and redundant rules in this series.  Shadowed rules are a special case of hidden rules that deserve special attention.  A shadowed rule is hidden by another rule in the policy, but has a differently defined action.  For example, one rule will be defined to ACCEPT the traffic and the other will be defined to DENY the traffic.  Depending on which rule you look at, you may have an incorrect understanding on how the firewall with process the matched traffic.

Let’s take a look at an example of a shadowed rule:
shadowedRule
In this case, rule 13 will match all the traffic and more that rule 21 would match, so rule 21 is clearly hidden.  However, as an administrator, if you were looking at rule 21, you would be under the impression that rule 21 would drop tcp/8080 traffic between the source and destination, when in fact, it would be previously accepted by rule 13.

How can FireMon help?

Just as with hidden rule analysis, FireMon can identify the shadowed rules in your firewall policies.  Once identified, a decision can be made on how to handle this situation.  In the example above, it may be appropriate to delete rule 21 as redundant and unnecessary.  However, it may also be appropriate to move rule 21 above rule 13 to have the desired effect of dropping that specific traffic flow.  In either case, these shadowed rules represent a technical mistake in the policy that should be remedied to reduce the policy complexity and to remove the confusion they can cause.