This article can also be found in the Premium Editorial Download "Information Security magazine: Comparing five of the top network-based inline IPS appliances."
Download it now to read this article plus other related content.
Now comes the tricky stuff: understanding the relationship and connection points between the devices you find. Without this understanding, you simply have a laundry list of gadgets. But knowing how they work together can give valuable insight: for example, during an incident response exercise, this type of data can help explain how a worm is propagating, which machines are spreading it, and how it gained entry in the first place.
This is where correlation is key. By aggregating data from a variety of sources, including application logs, system logs, traps and alerts, correlation tools help administrators track relationships between devices on the network. To ensure a correct comparison, the information is then normalized, or parsed, and put into a standardized format. From there, correlation rules are applied to identify relationships and causality, thus providing a more intelligent view of the network's vulnerability.
|Regulatory Compliance Dashboards--What's Realistic|
Let's face it, compliance is a hassle. Nobody likes the time required to audit or the expense of documenting controls. As such, nothing sounds more appealing than a vendor offering a "point, click and comply" solution. Public companies could go with a SOX suite, banks a GLBA solution, and federal agencies could pick one or more add-ons from the FIPS series. Sounds great. But how realistic is that in practice?
Unfortunately, there are no drag-and-drop compliance solutions. The regulations don't define specific success criteria to which a vendor can write. For example, SOX requires, "an assessment...of the effectiveness of the internal control structure and procedures of the issuer for financial reporting." Not only does this requirement encompass all the systems used in the financial reporting process--everything from legacy mainframe systems to the Excel spreadsheets used in the accounting department--but it even extends outside IT. One vendor cannot realistically offer a solution that ensures the effectiveness of non-automated processes.
That's not to say that no vendor can provide compliance value, however. Those that offer systems dashboards that report on workflow, monitor system activity, or report policy violations offer tremendous compliance value. That's because once an enterprise determines what constitutes compliance in its environment and has a handle on where its ineffective processes are, streamlining and refining automation efforts are a huge win. Not only does an improvement in these areas help meet the current regulations, but it safeguards the enterprise for future regulation. As such, systems dashboards expedite audits and boost administrator confidence.
-- By Diana Kelley & Ed Moyle
Not every post on Bugtraq is a reason to panic. Eight vulnerabilities, on average, are discovered daily. Trying to respond to each and every newly discovered vulnerability is a waste of time and resources, since only a small fraction of new vulnerabilities will actually apply to a given enterprise. AIX vulnerabilities aren't a concern to an AIX-free enterprise; IIS vulnerabilities aren't a problem if you're an all-Apache/Tomcat shop. Even if the vulnerability is in a deployed application or operating system, it only applies to unpatched machines or machines with a particular service enabled rather than the entire population.
How do you know which vulnerability reports apply to your environment and which do not? Validation. Validation tools confirm which devices in the network are truly vulnerable and distill the vulnerability data into a focused list to help determine which vulnerabilities merit action. Validation compares information about the vulnerability against information about the environment. If the vulnerability matches what the enterprise has deployed, the vulnerability is flagged as requiring administrator attention. If not, the vulnerability is disregarded.
The next step is taking remedial action to keep vulnerable machines safe from threats. Specific steps will vary from vulnerability to vulnerability, but remediation typically includes applying patches, changing application or device-configuration settings, and applying filtering techniques such as firewalls, VLANs or other segmentation techniques to restrict traffic to the machine. When using remediation tools, think carefully about the level of automation that is appropriate. For example, do you perform regression testing on critical applications before deploying a potentially conflicting patch? What patch workflow requires buy-in from teams that currently maintain the process? And what about auditing? Ensuring that automated actions are audited is extremely useful during application debugging.
Look Before You Leap
Ready to buy VM tools? Before you commit, make sure you have your gear and your plan of action in order. Just like a skydiver, enterprises deploying a VM solution don't want to find out halfway down that something doesn't work.
This was first published in October 2005