Then there’s the care and feeding of the controls themselves which I believe is your point. I’ll blog in a future entry in more detail, but let me give you an idea of what my research shows will happen over the next 3-8 years. In short, why should it require a team of people to program firewall rules when the application already knows what it needs to communicate on the network? We’ve got it backwards. Rather than manually apply these policies as these applications are put into production, why not gather the requirements directly from the application (via static analysis of the source code) from the developer (in the form of annotated models/metadata) or from the business analysts (also in the form of models/metadata). As long as what the application requests conforms to policy, why do we need to manually enter this after the application is developed when all of this knowledge was available in the development cycle?

This note explains the concept in detail and I’d be glad to talk to you about multiple vendors and offerings that are showing this is possible — today.

http://www.gartner.com/DisplayDocument?id=525109

On false positives, I’ll defer to my colleagues that cover IPS in detail – however, a) the technology has matured to the point where the use of out of the box rules and filters (“high-fidelity”) will produce very few false positives. For example, the use of ‘vulnerability-facing filters’ is an example of an approach that provides effective protection with few false positives. Log monitoring can be consolidated with a SIEM or similar (or outsourced).

In a virtualized compute environment, do you think the likes of VMWare, Microsoft, Citrix etc. can do more than having zoning around a trust construct (vShield) or anything beyond making sure ABI is confirmed too (Determina).

If not then security in the virtual world will continue to rhyme with that of the physical world.