[Open-scap] picture

[Kevin Sitto]

Hi Peter,

I like your ideas, the notion of using lib_openscap to provide an abstraction layer around the raw SCAP content definitely seems like something which would provide alot of value.

One thing I'd like to propose is that we provide both data abstraction and functional capabilities within lib_openscap.  The matter of providing functionality in addition to data abstraction is largely academic with the "enumerations" as this functionality is largely related to loading the abstract data types but becomes pretty significant as we start to look towards OVAL and XCCDF.

For example:
 
lib_openscap.CVE eventually provides the following:
structs:
CVE
functions:
LoadFromNVD
LoadFromFile
 
lib_openSCAP.OVAL provides something along the lines of:
structs:
OvalDefinition
OvalTest
OvalCriterion
OvalObject
OvalState
OvalTestResult
etc.
functions:
load_definitions
export_characteristics
export_results
ProbeObject
ResolveTest
etc.
 
In other words, the only tweak I would propose to the architecture you've defined is moving the directly OVAL related capabilities within scap_daemon down into the OVAL library within lib_openscap while leaving the higher level functionality of actually staying memory resident, monitoring for incoming signals, sending results to a server and other such facilities to scap_daemon which is basically our prototype for an app that would live in that top layer (what I believe Net-Centric folks like to call the "utilization layer").
 
What do you think?
 
Kevin


-----Original Message-----
From: open-scap-list-bounces at redhat.com [mailto:open-scap-list-bounces at redhat.com] On Behalf Of Peter Vrabec
Sent: Wednesday, February 11, 2009 10:54 AM
To: open-scap-list at redhat.com
Subject: [Open-scap] picture

Hi folks,

I drew a draft of what we doing here, just to make things clear. Or it might be a good start point for discussion.

small explanation:
- library provide interface to SCAP standards, it can parse different xml files and provide their content via abstracted data types to the applications. That's what we do for CPE and CVE. CVSS is a different case.

-applications, for example scap_daemon can load OVAL definitions using the library. Than they can process the objects, create system characteristic, and finally export the characteristic by library function.

- in the end there might be different front-ends for things like scap_daeomon, but that is a different story.

Q:
- How do you like it? :)
- Should library provide some more functions besides "load" and "export"?
- Where should the process of creating system characteristic be placed, inside or outside the library(as it's shown in the picture) ?

I'm looking forward each reply :)
Peter.










-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/open-scap-list/attachments/20090218/45a2819d/attachment.htm>