- So Many Tools...
- New Standards and Guidelines
- Commonalities Among Scanning Tools
- Same Scanning Engine, Different Data?
- Compliance Is Not Security
- Where Do We Go From Here?
Same Scanning Engine, Different Data?
Current products are generally evaluated and purchased based on the performance of the scan engine as well as the evaluation criteria used to assess the security of your systems. I'm beginning to wonder why we need so many engines. The basic engine is the same. Why don't we just buy the data feeds?
Right now everyone comes up with their own criteria and methods for testing and analyzing systems. Some methods are obviously more successful, more accurate, and more thorough than others. By now, however, the basic scanning engine has been well tested. Sure, there may be some innovations that allow multi-threading, better memory usage, bandwidth throttling to avoid network congestion, and various manipulations of the packets to bypass firewalls and filtering schemes. But the basic machine is running well. I can see the market for a small handful of scanning engines, but what if they all supported a similar framework for the test criteria?
The various companies would compete on the merits of their test methods and results. They could license the regular updates just as they do now, but you wouldn't necessarily be tied to their scan engine. You could pick the scan engine that best suits your needs, and pair it with the data feed that is most appropriate. I can envision feeds for patch management, vulnerability scanning, database scanning, web application testing, configuration baselines, and policy compliance.
I think it might even be possible to apply a similar model to antivirus/antispyware software, and perhaps intrusion detection systems (IDS). The engine for each would be different from the basic scan engine, but the licensing model could be applied.
Even if none of this happens, the standardization alone can be of great assistance as long as everyone remembers that standardization alone is not security, per se.