This vendor-written tech primer has been edited by Network World to eliminate product promotion, but readers should note it will likely favor the submitter's approach.
For all the advances in enterprise networking over the years there's been one big step backward: security testing. Relatively few enterprises today conduct regular security tests in-house, relying instead on occasional tests by outside consultants or, more dangerously, just taking vendor claims at face value.
Too often enterprise security testing takes one of two paths, neither satisfactory. Some enterprises buy complex security test tools, along with training, but then the tools gather dust once the trained staff leaves. Or they bring in outside consultants for security audits and penetration tests. While the results can be useful, they offer only a snapshot of the enterprise network at a given point in time. Obviously, both approaches have drawbacks.
ROUNDUP: Worst security snafus of 2012
What's really needed is an understanding that network security is an ongoing process, not a single product or service. Security test tools will continue to be important -- but only if they're actually used. With that in mind, here are some guidelines for assessing in-house security test tools:
* Ease of use and portability. The most common reason security test tools fall into disuse is their inherent complexity. We live in an age where children take to tablet interfaces with no instruction. There's no reason why security test tool interfaces should require a Ph.D. in network forensics to operate. And testers should get the same look and feel, regardless of whether a test is run from a desktop, tablet, smartphone or any other device.
* Meaningful, repeatable results: Test traffic should offer as much realism as possible. For example, tests that simply packet-blast a firewall with stateless small packets aren't very interesting, especially if the firewall's job is to guard against specific types of stateful application-layer attacks.
* DoS/DDoS protection: There are times when packet-blasting at high rates is exactly what's needed, and that's true for denial-of-service testing. Test tools need to have enough horsepower to saturate one or more backbone links with known forms of DoS and DDoS attacks, and they need to do so in a way that offers fine-grained control of key traffic parameters such as attack source addresses.
* Fuzzing. There's a bit of an arms race going on among vendors of signature-based security devices such as intrusion prevention devices (IPSs). One vendor will claim its IPS supports X number of signatures, while another will say its products are better because it has 2X signatures.
Unfortunately, neither vendor can claim totally effective protection because of a basic limitation with the signature-based approach: Signatures match only an exact sequence of bytes or packets. As a result, altering even one bit in a sequence is likely to "blind" a signature. Attackers know this, and make small changes to known vulnerabilities to escape detection. In effect, the attackers are fuzzing exploit traffic by changing parts of a known signature.
An effective security test tool also uses fuzzing. For example, a tool that uses fuzzing can take a SQL injection exploit and iterate over each field in the SQL query, changing random bits in each field. Because the IPS signature matches only on exact field contents, it's likely to miss this varied form of attack.
Fuzzing isn't limited to attack traffic; it also can expose weaknesses in benign traffic, covering many common network protocols. A good illustration of this is Open Shortest Path First (OSPF), the widely used enterprise routing protocol. Many routers running OSPF will behave in unexpected ways -- or even crash -- when receiving unexpected values in some OSPF headers. Fuzzing is equally effective in exposing security issues with attack and non-attack traffic.
* Known vulnerabilities. Much progress has been made to describe and categorize known vulnerabilities in a structured way. Attack databases, such as the Common Vulnerabilities and Exploits (CVE) list and Computer Emergency Response Team (CERT) advisories, identify security issues and offer demonstrative exploits. Automated testing of these exploits can be a great timesaver, while simultaneously extending security coverage. Look for security test tools that can step through a desired set of vulnerabilities.
* Mobile device emulation. Steve Jobs was right: We live in a post-PC era. Today it's equally likely that network connections will originate from a phone or tablet as from a PC -- and that means security testing needs to emulate these mobile devices.
While mobile and desktop environments have some things in common, there are significant differences down the protocol stack. Consider that TCP -- which carries 90% or more of all Internet backbone traffic -- has more than 300 variants, with nearly 100 for Windows alone. An effective security test tool should be able to model enterprise traffic in a meaningful way, regardless of whether that traffic comes from mobile or fixed sources.
Mobile devices also may use authentication protocols such as 802.1X and/or RADIUS that are not used by wired clients. Similarly, mobile devices -- especially those used by guests -- may reside in specially quarantined subnets, again with different access privileges than wired clients. Security test tools must be able to model the mobile device environment in a meaningful way.
* BYOD. In a related development, many organizations have embraced the "bring your own device" movement, allowing employees and contractors to reach enterprise network resources using their own computers, phones and tablets. There are numerous pros and cons to BYOD, and enumerating all the various security policy issues is well outside the scope of this article. However, once an enterprise decides to proceed with BYOD, it's clear that security testing is an essential part of any well-managed rollout.
BYOD testing begins with the ability to emulate each device type that will connect with the network. As noted, there are numerous variations within basic protocols. Moreover, the same application may be implemented in different ways on PC and mobile platforms. In such situations, it's essential to test these differences. A testing tool with capture/replay capabilities can help here.
Beyond the application and protocol differences, there's also the question of device security. Prior to BYOD, enterprises controlled tightly regimented fleets of PCs and servers, with common versions of operating systems, applications and antivirus software.
That level of control goes away in the wild and wooly world of BYOD, where devices run many different applications and operating systems (and possibly viruses and worms). The unknown and untrusted nature of BYOD makes security testing essential.
The published vulnerability tests discussed earlier are one way of determining device security. Another way is to test what resources devices can reach. Many enterprises use posture assessment system as part of their network access control (NAC) infrastructure. These systems are intended to check whether BYOD and other devices have the right versions of software, run the right level of antivirus patches, use the right Windows registry settings and so on. A good security test tool can assess the effectiveness of the NAC infrastructure by deliberately emulating "safe" and "unsafe" devices for remediation. [Also see: "Will BYOD revive the network-access control idea? Gartner thinks it will"]
With all the new applications and device types on enterprise networks, security testing is more important than ever. It's time for enterprises to take ownership of security posture assessment -- and find the risks before the attackers do.
Spirent Communications is a global leader in test & measurement offering an extensive portfolio of solutions to test data centers, cloud computing environments, high speed Ethernet networks and services, 3G/4G wireless networks and devices, network security, and global navigation satellite systems. www.spirent.com