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.

FireMon: Formula One for Proactive Security Intelligence




For hardcore fans of Formula One auto racing, aside from the thrill of the involved speed and pageantry, one of the most compelling aspects of the wildly popular sport lies in the marriage and continued advancement of human and technical expertise.

Heading into the 2014 season, F1 has once again altered its technical “formula”, requiring teams to adopt new turbocharged 1.6-litre V6 engines as opposed to the naturally aspirated 2.4 liter V8s that they’ve run since 2006.
Understandably, this significant change to the central aspect of the world’s most advanced race cars created a massive technical challenge for even the foremost teams, among them Ferrari, Mercedes and Renault (including 4-times consecutive champions Red Bull Racing).

FireMon.F1.engine

As engineers and drivers have put their newly configured machines through testing over the last few weeks, there have been a lot of teething issues and resulting black fumes of engine smoke. Countless sensors on each engine are being monitored constantly to gather information regarding failures and empower useful engineering revisions.

Similarly, today’s IT security practitioners and solutions providers are constantly reformulating the makeup and implementation of engines used to assess and manage IT security infrastructure. The quest to find the most effective source of analytic power and resulting intelligence is a process of constant advancement and experimentation.

Processes are mirrored in both domains: what formula of capabilities and output will product the most effective performance and results? Horsepower is crucial; reliability has to be there; change will be constant; over the course of time that an engine is utilized, what are the crucial requirements and areas, where permissible, where trade-offs and concessions can be made in achieving overall goals?

In the world of Proactive Security Intelligence and management of network security device infrastructure, FireMon can unquestionably make the claim that its analysis engine is the one that should be wearing laurels at the end of the day. (And yes, one could also create many analogies around race car tire performance and security “PSI”.)

The key differentiation that underlines this statement are the (patented) FireMon Security Manager engine’s scalability, speed and breadth of assessment. No other network security infrastructure assessment engine in the game today can provide comparable real-time visibility into the alignment of enterprise-wide defenses, along with what-if change modelling and understanding of underlying IT risks. It delivers actionable results in minutes – not hours – a feat unmatched in the sector.

Like engineers on pit row and in the R&D centers of F1, who work tirelessly to project every situation their engines will face during the season, simulating conditions, gathering data and attempting to create the ideal configurations for each race, FireMon customers leverage our solutions to constantly understand their current state of security alignment and affect changes that result in optimal network protection and performance.

Just as F1 teams are working constantly to engage a power plant that offers best chance to win a world championship, FireMon clients consistently and comprehensively review the latest intelligence generated by Security Manager’s intelligence engine to achieve optimal network security defense, policy compliance and IT risk management – ultimately moving to avoid data breaches such as the one recently reported by Target.

Whether you’re a fellow F1 enthusiast reading this blog and seeing the connection, or a practitioner seeking new methods of improving your organization’s IT security standing, I assume that, like me, you’d recognize that the magic is found somewhere in the formula of combined human capability and computing machine.

To see the FireMon formula in action, simply request a detailed demonstration here, or if you’re at the RSA Security Conference 2014 in San Francisco next week, seek us out at Booth # 927 in South Hall – we’ll happily let you take it for a spin.

Here’s looking forward to the 2014 F1 season, and the continued competition to win out in the field of Proactive Security Intelligence.

Of course, I feel that FireMon will take the checkered flag.

RFC 1918 – Preventing Private Address Leakage




Request for Comments 1918 (RFC1918); also known as private or reserved addresses, are blocks of IP addresses reserved by the Internet Assigned Numbers Authority (IANA) for dedicated use inside local (non-public, private) area networks.

RFC 1918 reserved address (block) space:

  • Class A – 10.0.0.0 – 10.255.255.255 (10/8)
  • Class B – 172.16.0.0 – 172.31.255.255 (172.16/12)
  • Class C – 192.168.0.0 – 192.168.255.255 (192.168/16)

To prevent packet and routing information leakage to/from untrusted networks, border devices such as firewalls, routers, and gateways should implement Routing Layer (Layer 3) practices that include (but are not limited to) the dropping and logging of ingress/egress invalid packets and anti-spoofing measures (e.g., filtering private addresses); except when tunneled through a Virtual Private Network (VPN) to remote offices or telecommuters. Systems in the Demilitarized Zone (DMZ) should be configured to have their addresses translated to public Internet addresses through Network Address Translation (NAT). NAT replaces private IP addresses with public IP addresses, which can be used on the public Internet.

Example: Cisco ACL (Filtering RFC1918):

  • access-list 110 deny ip 10.0.0.0 0.255.255.255 any
  • access-list 110 deny ip 172.16.0.0 0.15.255.255 any
  • access-list 110 deny ip 192.168.0.0 0.0.255.255 any

The example above is that of an “explicit rule.” Explicit rules should be placed at the top of a policy.

Building The Fire 2014




FireMon celebrated an amazing 2013 as noted in our recent press release. The company also held it’s Global Sales Kickoff in mid-January, the theme of which was Building the Fire 2014. I thought I would share a couple of observations from the event with our blog readers.

