How Much Gets Reported

It’s a pretty well-known fact that far more crime occurs than gets reported to authorities, and far more gets reported to the authorities than gets reported on by any form of media. Cybersecurity attacks are no different.

Because we assist in the investigation and incident response of many of these cases, we’re constantly on the lookout for reporting of those incidents by independent sources. By our own research, 1 attack gets reported in the media for at least 73 that happen without any mention to the public. Of those, we see scant few actually make it to what most would consider “mainstream media”.

Stuxnet is the most recent example of a named malware attack that made the prime time news, and it joins the ranks of Code Red, Nimda, and (to a lesser degree) Zeus in the public lexicon of big attacks. However, the ones that never make it to the front page show both an increasing technical sophistication, and a more focused set of attack goals.

Posted in Commentary | 1 Comment

The Human Brain and Your Network Infrastructure

Common wisdom says that we humans use less than 10% of our brains’ capacity in a lifetime. I assert that the same is true for enterprise networking hardware and software.

As referenced by Paul in his recent post, we very frequently run in to organizations that have an overwhelming urge to add something to their systems to make them more secure. In reality, some of the deepest changes that will have the biggest impact on security are all around you in the environment you already have.

For example, all Cisco switches support VLANs, but a full half of the organizations we have dealt with have not seriously explored using that functionality to help separate network devices from each other. Where VLANs are implemented, at least 75% of those organizations don’t properly use a firewall or layer 3 access lists to prevent traffic from flowing between the network segments. Back down to layer 2, all Cisco switches support some form of MAC filtering or limitation of MAC addresses per port, but even those basic controls are almost never enabled in deployments we’ve seen. These are defenses for some of the most basic network attacks and can be enabled safely in some combination for 98% of all deployments.

The examples could go on endlessly, but the important thing to illustrate is that most all of your network is only delivering 10% of its potential from a security standpoint at any given time. Unlike the brain, accessing the remaining 90% is as simple as testing the functionality, configuring it, and deploying it to current installations.

To make the point directly, your organization has likely been purchasing all the hardware and software you need to be secure for years. The missing piece is the knowledge and experience required to put the pieces together in a way that makes them work effectively and securely together. That’s where we come in.

Posted in Security Articles | 2 Comments

Avoiding Hard Work for Nothing

This morning I found myself thinking of the many commercial and government organizations we’ve run into over the years that have an urge to buy something… something, as in almost anything they can plug in that purports to improve their cyber security posture. “Surely there is something I can purchase and plug in to fix (this or that cyber security issue). There has to be something I can buy!”, goes this line of thinking.  Something that will help these organizations delay –or even avoid– the challenging but lasting solutions that would result from correcting the underlying fundamental pervasive deficiencies in network architectural design, technical training, readiness, incident response, policy and more. “Surely there is something on the market today will let us avoid the hard decisions until the next budget cycle – if ever!”

If only things were this simple. Unfortunately, there is nothing on the market today that fits this description, no matter what some product vendors would like for us to believe.  While many security products do work from a tactical point solution perspective, each comes with its own support, maintenance and all-too-often cyber security holes of their own. Meanwhile such organizations have fewer IT budget dollars and time left to fix the true cause of many of their problems, their network’s flawed architectural design.

Fortunately, there is good news. One of reasons why decision makers put off tough architectural design decisions is because they often believe significant outlays of capital expenditure and network downtime would be involved. Neither assumption is normally true.

The logical configuration of an enterprise network can be re-aligned to support multiple security objectives at once from a fundamental architectural design standpoint, while simultaneously improving network functionality and reliability. To do this, the logical and physical interconnectivity of routers, switches, firewalls, DMZ configurations, VLAN configurations, proxy servers, remote access infrastructure, DNS, databases, servers, enterprise authentication, Active Directory domain(s) configuration, domain policies, Group Policies and more are all fair game for enterprise-wide re-configuration. Such reengineering can lower the cost of network operations more than sufficiently to pay for the entire exercise. The return-on-investment payoff timeframe can be year or less – and all without any additional network downtime.

Sound impossible?  Don’t believe it can be done?  Good, then I’m glad I’ve piqued your interest. Give me a call and I will personally help you to understand exactly how we do all this and more – and I will even use your network as an example, gratis on the house.  So what are you waiting for? Call me. When you do, choose the option for our enterprise security services team and then ask for me. I look forward to speaking with you very soon.

Posted in Security Articles | 3 Comments

Mitigating the Next Stuxnet Worm

