Got Discipline?

Of course, outside requirements come into play too. Although there's no magic bullet that will make your organization compliant with HIPAA, the Gramm-Leach-Bliley Act or ISO 17799, you can interpret applicable portions of the regulations into policies that can then be enforced and monitored (see "Complying With the Feds,"). Our motto: Speak softly and carry a big yardstick.

Let's Focus

Sheer volume and complexity can make monitoring servers and desktops a nightmare. If you're a Windows-only shop and your desktops and servers are in a domain or Active Directory tree, Windows' Group Policy Object or SMS (Systems Management Server) might be sufficient to ensure policy compliance. However, once an environment becomes even slightly more complex, the task of monitoring becomes much more difficult.

We talked with an IT manager from a multinational petroleum company that deploys more than 4,000 servers and 70,000 workstations worldwide. Although many of these hosts are Windows computers spread across multiple domains, a number of servers and workstations are standalone. Even with tools embedded in Windows and an SMS deployment for desktop management, this organization spent a lot of time writing scripts to gather data from hosts across the network and used Excel spreadsheets to generate reports. A system engineer devotes one weekend per month to running reports--on topics such as disk usage, service pack and patch levels, and security policy configuration.

On the other end of the spectrum, a small hospital with 2,000 workstations, 40 servers, and an IT staff of five needed a view of workstation and server configurations and wanted to create reports showing user access in the file system and tracking access to specific files across the network. It needed to query configuration on Novell's eDirectory and NetWare 6, and Windows 2000 and NT servers and desktops, but did not have the developers to write custom scripts--it wanted a COTS (commercial, off-the-shelf) product.In both cases, these organizations wanted to ensure--independent of the operations staff--that desktops and servers were configured as defined by their security policies. They also wanted to monitor patch compliance and generate reports pinpointing out-of-compliance hosts. Two organizations of different sizes and in different markets had similar reporting and management needs, none of which were met by existing applications. Sure, developing policies and then extrapolating compliance rules is no small undertaking (for help see "Control the Keys to the Kingdom," and "Chart a Plan for Security"), but there are many benefits to be had from policy-compliance monitoring, including:

• Ensuring end users follow the rules. For example, if your access policy requires that all passwords be eight characters, changed every 30 days and not be repeated, you must be able to pinpoint users who are not in compliance with the policy so that you can have them executed. Just kidding.

• Maintaining separation of duties. Tiered management access ensures separation of duties between monitoring and management. We recommend that security administrators monitor desktops and servers for configuration compliance. Optionally, configuration access can be granted for trusted security administrators or desktop/server administrators.

• Bringing about increased responsiveness. You must be able to respond quickly to changes that affect your security stance. For example, if a new vulnerability can be solved by creating a new registry key, can you ensure that the key was created and properly set to the right value across your enterprise? If not, you have a problem.

Remember, honest mistakes as well as malicious attacks can leave your organization vulnerable. Monitoring policy compliance keeps potential problems at the forefront of administrators' minds. Often, security updates and patches break some critical functionality on a server. In such cases you have four choices: do nothing, patch, find a workaround or persuade the application vendor to fix the problem so the system can be patched. No matter which you choose, turnaround time may be long. Forgetting about an unpatched system is all too common.In addition, once you have developed and deployed a security policy, compliance tools can ensure that apathy doesn't set in. It's human nature to move on to the next big project. Plus, personnel turnover will have less of an impact on your security if policy monitoring strategies are in place.

Details, Details

Once you start monitoring for compliance, remediation is a natural progression. Technically, it doesn't matter which application makes changes on desktops and servers. In reality, organizational hierarchy dictates a separation between operational and security duties. Controlling access to the policy-compliance application is critical so that only authorized people, such as security administrators or auditors, create and run reports, while desktop operations staff run reports and make changes to target systems, for example.

Although desktop-management packages and home-grown tools provide some basic functionality, the consolidation of reports and the redundancy of effort is costly. If you have multiple platforms and multiple levels of security, and you need to get a handle on your security and protection procedures, you should be looking at policy monitoring. Our review of policy monitors begins here.

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. Write to him at [email protected].Post a comment or question on this story.

Security Policy Monitoring

It may start innocently enough, perhaps with a user installing a seemingly innocuous piece of software on a networked enterprise PC. This might annoy the desktop people, but as the security manager, it's not your problem, right? Wrong. Can you be sure that the application did not change vital configurations on the machine, possibly making your entire network vulnerable? Worse, if your security policy is not continually enforced, such a hole might go unnoticed indefinitely. And even if your desktops are locked down tight, HIPAA requires all health-care organizations to have a system in place ensuring the security of all patient information; the Gramm-Leach-Bliley Act makes similar demands on financial institutions. Security policy enforcement, clearly, is taking on new urgency.

The best way to stay in the Feds' good graces is security policy monitoring, whereby you lay down the law across your organization and then constantly audit for compliance. We gathered security policy monitors from BindView, Computer Associates International, Configuresoft, NetIQ, Pedestal Software, Polivec and Symantec in our Syracuse University Real-World Labs® and deployed them on a 100-node network. In the process we nailed some hideously out-of-compliance production systems. Ouch.

After a few months of poking and prodding, we were impressed with all the products we tested. Price was, of course, a factor--this level of control does not come cheap. Still, each allowed for stringent compliance checks and offered strong reporting; some even helped us write policies via templates and could proactively slap around deviant systems. We awarded BindView's bv-Control 7.2 our Editor's Choice for its all-around strong feature set. Shops with tight budgets should take a look at our Best Value Award winner, Pedestal Software's SecurityExpressions 3.0.If your organization is in the financial or health sector, you no doubt are familiar with the Gramm-Leach-Bliley Act (GLBA) or the Health Insurance Portability and Accountability Act (HIPAA). Both mandate specific actions to protect the security and privacy of customer and patient information, respectively. They affect how organizations collect, store, transmit and allow access to nonpublic information that can be individually identified to a customer receiving a financial product or service or a patient receiving health care. But neither act spells out specific hardware or software solutions that you need to implement to comply with the law.

IT is good at providing practical solutions to network management and security problems. Many of the technologies that apply to both GLBA and HIPAA, such as authentication schemes for identity management, encryption for data transmission, secure VPNs for remote access, and access controls for data storage, are in place. But IT is not so good at documenting the solutions used to meet the legal requirements in laws like GLBA and HIPAA. And that's where policy management can help.Policy-management tools, such as BindView Policy Operations Center, bring together policy templates linked to specific requirements of GLBA and HIPAA. These templates can be used to form a written policy that addresses legal requirements. In the case of GLBA, it can be tailored for the size and complexity of your organization. For HIPAA, it can scale to the cost of the solution. These policy tools not only apply the law, they also suggest industry practices to bring you toward compliance. For example, if your enterprise uses WLANs, BindView suggests IEEE WLAN security features, including WEP (Wired Equivalent Privacy), and MAC (Media Access Control) filtering to protect customer information and assets. It also includes asset-protection standards for devices, such as firewalls and routers, and operating systems. --Sean Doherty

Resources

• GLBA Interagency Guidelines Establishing Standards for Safeguarding Customer Information

• HIPAA Privacy Rules, aspe.os.

• HIPAA Security Rules• "Final HIPAA Rules Hit the Street," (InformationWeek, Feb. 13, 2003)