OVAL® or the “Ideal Scanner Myth”

Greetings, colleagues.
The issue of automated security scanners is very acute in the "corporate" market of services.
Of course, who wants to check thousands of hosts manually?
Since demand creates supply, you can find them for every taste, color and budget.
They are designed to solve the same goals: compliance management.
Thereby saving corporations a huge amount of money with the mass standardization of PCI DSS and similar standards.
They are all so different, but still they have one thing in common : sheer anarchy and confusion in the format of reports, inventory results and content for updating. As each group of programmers came up with, it was done. This situation leads to the fact that it becomes extremely difficult to compare security scanners. And there is no question of using the data accumulated during the use of product “A” when switching to product “B”. How, where not to go, everywhere “commercial secret” and “intellectual property”. The solution, my dear reader, is obvious: standardization of input and output formats at all stages of the scanner activity. This is precisely what is described in the Open Vulnerability and Assessment Language (OVAL) standard.


In order not to dive anew into the basics and basic terms, I would like to note that I told about OVAL in my last article . Therefore, it is worth her to look, that would not be confused in terminology.
Actually, summarizing the stated theses, one can understand the following: the desire to make information security “measurable” is possible only with complete standardization of information at all stages of its passage through the scanner. Why is it still not done? The answer is as simple as it can be within the “bubble” of information security: it is not beneficial to the creators of security products. As long as the inventory process, finding vulnerabilities and making decisions about their presence remains the “black magic” of each particular company, their products will firmly hold the “market” without fear of criticism and invasion of competition.

In other matters, we will not be so categorical. The process of formalization of knowledge in information security for each company will require such large resources that it fully justifies them. After all, to translate 100,500 scripts into “definition”, “object”, “test” and “state” is a big job that requires a lot of “person-months”.
')
So what is this " perfect scanner "? Which will satisfy all the requirements of regulators and can finally make security “measurable”. The answer lies at a depth of a meter from the surface, and is described in the OVAL documentation . The key to victory is the use of formalized constructions at all stages of scanning. And this is not my fantasy, but quite a workable scheme proposed by MITER :



Thus, we get the "template" designs at each stage. What are the benefits of this? Nevertheless, it is obvious: we scan the system with the scanner “A”, then with the scanner “B” and see that the advertised foreign product did not find half of the installed programs. And his rival confused Windows and Unix in general.

The transparency of the result and the comparability of the reports are the main advantages of such a scheme.
Forced to describe the entire scan sequence as an OVAL-definition, authors will be able to show why a decision was made. Not “Alarma! you have vulnerability CVE-2034-100500! ”and the decision tree revealed:“ You have vulnerability CVE-2034-100500 because you have Solaris 15, Firefox 22 version 1.1.23 is installed and no security patches 13455-10 are installed ” . Agree, from the point of view of the user, this situation is much more “tasty”. As a bonus, we get full compatibility with both update information for audit checks and host inventory results.

“And where is security software developer?” You ask. And he remained in his place: in scripts that implement the execution of certain tests. Being an extensible language, OVAL is allowed to set its own abstract types, requiring only their formal description as a mandatory condition. Therefore, the "bottoms" remain securely hidden. The test “check in the / var / log / messages file for the presence of LinBackDoor backdoor” and not the script that implements it is alienated.

To summarize : the implementation of the standards of the OVAL language at each stage of scanning will not harm the vendors. But it will make “transparent” scan results and allow you to directly compare information security products. Thus, we will achieve the task: to make security “measurable”.

Thanks for attention.