On July 18 at the FOSE 2011 Conference in Washington, DC , I was one of two speakers who addressed the topic, “Situational Awareness – Mitigating the Next Stuxnet”.  In my remarks, I noted that the Stuxnet worm secretly infected 12,000 computers in five Iranian nuclear facilities over a year-long period without detection. The attacks began 2009 and weren’t discovered until July 2010. I stated that there is no way that this attack could have happened had Iran had a reasonably competent level of internal cyber security which was commiserate with the stated importance of those facilities to that nation.

A look at this diagram shows the nine different ways that the Iranians unwittingly gave the Stuxnet worm major assistance in accomplishing its mission without detection:

      Static screen shot from an animated presentation illustrating Iran’s cyber security incompetence

As this diagram speaks volumes for itself, for brevity’s sake I will comment here on only two of the nine different ways the Stuxnet worm was able to propagate for so long to so many thousands of machines without detection:

  • In a real-time process control facility (common example: SCADA/DCS), the user-monitored graphical user interfaces on Human Machine Interface (HMI) machines can be manipulated at will to display whatever an attacker –or an attacker’s malware– wants. This includes forcing the display to show normal facility operations data, even though the machinery or processes may be operating abnormally as a result of an in-progress attack. Use of this tactic in an offensive military worm should not have been a surprise, as vulnerability assessment Red Teams including those managed by yours truly have used such attacks as part of process control assessment work as far back as 2001.

A low footprint, high return way of preventing such manipulation is to use off-the-shelf software to monitor file-level changes to all mission critical applications such as HMI software, database executable files and major portions of the HMI underlying host operating systems.  A pattern of file changes that spreads on its own from machine to machine across the network is indicative of a stealthy malware attack. An example: the MD-5 or SHA hash value of BOOTVID.DLL changing across a network without detection by anti-virus software likely indicates the spread of a stealthy new malware specimen.

  • Malware propagation across a network environment generally produces abnormal patterns of traffic which deviate from previously baselined traffic patterns.  These patterns can be detected by routine manual analysis even in the absence of detection by Intrusion Detection Systems (IDS), although many IDS systems can be calibrated to detect such traffic deviances.  Basic examples of patterns to look for include new peer-to-peer machine connections, server-to-workstation connections, a pattern of changed connections from workstations to servers, or outbound traffic changes or pattern of new outbound data egress attempts.Any pattern of changes that spreads on its own across the network without alerts from anti-virus software may be a strong indication of an in-process stealthy malware attack. Example: a burst in a specific pattern of DNS queries which spreads from machine to machine across a network.

In conclusion, it should be calming to realize that in the end, the Stuxnet worm was just software. Complex groundbreaking software, admittedly yes, but still just software.  The Stuxnet had no magical powers or superhero ways of taking over its target networks.  It was merely software that relied on the same avenues of attacks and network communication protocols which have been widely discussed for many years as being significant problem areas. Stuxnet  could have been beaten by an appropriate level of internal defense which was commiserate with the importance of those facilities to that nation.

Now that the Stuxnet code is in the wild, we can surmise that the next great attack will only build on the ground breaking path laid by Stuxnet worm.  This should be a wake up call to our nation.  The question is, are we listening?  Time will tell soon enough.

Posted in Security Articles | 7 Comments

A Cost-Based Analysis of User Effort in Security

This article does a fantastic job of quantifying the somewhat nebulous idea of why end users generally tend to make decisions about security that seem poor. Looking at the cost analysis comparing the price of end user time to the actual losses, it’s clear that many of the basic traditional wisdoms surrounding daily web usage are a huge hassle with little payoff.

In other words, the average user would spend far more time attempting to maintain strong passwords and check every URL and SSL certificate than he/she is likely to lose by failing to do so. The article goes much deeper into the math leading to those conclusions, but it’s not necessary to whip out a calculator to know he’s right.

In my opinion, this solidifies the fact that much of the burden of end user protection is shifted up the chain. While one user may only see a few pennies per year of realized risk, the organizations serving all of those end users will see substantially more loss, as it is all aggregated. By the same token, organizations serving end users are in a position to much more economically deploy countermeasures, and have access to more data which allows them to do so effectively.

The other angle on this is that the more transparent security controls become to end users, the more effective they’ll be. This paper covers directly the effort needed to validate SSL and read URLs. Other controls like virus scanning at the perimeter, IPS, and well-implemented least-access principal (while not without issues of their own) are considerably less likely to require end user effort to be effective, and therefore be a better answer in that regard than any amount of awareness training.

Posted in Commentary | Leave a comment