Archive for the ‘FireMon Solutions’ Category
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.
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.
Gary Fish and I had a great conversation with Alan Shimel on his Security Exe podcast last week. If you have a few minutes, you can listen to our discussion here: http://www.ashimmy.com/2011/12/have-we-got-risk-all-wrong.html
One of the great points to come out of a conversation was a comment Gary made. Paraphrasing here, Gary proclaimed, “You shouldn’t buy another security product until you understand your current security posture. And that is power of Risk Analyzer. Identify the gaps that really need fixed before you spend your money on another ineffective security product.”
I think this is a great point. Before you set out to fix something, understand what you are trying to fix.
Also, this statement reinforces the message we have been making for years. Security technology to mitigate, reduce or limit risk is great, but only if it is effectively managed. Understanding the current security posture in the context of these existing controls should be a pre-requisite to any future security project.
I am very excited to announce the release of Risk Analyzer, FireMon’s patented risk analysis application providing enterprise visibility into risk exposure (Press Release). The product is a revolutionary advancement in how to identify and measure network risk and is now available as part of the FireMon portfolio of security management products. The release of Risk Analyzer marks another significant step towards our vision of enabling enterprises to achieve Better Security through Better Management of their security processes and technology.
This solution builds on the decade of experience we have with firewall and network configuration management. Understanding how network behavior and existing security controls affect the reachability of identified vulnerabilities defines the real exposure of an asset from a particular threat. These calculated scores for the defined risk scenarios provide insight into existing exposure and also permits continuous evaluation of improvement or regression of the security posture.
To learn more about Risk Analyzer check out the web site at http://www.firemon.com/products/riskanalyzer/ where you can also register for an upcoming webinar about the solution.
I look forward to sharing more about this solution and our vision in the coming weeks and months. But for today, I want to share my appreciation for a great team of people that helped bring this vision to reality. Our dedicated and talented product and engineering teams have done a tremendous job building upon great technology to deliver a great product. Thank you!
The amount of news generated around attacks in 2011 has been overwhelming. In just the last week, the reports around SCADA based attacks have reached almost histrionic levels. Attacks on NASA, AT&T & VCU have all been highlighted this month as well. Despite the fact that companies will spend over $8 billion dollars on network security this year, hackers continue to successfully breach networks with an alarming regularity.
In an article on APT’s posted on Dark Reading yesterday, Sean Brady from RSA had an interesting quote. He said “Identifying the entry point — where an attacker got into a company’s network — is a key aspect of identifying and responding to an advanced attack”. At Firemon, we couldn’t agree more. However, we would also ask why wait until you’ve been attacked to discover the entry point? Why not proactively find the entry point yourself? As clearly indicated by the attack coverage we’ve seen in the press this year, the attackers are actively looking to find the entry point into your network even as you read this post.
Firemon’s new Risk Analyzer technology is designed to proactively find the entry point into your network that can be exploited. Risk Analyzer will also identify where an attacker can pivot off that access point, and what other resources within your network can be compromised. Risk Analyzer will also prioritize what patched vulnerabilities can reduce the greatest amount of risk with the least amount of effort, helping to focus your organization’s remediation efforts. Don’t be the last to discover the entry points that are exposed in your network; he who finds the entry point first wins.
I read a quick blog post this morning from Rick Holland at Forrester. In fact, part of my title is borrowed from a line in his post. As security professionals, I think it is important to recognize that despite our best efforts, many of the network security controls that have been deployed have still failed to prevent breeches and attacks from occurring. Holland along with John Kindervag have published a new report called “Planning for Failure”. They note that this years headlines have not been encouraging for the security world, as evidenced yet again yesterday by the Steam website hack and the take down of Estonian hackers in Operation Ghost Click.
The deluge of news around breeches and incidents that have occurred this year should not cause us to throw our arms up and head for the exits. It should ultimately galvanize those of us in the security world to be more proactive about assessing the risk posture of our organizations, identifying the areas of weakness we have, and fixing them before an incident occurs. As Holland notes in his post “An ounce of preparation is worth a pound of remediation”. The full Planning for Failure report also stresses the importance of testing. We at Firemon could not agree more. Our new Risk Analyzer technology enables organizations to test their entire network topology, factoring in the network security controls that are in-place, and identify exactly where attackers could breach your network. Risk Analyzer will even highlight systems that are susceptible to client-side vulnerabilities that attackers could gain access to despite effective network security controls, and identifies where the attackers could further penetrate into the network by pivoting off these assets. Risk Analyzer’s patented analysis engine provides real-time analysis, and graphically shows you where in your topology you are vulnerable. Risk Analyzer also helps you to laser focus on what remediation steps will reduce the greatest amount of risk with the least amount of effort by providing a prioritized list of remediation actions, and allowing a user to virtually apply said patches, graphically showing the impact that remediation effort has on the networks risk posture.
We are excited to release Risk Analyzer this month, and believe it is the key part of a proactive testing process that all security organizations should implement as part of their overall Incident Management plan. Risk Analyzer will allow you to substantially reduce your risk posture, prioritize your remediation efforts, and to measure the effectiveness of the security controls you have put in place.
Disaster Recover (DR) and back up long ago became staples of a competent network and security strategy. Backing up databases, applications and data can be as simple as setting up a schedule or deploying a service to automate it for you.
Though, much like the mechanic who doesn’t take care of his own car, backing up security and network device configuration is often overlooked and falls between the cracks. It’s just as important to back up security and network devices as it is to back up applications and other data.
Wouldn’t it be great if there was a solution that was tailor-made for backing up security and network devices? Something purpose-built for firewalls, routers, switches, content filters and load balancers? Now there is!
FireMon is happy to announce the newest member of the FireMon suite of enterprise security management solutions: we call it BackBox. It is purpose built for security and network devices. Scalable and secure, with extensive multi-vendor support, BackBox offers central and secure backups that are verified to make sure you have everything backed up that you would need to restore in case of an incident.
BackBox also offers real-time reporting with a live dashboard and a full DR implementation plan to follow when you need to activate it.
All of these are custom tailored to security and network devices. When these devices go down, time is money. You want something that is going to get those devices back up and running as quickly as possible!
Here is a list of some of the devices BackBox supports:
Check in soon for more BackBox updates!
A while back, I worked with one of our clients who was put in a tough spot by their external auditors. The auditor flagged every firewall rule that accepted traffic and used the “Any” object in the service column as non-compliant. Our client, in turn, asked us, “How can we quickly redefine these rules with more appropriate access? And how can we do it without interrupting business operations?” The answer we gave them was FireMon’s Traffic Flow Analysis.
Finding Big Rules
We’ve all had those handful of rules that we hate. They’ve been in the firewall for years and nobody remembers who put them there or why. But they all have something in common: they aren’t secure. They allow too much access, auditors hate to see them and no one can justify the access because the uses are too broad. Class A networks in the source or destination, “Any” objects in the service column, and the use of deeply nested group objects are all examples off broad access.
So, why were the rules added in the first place? There are a lot of reasons, but I think the most common one is that the real requirement for access was not well defined, so broad access was given to ensure functionality. It’s certainly not uncommon for security to be the last to know about architecture projects or new systems being deployed on the network, so engineering on a short timeline without all of the information has almost become status quo. Given the high probability of those scenarios continuing to occur, how can we improve the rule set without interrupting normal operations?
Removing Big Rules
FireMon’s Traffic Flow Analysis can help you pare down those big rules into a handful of manageable rules that more correctly represent the access that is required. Once you do that, the business justification for the access will be clear, the business owner can be assigned, and the rules can be managed throughout the rest of their life cycle.
Traffic Flow works by closely watching the access that is in use behind a single firewall rule. Then, using a complex algorithm to determine the common access paths, it recommends how you can define new access. The analysis can be as simple as showing the services used by that rule or complex rule definitions that include the source, destination and service.
Traffic Flow is available for firewall rules as well as ACLs on Cisco routers. It also has some additional uses, such as quickly helping you see what is falling through to the drop rule or creating a policy from scratch by monitoring an accept-all rule.
One of the early epiphanies for any risk manager is when they realize that to totally eliminate risk is frankly not worth it. The truth is that to eliminate risk, if it is even possible, would usually be so resource intensive that it renders a pyric victory at best. That is why they don’t call it risk elimination but risk management.
Balancing risk against business need and cost of effort for mitigation is the key to Risk Management. What is the exposure? What will it take to eliminate that exposure? It follows then that handling risk in the most efficient matter possible would allow you to lower you risk level while expending the least amount of resources. Efficiency is a prime consideration in risk management.
That is one of the best and most useful features in Firemon’s new Risk Analyzer product. Once RA has examined the network configuration and vulnerability data it can tell you what any single action or combination of actions on your part will result in what risk mitigation. For instance it can show you that patching one vulnerability could eliminate a specific number of potential exposures. At the same time it could show you that fixing another vulnerability or fixing multiple vulnerabilities really doesn’t buy you much in terms of reducing risk.
How do you get the biggest bang from the risk reduction buck is a vital piece of risk management. Intelligent analysis of multiple risks and remediation options is just one of the great features that Risk Analyzer will bring to your organization. We will be highlighting more great Risk Analyzer features in upcoming blogs.
When FireMon announced that it had acquired Saperix Technologies and their patent pending, MIT Lincoln Labs developed, risk analysis technology, many people nodded their heads but didn’t really understand why we were so excited.
While risk analysis on its face sounds like a no brainer for an information security company, not everyone may be familiar with the use cases around this type of technology. Risk analysis is often not about eliminating risk. That is pretty much impossible. Risk analysis is more about managing risk to an acceptable level for your organizational needs.
We wanted to give you three use cases to familiarize you with what can be accomplished with risk analysis. These use cases are general and apply to the broad category of risk analysis. In our next post, we’ll discuss how to calculate risk for an enterprise network so be sure to check back soon.
Here are three scenarios where risk analysis solves mission-critical issues:
1. Measuring Risk: How does one quantify risk? Of course, not all risks are created equal. Some risks represent greater risk (pun intended) than others. So how do we assign a value to risk, quantify it and compare multiple risks, which is essential in prioritizing risk reduction activities?
Risk analysis in general and FireMon’s Risk Analyzer in particular give executives insight into what their risks are, assigns prioritization scores to different risks and shows what remediation and other activities can reduce risk the most. This way, risk managers can decide how to use limited resources to get the “biggest bang for the buck” in reducing and managing risk.
2. Prioritize Vulnerabilities: Unfortunately, today’s networks are “target rich environments” with vulnerabilities often outstripping an organizations ability to cure them. In this type of situation, prioritizing which vulnerabilities to remediate first to reduce and manage risk is essential. While many vulnerability management solutions will assign priorities to vulnerabilities based on criticality of vulnerability and importance of the asset, these can be rather subjective.
A risk analysis solution such as FireMon’s Risk Analyzer goes beyond the subjective and looks at other factors such as network configuration. Adding this additional level of context can drastically change the priority of remediation. Also, by analyzing which particular remediation will solve the greatest number of vulnerabilities again allows an organization to have greater insight and control of managing risk.
3. Preventing Attack Propagation: With blended attacks, advanced persistent attacks, spear phishing and other sophisticated attack techniques, often times the initial target of an attack is not the actual payday target of an attacker. Many times, intruders may first target a less-protected, non-critical asset on the network. However, once establishing the beachhead, the hackers use this “inside” base to then propagate an attack against other assets on the network. Because they are originating inside the network already, they are often invisible to perimeter defenses. Risk analysis can highlight how an attack can propagate through the network. Risk Analyzer can actually show graphical views of how an attack can propagate through a network and what paths it may take. In this case, forewarned is forearmed. Knowing how an attack may propagate, network admins can be on the lookout and thwart these dangerous attacks.
Hopefully this will give you a better idea of how important risk analysis is. Stay tuned for our next post where we’ll discuss how to calculate risk for an enterprise network.
For years, firewall managers have been required to justify why a firewall rule was added to the rule base. In the past, lots of us met that requirement by putting the change control ticket number in the “comments” column of the rule. That method worked for a while, but now that regulations like PCI and NERC require firewall managers to produce the full documentation multiple times a year, we need a new answer – one that does not require days of manpower. One that will survive the next time we change ticket systems (and yes, we will change ticket systems… again).
As security professionals, we don’t hold the responsibility for the risk that any access poses, the business leaders do. But we are responsible for advising on risks that are incurred and presenting the information on why our risk posture is the way it is.
So, explaining our access in terms that the business can understand is critical. If all that we know is a technical definition (like some internet IP address has access to some internal server using SSH), we don’t know very much. But, if we capture the justification for why that rule was put in, then we know “a consultant needs remote access to patch a critical application vulnerability.”
The second example shows the information our businesses need to make good risk decisions. It also gives us the information we need to ask the right technical questions, like, “Does that consultant still require access?”
Spreadsheets & Databases Don’t Work
I know a lot of companies have been documenting their firewall rules with spreadsheets and databases. Those are good point solutions, but they don’t scale for two big reasons: the rules move around, and the updates are still manual.
Firewall rules move, so tracking them based on rule number or position does not work. If you’ve tried this and created documentation, and then revisited that documentation a month later, you can barely recognize the work because the rule base has changed so drastically.
The manual nature of spreadsheets and databases is problematic as well. Updates are often made as an afterthought at end of the change process. These manual updates are difficult to enforce as integral parts of the change process, and so they remain inconsistent afterthoughts.
FireMon knows that good documentation is the cornerstone of firewall management. Making a decision about when to keep access in place or take it out is rarely a purely technical decision. Easily and quickly knowing who that access supports and what the access is providing is the basis for making any good decision.
FireMon’s solution integrates with the appropriate data sources (like change management and vendor administration tools) so that you can create documentation naturally, inside of a normal business process. It tracks the rules as they move up and down the rule base and keeps the documentation tagged to the right rule. And it fully reports on the data, including identifying those changes that were not documented.
From my experience, spreadsheets can’t fully report on anything. If yours can’t either, learn more about FireMon’s rule documentation capabilities at http://www.firemon.com/ruledocumentation.aspx.