Replace OVAL with an imperative lanuage

[redhatrises]

#85 asks the question about SCAP integration. With the development of OSCAL, this would be a good time to replace OVAL with an imperative non-XML language. XML is not recommended for machine language and processing it is difficult and too bulky for machine processing. With how OVAL is currently written, it is extremely difficult and complex to handle cases like apache with its multiple includes, configuration files, and virtual host configurations not to mention that OVAL does not scale well in a world or multiple types of containers and cloud technologies. An imperative language that is simple and easy to use and understand would make this easier and solve multiple problems as well as increase usage in the community and market at large.

A possibility would be to use a sand-boxed version of Python which would be vender-neutral, allow for it to be easily integrated into scanners, and a simple language that is easy to use and implement.

[mpreisler]

A possibility would be to use a sand-boxed version of Python which would be vender-neutral, allow for it to be easily integrated into scanners, and a simple language that is easy to use and implement.

+1

A sandboxed python with well defined limited API that the scanner vendors would have to implement is a good bet I think. Should make security guides much easier to write and debug.

[trevor-vaughan]

-1

There is a reasonable chance that my local security policy will not allow me to deviate from the OS baseline. I can process a markup format in many ways that are probably on my system, I may not be able to use a given language or version of a language.

An API should be implemented with plugins for all of the most common scripting languages in use at this time if this is a route that we want to go down.

[trevor-vaughan]

@redhatrises There is currently a project for this called InSpec that the SIMP project moved to because the present OVAL implementations were not flexible enough for end users.

[david-waltermire]

IMHO, we have way too much to do around control assessment in this project to work on a new language. I think the best way forward is to make how OSCAL references mechanisms for deploying and verifying a configuration related to a control modular. That way software and service providers, and system implementations that provide OSCAL content can make use of the appropriate mechanisms that are commonly used on a given platform. We still need to work out how to do this.

[redhatrises]

@trevor-vaughan InSpec is not vendor neutral. But @david-waltermire-nist is correct with how much other stuff needs to be done first. Maybe this gets passed on to Chef, Ansible, Saltstack, GPOs, etc. rather than creating something new, and the content just says how to use these technologies to check and validate that something has been changed correctly.

[trevor-vaughan]

@redhatrises It appears to be vendor neutral as far as I can see in terms of an open community, FOSS, etc... You suggested a sandboxed Python stack, it's a sandboxed Ruby stack so, besides the language being used, seems to meet the original suggestion.

I think that specification should happen here and implementation should happen elsewhere. To do otherwise would be stepping into spaces that already have large open (and commercial) vendor offerings.

[david-waltermire]

@trevor-vaughan and @redhatrises, I share the notion that we should focus efforts on the specification here and allow for implementation elsewhere. Ongoing work on improving documentation is needed to support this.

[david-waltermire]

Closing this issue due to inactivity.