By now you should know there is no silver security bullet. The defense-in-depth strategy dictates that, starting at the network edge and moving in toward your most important assets, your defenses should become more restrictive and tightly tailored to specific security problems. For example, a stateful packet-filter firewall, such as Check Point Software Technologies' VPN-1 Pro or Cisco Systems' PIX, is fine on the edge, but as you move closer to Web and e-mail servers and other critical resources, application proxy servers, such as Secure Computing's Sidewinder and Symantec's Enterprise Firewall, provide tighter control--though often at a performance expense.
But defense in depth, while important, is still mainly product-focused--what widgets get deployed where. Before you even get that far, focus on the three pillars of network security: authentication, access control and auditing.
Authentication: Who Is It?
Authentication plays a big part in most of the security products we test (see "Authentication Gets Tough"). It's a myth that passwords are not adequate protection for many applications. With the exception of biometric devices, nearly all authentication comes down to a password (a PIN is, after all, just a numeric password). For example, digital certificates, often thought to provide strong authentication, are protected by weak passwords. Although they're well-suited for targeted, high-value applications, both biometric readers and security tokens, including USB tokens, are still too expensive and cumbersome for wide deployment. Passwords, on the other hand, are relatively inexpensive and have nearly universal support.
But passwords fail because users pick easy-to-guess passwords--even when they are forced to use symbols and numbers. And precious few security applications--including firewalls, VPN systems, PKI tools, disk- and file-encryption schemes and IDSs--let you enforce password complexity. Luckily, with the ubiquity of LDAP-enabled services, we may see a move back toward single sign on, with the directory consolidating user authentication.
Access: Who Can Do What?
Access control can be dealt with on many levels, each particular to who is attempting to do what. Typically, access-control products restrict user access to OS objects and program functions. However, many technologies-- firewalls, VPNs and even antivirus products with active scanning--are, in reality, access-control products.
Firewalls, with the exception of a vendor's firewall client, generally don't provide user-based access control. However, the closer you can place firewalls to destinations or sources, the tighter you can control access. For example, perimeter firewalls control access for all the nodes they protect, and that leads to the "hard candy shell/soft, chewy middle" syndrome. In contrast, multiple firewalls throughout your network mean multiple defenses to break through. Desktop firewalls are making great strides in pushing security to the edge. Products from InfoExpress, Symantec and Zone Labs provide not only port blocking but application network-access control and privacy protection (cookie management and ad blocking, for example). The protection is not perfect; in fact, a well-written e-mail virus could defeat most of these products. But the theory is good--place access control, for both users and applications, close to the edge, where many of the problems lie, and target user and process access control (see "Defense Mechanisms").
User access control can be managed via education and finely tuned systems. But the crux of the matter is that you need to tighten access control at the OS level through sandboxing. Application sandboxing defines a set of resources, such as memory, disk space, network ports or calling other applications, that an application can access. The application cannot go beyond its boundaries. Typically stated in a positive manner, such as "Only Microsoft Word is allowed to write to .DOC files," sandboxing protects your critical systems from modification and exploitation. Although the products in this market are still young, expect the time spent properly configuring and deploying application sandboxing to pay off the next time a worm tries to crawl across your network.
Auditing: What Did What?
Authentication and access-control processes lose effectiveness when you lose track of who is doing what. The more you audit, the more you have to review: Firewalls, IDSs, routers and authentication servers spew tons of audit logs daily in a slew of formats containing all kinds of data.
But there are two distinct but related challenges with audit data. The first is aggregating data from multiple sources into a central repository. This is simply a matter of processing power, storage and integration with typical and proprietary reporting formats. The second is processing and correlating disparate events, and presenting the data for human consumption. The latter part is by far the harder task because the traffic patterns have to be defined, the events have to be identified across platforms, and intelligent connections have to be made to decipher the events. Security information management, or SIM, is still in its infancy, but the promise is clear--the data that can be mined from your network devices can go a long way toward getting a grip on security (see "Connect the Dots").
Your Mission...
Athletes, musicians and other professionals will tell you that practicing the basics--throwing fastballs or playing scales--keeps their skills finely honed. If the basics suffer, so do the advanced skills. Same is true for network security. To reduce your vulnerability to attack, keep going back to basics. Do vulnerability analyses to see what resources are ripe for attack. Lock your servers down tight with as few permissions as possible. Don't accept the defaults of any installation without understanding what the defaults mean. Restrict network and server access--inbound and outbound. Deploy virus scanning on mail and file servers and on the desktop, and keep your virus data files up to date. Treat remote-access users as hostile, and limit what they can do. Log everything.
But security can't be laid entirely at the network manager's feet. Vendors must focus on the basics as well. Their programmers and system designers should follow good coding practices. Buffer overflows are all the rage in the press, but other conditions, such as improper use of temp files, race conditions and program logic flow problems, can open a door. If vendors are using externally developed libraries, they should do their own QAs on the libraries to make sure their software isn't compromised, as happened with the zlib double free vulnerability.
Vendors should take the possibility of attacks seriously. They should design security into every product from inception, not as an afterthought. And if they don't do so, hit them where it hurts and take your business elsewhere.
Mike Fratto is a senior technology editor based in Network Computing's Syracuse University Real-World Labs®; he covers all security-related topics. Prior to joining this magazine, Mike worked as an independent consultant in central New York. Send your comments on this article to him at mfratto@nwc.com.
RSS
