Automated Security Management

What is it?
A system that collects data from security- and systems-management tools, then automates the process of fixing holes or vulnerabilities in the security of servers, workstations and network infrastructure.

Why should I care?
Technology managers have learned that having a security patch available for a newly discovered vulnerability isn’t enough; they have to make sure it plugs one hole without opening another one, and that it’s installed on every vulnerable machine. Managing patches across different hardware and software can be backbreaking. Automated security management (ASM) is designed to take much of the grunt work out of fixing security bugs. That should free up more resources for testing patches before they go out—preventing would-be fixes from rendering important applications useless.

How does it work?
Automated security-management systems are supposed to integrate data from application and network security-assessment software, configuration-management systems, firewalls and other security “appliances” to build a comprehensive picture of the state of security in a corporate network. Then they search for known holes in security, blocking potential attacks on those holes, and apply bug patches and configuration changes to fix them permanently. Security-management servers can receive alerts about new vulnerabilities and automatically download patches. Alternatively, subscription-based Web services can deliver both alerts and patches. To ensure that patches won’t cause new problems, ASM software holds new patches in quarantine until they’ve been tested by administrators, and only then deploys them to servers and firewalls. Problems that can’t be handled automatically are turned into trouble tickets and passed to helpdesk staff or software developers.

What makes it work?
Lots of software and some emerging standards. A key element is the Application Vulnerability Description Language (AVDL), an XML-based specification being developed by the Organization for the Advancement of Structured Information Standards. It’s designed to standardize the way vulnerabilities are identified by security-assessment software, monitoring tools, configuration-management tools, and security devices such as intrusion-detection systems. Secure Hypertext Transfer Protocol and Web services play a role, providing information and patches to agents residing on managed systems. And subscription-based Web services can deliver vulnerability data from vendors and security organizations to assessment tools.

What’s the downside?
The AVDL is a work in progress. A final specification was due in December, but had not been posted as of January. Most other security tools can trade information with products of similar function, but many have limited integration with existing system-management tools. Agents for each type of software are proprietary, and need to be written specifically for each application or operating system they support. Also, the market is fragmented: Only a few vendors, such as Citadel Security Software, provide a great deal of automation in a single product.

What’s next?
Solidification of the vulnerability language standard and wider acceptance. Also, the emerging Data Center Markup Language (DCML), a widely supported effort to standardize how system configurations are set, may lead to better integration of existing systems-management and security tools, and may connect to or incorporate the vulnerability language.