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 our 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!

In our series on risk here at the Firemon blog, we have clearly stated that network security is all about risk. So if risk truly is the yardstick we should use to measure the state of our organizations security, why are so many of us not measuring risk correctly? There are many factors that contribute to this issue, but ultimately there tends to be one overriding issue that affects organizations perspective around security and risk.

Too many organizations view security and risk reduction as a project rather than an ongoing process. There are a number of security arenas where this myopic perspective of security as a project is displayed. Compliance initiatives around PCI DSS, HIPPA, GLBA, etc. tend to get slotted as a project to complete, and after said completion, security has been achieved. While compliance initiatives are an important and depending on the industry, required part of an organizations security efforts, they are not a project to complete that results in a state of security and therefore reduced risk. Time and time again, we have seen too many organizations assume that their PCI DSS compliance equals a secure network, only to be shocked when they are subsequently attacked.

Similarly, implementing a vulnerability analysis and remediation project has become most organizations default way to identify and reduce risk within their networks. Typically an organization will run an enterprise vulnerability scanner at set times, compile a list of the vulnerabilities identified, possibly prioritize actions based on asset value, and then schedule patch work for the next 2-3 months to fix the 100′s or 1000′s of vulnerabilities listed by the scanner. As we saw with compliance initiatives, too many organizations treat vulnerability scanning as simply another project to tick off the list, and once complete, assume they are secure. The vulnerability scanner also has no knowledge of the network security controls that are in place, and therefore is unable to truly identify exactly what is the most severe risk to the network security based off what is truly reachable or exploitable as we have previously highlighted on our blog. Vulnerability Scanners are a vital tool within any organizations remediation strategy, and one that hopefully most organizations are utilizing. They are not the end-all solution answer to risk by themselves though.

In both security arenas we discussed above, there is no real time, ongoing, effective measurement of the organizations true exposure to risk.  Project based approaches do not allow an organization to truly see how the efforts of the organization to reduce risk ultimately affect the overall risk posture. In both cases, they are gaining a false sense of security simply by completing projects related to security. To truly manage and reduce risk, organizations need to make the management of risk a daily part of their operational security. In order to operationalize risk, practitioners need to leverage a tool that fully measures all of the elements that affect the risk to the network, prioritize the actions that need to be taken, highlight the impact those actions will have on the security posture, and allow the organization to see how their risk posture has changed over time or as new changes have been required within their network connectivity. The key element to said tool must be a truly effective measurement of risk to enable risk management to become a daily operational function of security. In our next post, we will discuss what elements are required to fully and accurately measure risk to a network.

Johnnie Konstantas over on Security Week has the first of what looks like a series of articles posted on what she calls Firewall Wars 2.0.  Johnnie recounts that back in the day, the big fight was between stateful inspection firewalls and proxy-based firewalls.  I remember those days well and agree there is a parallel to those days.  However, I don’t think time only one has to win.

Konstantas now suggests we are in a new era of firewall wars and I tend to agree.  The “Next Generation” firewalls promoted by Palo Alto Networks and followed by many of the traditional firewall vendors has begun to shake up the market.  I don’t agree with Konstantas assessment of what constitutes a “Next Gen” firewall however.  She seems to lump them into the UTM category, which I think understates both the UTM and the NG firewall capabilities.  The genius of the Next Gen firewall (in my opinion, of course) is that it took much of the capability of an IDP to recognize and categorize layer 7 traffic and managed it in a “positive security model”.  Unlike IDP’s that block traffic identified as bad, the NG firewall identifies and only allows traffic deemed acceptable.  Slight shift in technology application, gigantic shift in behavior.  And while it is a great advancement for certain situations, I don’t think it immediately makes stateful inspection firewalls obsolete.

What I liked best about Konstantas review of the topic was the recognition that not all products are created equal AND not all situations require the same solution.  Security needs and performance requirements should be key factors in making a decision.  Not all situations call for NG firewall capabilities or UTM functionality.  In fact, I would suggest, not all locations call for a dedicated firewall, in some locations a firewall feature set on a router may be a good fit.

As for the “war”, as budget cycles come around for firewall upgrades and migrations, consumers will have a lot more choice than they did just 3 years ago.  I suggest it not be considered a Betamax vs VHS battle…there is room for NG firewalls, stateful inspection firewalls and even proxies all deployed in the appropriate location in the battle of network security.

Regardless of which firewall technology an enterprise choses to deploy (or if they deploy them all), they must be effectively managed.  The best firewall technology won’t fix a poor configuration.  A good management technology like FireMon Security Manager is the answer to make sure your firewall technology is effective.

In many discussions about information security, you will see references to risk, risk management, risk assessment, etc.  For some people, this seems like an obvious association, for others, there appears to be a clear distinction between the two.  For the later, they tend to think of security as a technical effort and risk as an audit/compliance effort.  I understand where this idea comes from, but I don’t agree.  From my perspective, Security is all about Risk.  Whether you are talking about securing your retirement financial security, securing your home or securing corporate information assets, you are talking about mitigating or limiting the RISK from the threats that pose potential harm to what you want to secure.

So why accept any level of risk?  Because it is necessary to live or conduct business.  We accept risk of illness when we step outside.  We accept risk of data breach when we connect to a business partner.  In both cases, it is simply a reality we accept.

The practice of Information Security is to protect assets from harm.  As an industry, we often refer to these activities in terms such as,  “securing the network”.  However, it is critical to understand that installing a new security technology to secure (verb)  the network or application doesn’t actually result in a secure (adjetive) asset.  Instead, it is implemented to reduce the risk to that asset from a perceived or real threat, not eliminate all risk from all threats.  To actually secure something completely, where there is no risk, would ironically require destroying it.  To guarantee security of the network would require completely blocking all access (at which point it is no longer a network).  And so, the practice of Information Security, like daily life, is an exercise in managing acceptable risk.

But we can do more than just accept risk.  We can and should manage risk.  While we can’t eliminate all risk, we should manage risk to acceptable levels.  But this is not standard practice.  While many companies have some form of Risk Management, it is not the central component of their security practice.  Instead, it is something that is layered on top of their security practice. In fact, many companies create separate groups; one to manage security and one to manage risk.  The security group will install and operate security technologies and every so often the risk group will inform them of problems that need addressed.  If risk were truly the center of our security practice, risk would play a role in all daily operational activities and the effectiveness of those security activities would be measurable impact on the risk to the assets we wish to protect.

Instead, security groups get lost in “securing” the enterprise.  Without a measuring stick for success beyond, “don’t get hacked”, we continue to turn to new technologies promising a new level of security or to address a new threat.  We lose sight of the real reason for the technology, to limit risk.  I don’t see this as a problem security operations created, I believe it is a problem with executive leadership not defining success clearly.  But it is the responsibility of security to provide the correct picture and data describing security in terms of risk that is consumable by the executive leadership.  Until these two things happen, security will remain an impossible task with an impossible goal to “secure the enterprise” while enabling business.

I believe we can get there.  I believe that measuring risk is where it needs to start.  This post is the first in a series of posts that will appear here on the FireMon blog detailing why we think measuring risk is so important and a way to make it possible.