search

OVAL-Community / OVAL

Official repository for the Open Vulnerability and Assessment Language
33 stars 26 forks source link

Add independent SQL512 test, deprecating SQL57 #153

Open vanderpol opened 1 month ago

vanderpol commented 1 month ago

Abstract NIWC has developed SQL Server content using the SQLEXT OVAL specification previously submitted to OVAL https://lists.cisecurity.org/empathy/thread/KP4JJ3BINRY3VSDH6FP7UQWYDM2G4IW5

We realize that the SQLEXT OVAL test is non-standard, as it provides the content author the ability to have the application create sets of results (xccdf/OVAL etc..) per host, per DBMS instance or per database, inside the OVAL object.

As the SQLEXT is used by SCC and has publicly available content, we would like to find a way to make this test officially part of SCAP. https://www.niwcatlantic.navy.mil/Technology/SCAP/scap-content-repository/

Our proposal is to move the decision point on when/if to create results based on 'host' or 'instance' or 'database to XCCDF 1.3 as part of SCAP 3.0.

Link to Proposal Once a proposal has been put into pull request form, add a link to the PR here. If and as alternate proposals or objections are added they should be linked here as well.

Additional context Add any other context or screenshots about the enhancement.

vanderpol commented 3 weeks ago

Potential XCCDF 1.3 spec updates to allow for benchmarks to define the scope for scanning, and result creation. 


<xsd:element name="target" type="cdf:targetType" minOccurs="0" maxOccurs="1" default="host">
     <xsd:annotation>
          <xsd:documentation xml:lang="en">For content targeting technology other than the entire operating system, content authors can specify the target type.  This selection may cause the SCAP processing application to create more than one set of results, one per target instance.</xsd:documentation>
     </xsd:annotation>
</xsd:element>

<xsd:simpleType name="targetType">
    <xsd:annotation>
        <xsd:documentation xml:lang="en"> The targetType represents the technology of the target that is in scope for being scanned, and can be a basis for creating separate instances of XCCDF results per target type.
        </xsd:documentation>
    </xsd:annotation>
    <xsd:restriction base="xsd:string">
        <xsd:enumeration value="host">
            <xsd:annotation>
                <xsd:documentation xml:lang="en">Target is the entire operating system and all applications of the host being scanned.  One set of results per host should be created.</xsd:documentation>
            </xsd:annotation>
        </xsd:enumeration>
        <xsd:enumeration value="dbmsinstance">
            <xsd:annotation>
                <xsd:documentation xml:lang="en">Target is a single DMBS instance on the host being scanned.  One set of results per DBMS Instance should be created.</xsd:documentation>
            </xsd:annotation>
        </xsd:enumeration>
        <xsd:enumeration value="database">
            <xsd:annotation>
                 <xsd:documentation xml:lang="en">Target is a single database of a single DBMS instance.  One set of results per DBMS Instances and database should be created.</xsd:documentation>
            </xsd:annotation>
        </xsd:enumeration>
        <xsd:enumeration value="webserver">
            <xsd:annotation>
                <xsd:documentation xml:lang="en">Target is a single webserver instance on the host being scanned.  One set of results per webserver instance should be created.</xsd:documentation>
            </xsd:annotation>
        </xsd:enumeration>
        <xsd:enumeration value="website">
            <xsd:annotation>
                 <xsd:documentation xml:lang="en">Target is a single website on the host being scanned.  One set of results per website should be created.</xsd:documentation>
            </xsd:annotation>
        </xsd:enumeration>
        <xsd:enumeration value="container">
            <xsd:annotation>
                 <xsd:documentation xml:lang="en">Target is a single virtualization container on the host being scanned.  One set of results per container should be created.</xsd:documentation>
            </xsd:annotation>
        </xsd:enumeration>
    </xsd:restriction>
</xsd:simpleType>
solind commented 3 weeks ago

I like this idea much better than the OVAL attribute!

vanderpol commented 3 weeks ago

Thanks David, and it's based in part on your feedback from years ago on our SQLEXL proposal. At the time, we were for some reason stuck with "it has to be done in OVAL" mindset, but in reality it makes much more logical sense (and programmatic sense) to do it in XCCDF. I'm hoping Dragos will agree that this attribute should be added to XCCDF 1.3, and then I'll submit a PR on SQL512

vanderpol commented 2 weeks ago

@dragosprisaca, I'd really like to hear your feedback on the potential of adding a 'target' or similar element to XCCDF. If this is possible for XCCDF 1.3, I'll proceed with this SQL512 proposal, schemas, etc...

dragosprisaca commented 4 days ago

@vanderpol Could you please provide an example of how the new 'target' element will be represented in XCCDF?

vanderpol commented 4 days ago

@dragosprisaca, based on my draft spec (scroll up on this issue to my post 3 weeks ago), I would think it would be implemented like the following (for our SQL DB benchmark)

<xccdf:plain-text id="release-info">Release: 3.1.3, Benchmark Date: 22 July 2024. Based on DISA STIG Manual V3R1</xccdf:plain-text>
<xccdf:platform idref="cpe:/a:microsoft:sqlserver:2016"/>
<xccdf:target>database</target>
<xccdf:version update="http://iase.disa.mil/stigs">3.1.3</xccdf:version>

And it would be optional, with a default value of "host", so 90% of benchmarks wouldn't need any changes at all, it would be transparent.

I think the primary challenge with this is making a sufficient list as to not be needing updates in the near future. I've heard others discuss the potential for some type of 'container', which may cover quite a few other technologies if needed.