First, the growth of FireMon was phenomenal to see! When I joined the company in August of 2011, I was the 21st employee at FireMon. Having the honor and privilege of being the emcee for the kickoff, I found myself looking out at 103 other FireMon employees on the first morning of kickoff. There was a palpable sense that the company was truly about to explode as our President & CTO Jody Brazil shared the explosive growth numbers that we experienced in 2013. This was reinforced throughout the kickoff as all divisions discussed the growth experienced both in sales, technology enhancements and in employees within each division.

Secondly, the future direction of FireMon was exciting to see. The product roadmap and vision for 2014 was laid out for the company, and the continued focus on real-time, proactive Security Intelligence reinforced FireMon’s market-leading focus on security management and risk analysis. A number of new and exciting technologies and enhancements will be rolling out throughout 2014 within the FireMon Security Platform, and we are excited to share these with you as they come out.

Finally, the amazing culture of fun and teamwork that FireMon has built over the years was on display throughout the event. The FireMon Band, G Fish & Special Sauce, made their debut performance on the first night of the kickoff. The diverse talents of employees from Sales, Development and Executive Management were on display, accompanied by sing alongs and dancing from the entire company. A small sampling of the band is below:

The second night featured phenomenal food and fellowship while enjoying two Kansas City landmarks as the team dined on the world famous Fiorella’s Jack Stack BBQ at Boulevard Brewing Company.

FireMon is on a phenominal growth curve. We entered 2014 with 56 open positions around the world. While we have filled a number of them, there are still openings available. If you would like to be a part of a fun, dynamic, winning culture on the cutting edge of Security Intelligence, we invite you to join us as we Build The Fire in 2014.

 

Prevent IP Address Spoofing




Prevent IP Address Spoofing

“Things are not always what they seem; the first appearance deceives many”. Phaedrus.

IP Address Spoofing is sometimes referred to as IP Address Forgery, and as the name suggests it’s a technique commonly used by hackers to perform malicious activities, such as Man in the Middle (MiTM), Denial of Service (DoS) and Dedicated Denial of Service (DDoS) attacks. It is generally used to maintain anonymity and cause havoc on the Internet.

To first understand what IP Address Spoofing is; and how it is used, we need to have an appreciation of the underlying protocol(s) that open the door for manipulation. Which essentially is IP, TCP and UDP and the ability to manipulate the packet header information (source address field).

Current State and Attacks

In an age of Botnets where an attacker has a layer of abstraction behind a command and control server, some people think that IP Address Spoofing is no longer an issue. When in fact the reality is the opposite, IP Address Spoofing remains a real problem to defend against. In some cases, IP Address Spoofing is necessary for an attacks success, where it provides an additional layer of anonymity and protection for a botnet (see DNS DDoS Amplification Attack).

So, due to the inherent ability to manipulate a packets header in the protocol stack is where the ability to perform malicious attacks such as:

MiTM – Where a malicious user intercepts a legitimate communication between two parties. The injected, malicious host then controls the transmission flow and can eliminate or alter the information within the data stream without the knowledge of the original sender or recipient. In this scenario, the attacker fools the victim into disclosing confidential information by “spoofing” the original sender’s address / identity.

DoS / DDoS – Since some malicious users are only concerned with consuming resources and bandwidth, they attempt to “flood” the victim network with large volumes of traffic to consume system resources. In order to maintain the effectiveness of the attack, the attacker will “spoof” the source IP addresses to make stopping and tracing of the attack as difficult as possible. This is amplified when multiple compromised hosts all have “spoofed” addresses and are participating in the attack.

Defence Mechanisms

What can you do to defend against IP Address Spoofing attacks?

Firstly, ensure that your firewall and routers are configured correctly and restrict the advance of forged traffic from the internet. For many years now firewall vendors have included a configurable anti-spoofing defence mechanism to block the use of private (RFC 1918) addresses on the external interface. In addition, the external (internet facing) interface should not accept any addresses that are used in the internal network range as the source. You should also prevent source addresses from outside of your valid public network range, which will prevent any of your neighbour’s from sending spoofed traffic to the Internet.

As an example, if the attacker sits within the 203.42.5.0/24 network range that is provided Internet connectivity by ISP D. An input traffic filter on the ingress link of router 2 (which provides internet connectivity to the attacker’s network) restricts traffic to allow only traffic that originates from the source addresses within the 203.42.5.0/24 network prefix and prohibits the attacker from using any “invalid” source addresses that reside out of the prefixed range.

A second preventative mechanism is to implement authentication and encryption to reduce the likelihood of threat. IPv6 implements both of these features.
ISP-Router-Example
How can FireMon Help?

IP Address Spoofing is a difficult problem since its inherent weakness is due to the design of the protocol suite. However, understanding how and why one would use a spoofing attack can greatly increase your chances of successfully defending an attack. Using Security Manager, FireMon provide the ability to perform a regular assessment of your firewall and its configuration against best of breed configuration practices. Security Manager includes a number of pre-built compliance reports that will save your security administrators valuable time and effort and assist your organisation to quickly find misconfigurations, the implementation of risky services and unused rules that could expose your network to attack.

A quick glance at the Firewall Configuration Best Practices report can provide your security managers with the detailed information needed to appropriately manage your organisations security on a regular basis.

Dashboard Review

Each configuration check that Security Manager is able to perform can be drilled into by clicking the item to show more detail.

Configuration Checks

Don’t be fooled by a masquerading IP; contact a Firemon representative today for a demonstration of Security Manager and how we can help your organisation and prevent your systems from being spoofed.