[Xccdf-dev] Fwd: [OVAL DEVELOPER] SQLEXT OVAL Extension Proposal

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

[Xccdf-dev] Fwd: [OVAL DEVELOPER] SQLEXT OVAL Extension Proposal

David Solin-3
I had previously replied only to Douglas; I am forwarding that response (below) for any community feedback.

Begin forwarded message:

From: David Solin <[hidden email]>
Subject: Re: [OVAL DEVELOPER] SQLEXT OVAL Extension Proposal
Date: October 1, 2015 at 6:03:34 PM CDT
To: "McIlroy, Douglas M CIV SPAWARSYSCEN-ATLANTIC, 58600" <[hidden email]>

Thanks for your insights, Douglas.  Please see my own thoughts inline, below.


On Oct 1, 2015, at 4:04 PM, McIlroy, Douglas M CIV SPAWARSYSCEN-ATLANTIC, 58600 <[hidden email]> wrote:

David,



Yes, this SQLEXT proposal supports behavior for addressing individual RDBMS instances (the term "instance" as used here refers to any query-able server process spawned by a given DBMS software installation) and named database schemas as top-level targets, and then outputting a dedicated result file for each target. Furthermore, SQLEXT is indeed a platform-agnostic SQL probe that can support DBMS products other than Microsoft SQL Server. The following Oracle, MySQL, and PostgreSQL documentation provides guidance for configuring multiple instances of a given DBMS on a host system:



https://docs.oracle.com/cd/E11882_01/server.112/e40540/startup.htm#CNCPT89033



https://dev.mysql.com/doc/refman/5.0/en/multiple-servers.html



https://opensourcedbms.com/dbms/running-multiple-postgresql-9-2-instances-on-one-server-in-centos-6rhel-6fedora/



Of course most (if not all) databases support running multiple instances on the same machine.  But apart from MS SQL Server, I don’t believe they are readily discoverable.  To determine which instances are running, for Oracle or MySQL or Postgres, it would be necessary for a tool to discover running processes, read their environments and command-line parameters, and reverse-engineer their configurations, in order to determine how to connect to each.  If the instances are not running at scan-time, then all bets are off.

This makes the implementation of <instance operation=“pattern match”>.*</instance> VERY problematic.




Also, other DBMS's aside from MS SQL Server, such as MySQL, do support hosting multiple named DB schemas per instance. One common counter-example, though, would be Oracle Database, which allocates an instance for each database schema, leading to the concepts of an Oracle DB "instance" and "database" being effectively equivalent. Therefore, the "instance" and "database" context behaviors would be interchangeable when being implemented for an Oracle DB evaluation.


Indeed, some do.  But to discover their names, you must first connect to a server instance in a management context.  And connecting to an instance without all the connection information is problematic.

Perhaps you're actually proposing that the SCAP scanning utility should be pre-populated with lists of all the instances on each machine, and how to connect to them.  That would eliminate the discovery problem, but I didn’t get that impression from the proposal.


Furthermore, in light of the lack of traction that the SQL57 spec has seen so far, we are not sure how productive attempting to augment it any further would be. Not much so far has come of attempting to incorporate SQL57 into the DISA STIGs due to the inflexibility and insecurity of the "connection_string" entity, so SQLEXT is being proposed as an alternative that addresses those complications.


I have to say, since it has always been possible to provide a connection_string value via an external_variable, I’ve personally never really understood the complaints.  Is it that the variable values would appear in the results?  The mask attribute might address that.

In the case of Joval, it’s possible to supply a connection_string with no username/password at all, in which case we use the credential supplied for connecting to the target machine.  In practice this can actually be useful when scanning MS SQL Servers that have been configured to leverage the Windows user account database.  We have had some success running the CIS MS SQL Server content through our product using the existing features.




Also, while extending XCCDF to support multiple top-level evaluation targets per host system is a great idea, we needed to pursue a solution that would be available in the near-term and that would support raw-OVAL evaluations that don't include an XCCDF benchmark. However, given that leveraging XCCDF to control the content processing model of a SCAP stream makes more sense than SQLEXT's raw-OVAL top-up approach, an update to the XCCDF spec would be welcome. Especially when considering other non-RDBM applications such as IIS, Apache, and Tomcat that also support being instantiated multiple times with a dedicated configuration for each instance, there definitely needs to be a discussion about how to make SCAP overall more fit for enterprise-grade applications.


I agree.  From a technical standpoint,  a non-standard upgrade to XCCDF should at least be no “worse” than a non-standard addition to OVAL.




________________________________
From: David Solin [[hidden email]]
Sent: Wednesday, September 30, 2015 5:28 PM
To: McIlroy, Douglas M CIV SPAWARSYSCEN-ATLANTIC, 58600
Cc: [hidden email]; [hidden email]
Subject: Re: [OVAL DEVELOPER] SQLEXT OVAL Extension Proposal

Hi Doug (and cross-posting to xccdf-dev),

I’m not really able to easily discern from the samples on Github… but, recalling the sql511 proposal, is the thrust of this proposal that the behaviors result in splitting out per-host, per-instance or per-database (depending on the behavior specified) into different result files?

Notwithstanding the answer to that question, I have a few initial thoughts:

This is not really a generic SQL test at all, but a Microsoft SQL Server test.  Only MSSQL has readily-discoverable instances.  Other RDBMS’s do not really have readily-discoverable instances, and also, they do not all support having multiple ‘databases’ within a single instance.  This was sort of the sole virtue of the connection_string — it identifies the target instance.  (This is also why both generic database-connectivity mechanisms I’ve personally used, ODBC and JDBC, support the concept of connection properties).

This appears to me to really, at heart, be a proposal to delegate instance/database discovery to the OVAL language.  It is certainly already possible using external_variables to target a piece of OVAL content to whatever combination of instances and databases one pleases — provided that those instances and databases are known to the tool that is doing the targeting (by setting the variable values).

If this is indeed the case, and if databases should indeed be treated as first-class targets, then it would make perfect sense to create entire SCAP benchmarks dedicated to evaluating databases, and measure compliance of each instance against that benchmark, rather than (as this proposal embodies) attempt to combine what should be multiple first-class target assessments into a single machine assessment result.

As an alternative to this approach, I would propose making a few changes to XCCDF and SCAP that would make it possible to do exactly what you guys want and leverage the existing sql57 test:

1.  Create selRefType and selComplexRefType types in XCCDF that make it possible to reference an exported value from a check system
2.  Add support for the XCCDF ComplexValueType in SCAP — defining it as a mechanism to evaluate multiple instances of a check evaluated via the multi-check attribute, or if via a complex-check, according to the complex-check’s operator attribute.

Was this an approach you guys have considered?  I’d be happy to collaborate with you to make these changes to XCCDF.  We could call it XCCDF 1.3.

Best regards,
—David Solin



David A. Solin
Co-Founder, Research & Technology
[hidden email]<[hidden email]>

[Joval Continuous Monitoring] <http://jovalcm.com/>

[Facebook] <https://www.facebook.com/jovalcm> [Linkedin]  <https://www.linkedin.com/company/joval-continuous-monitoring>


On Sep 30, 2015, at 11:41 AM, McIlroy, Douglas M CIV SPAWARSYSCEN-ATLANTIC, 58600 <[hidden email]<[hidden email]>> wrote:

Due to the need for automated compliance and vulnerability checks against SQL database management systems and a lack of support for the proposed sql511 test in OVAL 5.11, SPAWAR submits this new proposal for an OVAL extension which addresses the sql511 deficiencies. The current working designation for this proposal is “sqlext” (SQL Test for the OVAL Extension Schema). This is subject to change based upon discussion with the OVAL community regarding standard naming conventions for OVAL extensions. Please see the attached proposal document for further explanation as well as the SQLEXT OVAL Sandbox GitHub fork (https://github.com/mcilroyd/Sandbox/tree/master/resources/x-ind-sqlext) for sample content, results output, and XML schemas. We are looking forward to any feedback and recomendations that the community has to share for SQLEXT.

...<SQLExt Proposal.pdf>_______________________________________________
OVAL_Developer mailing list
[hidden email]<[hidden email]>
http://lists.cisecurity.org/mailman/listinfo/oval_developer_lists.cisecurity.org

<jovalcm.color.225.png><fb.rounded.png><li.rounded.png>



_______________________________________________
XCCDF-dev mailing list
[hidden email]
To unsubscribe, send an email message to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: [Xccdf-dev] [OVAL DEVELOPER] SQLEXT OVAL Extension Proposal

David Solin
Doug,

I have not forgotten your SQLEXT proposal for the OVAL language, and have been working on some XCCDF/SCAP ground-work that is required before I suggest updates to the XCCDF schema itself, to address your use-case.

First, we need to clarify the operation of the SCAP requirement, SCAP.R.2000.5, as this is the underlying capability that I am planning on utilizing for the solution.  Not all SCAP 1.2-validated tools meet the requirement because it was under-specified, so this is something that should be addressed in SCAP 1.3.

I have attached a sample ARF that illustrates how the same external check, with different variable exports, can be handled for the three SCAP check systems (OVAL, OCIL, and informally, SCE).

The model works well with OVAL and SCE, but there is an issue with OCIL in that variable values are not expressed in the OCIL results format (this makes it impossible to associate arbitrary OCIL results with a set of XCCDF variable exports).  To address that problem, I have added a few new types to the “gOCIL” variables schema (see https://github.com/joval/jOVAL/blob/master/scap/schemas/ocil-2.0/ocil-variables-schema.xsd).  The new types, UserWithVariablesType and SystemWithVariablesType, make use of the OCIL results target substitution group to make it possible to add variable values to OCIL results without requiring any changes to the existing OCIL 2.0 schema.

With this mechanism is place, it will be possible to define a new XCCDF ValueType that obtains its values from an external check.  We can document that, if multiple results are returned for the check system for the value, we treat the resulting values as generating discrete Rule instances.

This concept already exists in XCCDF, via the Rule@multiple attribute.  We could simply disregard the sentence "For example, OVAL checks cannot produce separate results for individual instances of a target.” in table 9’s description of the RuleType@multiple attribute in the XCCDF specification, and then evaluate according to the existing specification.

As a side-note, we could also document in SCAP 1.3 that a complex-value is simply a Value that can have multiple values without implying that there must be multiple corresponding Rule instances.  The OVAL check system permits variables to have multiple values, as we all well know, but OCIL and SCE do not have a concept of multi-valued variables, so it would remain invalid to use complex values in conjunction with those systems.

If we accept this change, then if someone wanted to make use of an OVAL import as a Value without creating multiple instances of a downstream Rule, they could simply import it as a complex type.

Let me know if you have any feedback regarding this approach.  In the meantime I’m going to investigate what would be the minimal set of changes to XCCDF that would be required to support this new value type.

Best regards,
—David Solin



On Oct 5, 2015, at 8:13 AM, David Solin <[hidden email]> wrote:

I had previously replied only to Douglas; I am forwarding that response (below) for any community feedback.

Begin forwarded message:

From: David Solin <[hidden email]>
Subject: Re: [OVAL DEVELOPER] SQLEXT OVAL Extension Proposal
Date: October 1, 2015 at 6:03:34 PM CDT
To: "McIlroy, Douglas M CIV SPAWARSYSCEN-ATLANTIC, 58600" <[hidden email]>

Thanks for your insights, Douglas.  Please see my own thoughts inline, below.


On Oct 1, 2015, at 4:04 PM, McIlroy, Douglas M CIV SPAWARSYSCEN-ATLANTIC, 58600 <[hidden email]> wrote:

David,



Yes, this SQLEXT proposal supports behavior for addressing individual RDBMS instances (the term "instance" as used here refers to any query-able server process spawned by a given DBMS software installation) and named database schemas as top-level targets, and then outputting a dedicated result file for each target. Furthermore, SQLEXT is indeed a platform-agnostic SQL probe that can support DBMS products other than Microsoft SQL Server. The following Oracle, MySQL, and PostgreSQL documentation provides guidance for configuring multiple instances of a given DBMS on a host system:



https://docs.oracle.com/cd/E11882_01/server.112/e40540/startup.htm#CNCPT89033



https://dev.mysql.com/doc/refman/5.0/en/multiple-servers.html



https://opensourcedbms.com/dbms/running-multiple-postgresql-9-2-instances-on-one-server-in-centos-6rhel-6fedora/



Of course most (if not all) databases support running multiple instances on the same machine.  But apart from MS SQL Server, I don’t believe they are readily discoverable.  To determine which instances are running, for Oracle or MySQL or Postgres, it would be necessary for a tool to discover running processes, read their environments and command-line parameters, and reverse-engineer their configurations, in order to determine how to connect to each.  If the instances are not running at scan-time, then all bets are off.

This makes the implementation of <instance operation=“pattern match”>.*</instance> VERY problematic.




Also, other DBMS's aside from MS SQL Server, such as MySQL, do support hosting multiple named DB schemas per instance. One common counter-example, though, would be Oracle Database, which allocates an instance for each database schema, leading to the concepts of an Oracle DB "instance" and "database" being effectively equivalent. Therefore, the "instance" and "database" context behaviors would be interchangeable when being implemented for an Oracle DB evaluation.


Indeed, some do.  But to discover their names, you must first connect to a server instance in a management context.  And connecting to an instance without all the connection information is problematic.

Perhaps you're actually proposing that the SCAP scanning utility should be pre-populated with lists of all the instances on each machine, and how to connect to them.  That would eliminate the discovery problem, but I didn’t get that impression from the proposal.


Furthermore, in light of the lack of traction that the SQL57 spec has seen so far, we are not sure how productive attempting to augment it any further would be. Not much so far has come of attempting to incorporate SQL57 into the DISA STIGs due to the inflexibility and insecurity of the "connection_string" entity, so SQLEXT is being proposed as an alternative that addresses those complications.


I have to say, since it has always been possible to provide a connection_string value via an external_variable, I’ve personally never really understood the complaints.  Is it that the variable values would appear in the results?  The mask attribute might address that.

In the case of Joval, it’s possible to supply a connection_string with no username/password at all, in which case we use the credential supplied for connecting to the target machine.  In practice this can actually be useful when scanning MS SQL Servers that have been configured to leverage the Windows user account database.  We have had some success running the CIS MS SQL Server content through our product using the existing features.




Also, while extending XCCDF to support multiple top-level evaluation targets per host system is a great idea, we needed to pursue a solution that would be available in the near-term and that would support raw-OVAL evaluations that don't include an XCCDF benchmark. However, given that leveraging XCCDF to control the content processing model of a SCAP stream makes more sense than SQLEXT's raw-OVAL top-up approach, an update to the XCCDF spec would be welcome. Especially when considering other non-RDBM applications such as IIS, Apache, and Tomcat that also support being instantiated multiple times with a dedicated configuration for each instance, there definitely needs to be a discussion about how to make SCAP overall more fit for enterprise-grade applications.


I agree.  From a technical standpoint,  a non-standard upgrade to XCCDF should at least be no “worse” than a non-standard addition to OVAL.




________________________________
From: David Solin [[hidden email]]
Sent: Wednesday, September 30, 2015 5:28 PM
To: McIlroy, Douglas M CIV SPAWARSYSCEN-ATLANTIC, 58600
Cc: [hidden email]; [hidden email]
Subject: Re: [OVAL DEVELOPER] SQLEXT OVAL Extension Proposal

Hi Doug (and cross-posting to xccdf-dev),

I’m not really able to easily discern from the samples on Github… but, recalling the sql511 proposal, is the thrust of this proposal that the behaviors result in splitting out per-host, per-instance or per-database (depending on the behavior specified) into different result files?

Notwithstanding the answer to that question, I have a few initial thoughts:

This is not really a generic SQL test at all, but a Microsoft SQL Server test.  Only MSSQL has readily-discoverable instances.  Other RDBMS’s do not really have readily-discoverable instances, and also, they do not all support having multiple ‘databases’ within a single instance.  This was sort of the sole virtue of the connection_string — it identifies the target instance.  (This is also why both generic database-connectivity mechanisms I’ve personally used, ODBC and JDBC, support the concept of connection properties).

This appears to me to really, at heart, be a proposal to delegate instance/database discovery to the OVAL language.  It is certainly already possible using external_variables to target a piece of OVAL content to whatever combination of instances and databases one pleases — provided that those instances and databases are known to the tool that is doing the targeting (by setting the variable values).

If this is indeed the case, and if databases should indeed be treated as first-class targets, then it would make perfect sense to create entire SCAP benchmarks dedicated to evaluating databases, and measure compliance of each instance against that benchmark, rather than (as this proposal embodies) attempt to combine what should be multiple first-class target assessments into a single machine assessment result.

As an alternative to this approach, I would propose making a few changes to XCCDF and SCAP that would make it possible to do exactly what you guys want and leverage the existing sql57 test:

1.  Create selRefType and selComplexRefType types in XCCDF that make it possible to reference an exported value from a check system
2.  Add support for the XCCDF ComplexValueType in SCAP — defining it as a mechanism to evaluate multiple instances of a check evaluated via the multi-check attribute, or if via a complex-check, according to the complex-check’s operator attribute.

Was this an approach you guys have considered?  I’d be happy to collaborate with you to make these changes to XCCDF.  We could call it XCCDF 1.3.

Best regards,
—David Solin



David A. Solin
Co-Founder, Research & Technology
[hidden email]<[hidden email]>

[Joval Continuous Monitoring] <http://jovalcm.com/>

[Facebook] <https://www.facebook.com/jovalcm> [Linkedin]  <https://www.linkedin.com/company/joval-continuous-monitoring>


On Sep 30, 2015, at 11:41 AM, McIlroy, Douglas M CIV SPAWARSYSCEN-ATLANTIC, 58600 <[hidden email]<[hidden email]>> wrote:

Due to the need for automated compliance and vulnerability checks against SQL database management systems and a lack of support for the proposed sql511 test in OVAL 5.11, SPAWAR submits this new proposal for an OVAL extension which addresses the sql511 deficiencies. The current working designation for this proposal is “sqlext” (SQL Test for the OVAL Extension Schema). This is subject to change based upon discussion with the OVAL community regarding standard naming conventions for OVAL extensions. Please see the attached proposal document for further explanation as well as the SQLEXT OVAL Sandbox GitHub fork (https://github.com/mcilroyd/Sandbox/tree/master/resources/x-ind-sqlext) for sample content, results output, and XML schemas. We are looking forward to any feedback and recomendations that the community has to share for SQLEXT.

...<SQLExt Proposal.pdf>_______________________________________________
OVAL_Developer mailing list
[hidden email]<[hidden email]>
http://lists.cisecurity.org/mailman/listinfo/oval_developer_lists.cisecurity.org

<jovalcm.color.225.png><fb.rounded.png><li.rounded.png>




_______________________________________________
XCCDF-dev mailing list
[hidden email]
To unsubscribe, send an email message to [hidden email].

arf.xml (68K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Xccdf-dev] [OVAL DEVELOPER] SQLEXT OVAL Extension Proposal

Melvin Steward
David 

I've been following the developments on this thread for a while now and wanted to write to you directly about using what you're developing to handle the security details for embedded devices on a industrial SCADA/DCS network 

I haven't seen very much on this thread that talks about such an application, but based on what I've seen on this topic it would pretty much follow the same pattern.

NIST has a special publication for industrial systems. This application is connected with the DHS critical infrastructure security project that's been going on since 2012.

Prince Riley is the technical lead on this and I've copied him on this email so you can reply directly back to him 

Thanks 

On Monday, December 7, 2015, David Solin <[hidden email]> wrote:
Doug,

I have not forgotten your SQLEXT proposal for the OVAL language, and have been working on some XCCDF/SCAP ground-work that is required before I suggest updates to the XCCDF schema itself, to address your use-case.

First, we need to clarify the operation of the SCAP requirement, SCAP.R.2000.5, as this is the underlying capability that I am planning on utilizing for the solution.  Not all SCAP 1.2-validated tools meet the requirement because it was under-specified, so this is something that should be addressed in SCAP 1.3.

I have attached a sample ARF that illustrates how the same external check, with different variable exports, can be handled for the three SCAP check systems (OVAL, OCIL, and informally, SCE).

The model works well with OVAL and SCE, but there is an issue with OCIL in that variable values are not expressed in the OCIL results format (this makes it impossible to associate arbitrary OCIL results with a set of XCCDF variable exports).  To address that problem, I have added a few new types to the “gOCIL” variables schema (see https://github.com/joval/jOVAL/blob/master/scap/schemas/ocil-2.0/ocil-variables-schema.xsd).  The new types, UserWithVariablesType and SystemWithVariablesType, make use of the OCIL results target substitution group to make it possible to add variable values to OCIL results without requiring any changes to the existing OCIL 2.0 schema.

With this mechanism is place, it will be possible to define a new XCCDF ValueType that obtains its values from an external check.  We can document that, if multiple results are returned for the check system for the value, we treat the resulting values as generating discrete Rule instances.

This concept already exists in XCCDF, via the Rule@multiple attribute.  We could simply disregard the sentence "For example, OVAL checks cannot produce separate results for individual instances of a target.” in table 9’s description of the RuleType@multiple attribute in the XCCDF specification, and then evaluate according to the existing specification.

As a side-note, we could also document in SCAP 1.3 that a complex-value is simply a Value that can have multiple values without implying that there must be multiple corresponding Rule instances.  The OVAL check system permits variables to have multiple values, as we all well know, but OCIL and SCE do not have a concept of multi-valued variables, so it would remain invalid to use complex values in conjunction with those systems.

If we accept this change, then if someone wanted to make use of an OVAL import as a Value without creating multiple instances of a downstream Rule, they could simply import it as a complex type.

Let me know if you have any feedback regarding this approach.  In the meantime I’m going to investigate what would be the minimal set of changes to XCCDF that would be required to support this new value type.

Best regards,
—David Solin



--
Sent from my BlackBerry® smartphone with SprintSpeed
++++++CONFIDENTIALITY NOTICE++++++
The information in this email may be confidential and/or privileged. This email is intended to be reviewed only by the individual or organization named above. If you are not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any review, dissemination, storage, or copying of this email and its attachments, if any, or the information contained herein is prohibited.  If you have received this email in error, please immediately notify the sender by return email and delete this email from your system- Thank you.

 

_______________________________________________
XCCDF-dev mailing list
[hidden email]
To unsubscribe, send an email message to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: [Xccdf-dev] [Non-DoD Source] [OVAL DEVELOPER] SQLEXT OVAL Extension Proposal

David Solin-3
In reply to this post by David Solin
Hi Doug,

I’ve finally finished fleshing out my proposal for your use-case!

I have attached a modified xccdf_1.2.xsd, which is a modified schema for XCCDF.  It is fully backwards-compatible with XCCDF 1.2, but adds a few new types:

New Type: selImportType
Description: This new type is similar to selStringType and selComplexValueType, in that it can be used to assign a value to a ValueType and can be associated with a selector (by attribute).  However, unlike selStringType and selComplexValueType, a selImportType has the ability to import its value from an external check system.  This is achieved using an embedded CheckType.  The embedded check has some restrictions placed by the schema — it must include a single check-import (which defines the value that will be imported from the check system), and it is not permitted to include any check-exports (to eliminate the issue of Value recursion with the determination of instance values).  In place of the check-export, there is a new inline-export element that can be used to assign exported variable values for the check "on the spot”.  Finally, an attribute, “type” (possible values: “simple” and “complex”) is used to identify the result as being either a simple or complex value.

New Type: inlineExportType
Description: This type can be used to define any value that is exported by a check without reference to any valueType defined in the XCCDF document.  Think of it as a static value declaration.  Its purpose is mainly to simplify the process of defining any values that need to be exported to a check used by a selImportType, but I have modified the schema so that it can be used by any checkType in XCCDF.  (This was necessary to make it possible to use a checkType restriction as a child of the selImportType, instead of having to define a highly duplicative variation of that type).

I am also proposing a modification to some parts of the SCAP specification...

Currently, the SCAP 1.2 specification only permits the use of “simple” valueTypes in check-exports.  I believe we can decide that a “complex” value merely indicates a single valueType with multiple underlying values, and permit its use.  In OVAL, for example, a variable may hold multiple values at the same time.  We can use the XCCDF complexValueType (and its sub-type, selComplexValueType) to express such a multi-valued variable.

It’s easy to understand how a complex selImportType, whose check-import has multiple values will work.  But, what if a selImportType is defined as “simple”, but its check-import ends up producing multiple results?

Well, I propose that we say in such cases, any XCCDF check making use of such a value becomes a permutation — that is, it should behave a lot like a check whose check-content-ref has an href, but no name.  For that case, we have the multi-check attribute that defines how to express the rule results (as a single roll-up, or as a list of permutations).  In the case of a multi-valued simple value in XCCDF, we can use the heretofore unused ruleType@multiple attribute to dictate the behavior.

The attached ARF XML file illustrates the use of the new types, as well as all the behaviors I’ve described above.

These new tools will make it possible for someone to write a benchmark that (1) discovers relevant instances of a database on a target machine, and (2) implements one or more compliance rules that is applied to each of those instances, which can be reported distinctly or as a roll-up.

Thoughts? Comments?

Best regards,
—David Solin





> On Dec 7, 2015, at 10:19 AM, Tanner, Douglas C CIV SPAWARSYSCEN-ATLANTIC, 58510 <[hidden email]> wrote:
>
> David -
>
>
>
> I believe you meant to send this to the other Doug on the team. I've CC'd him.
>
>
>
> Doug Tanner
>
> ________________________________
> From: David Solin [[hidden email]]
> Sent: Monday, December 07, 2015 10:35 AM
> To: Tanner, Douglas C CIV SPAWARSYSCEN-ATLANTIC, 58510
> Cc: [hidden email]; Waltermire, David A.
> Subject: [Non-DoD Source] Re: [OVAL DEVELOPER] SQLEXT OVAL Extension Proposal
>
> Doug,
>
> I have not forgotten your SQLEXT proposal for the OVAL language, and have been working on some XCCDF/SCAP ground-work that is required before I suggest updates to the XCCDF schema itself, to address your use-case.
>
> First, we need to clarify the operation of the SCAP requirement, SCAP.R.2000.5, as this is the underlying capability that I am planning on utilizing for the solution.  Not all SCAP 1.2-validated tools meet the requirement because it was under-specified, so this is something that should be addressed in SCAP 1.3.
>
> I have attached a sample ARF that illustrates how the same external check, with different variable exports, can be handled for the three SCAP check systems (OVAL, OCIL, and informally, SCE).
>
> The model works well with OVAL and SCE, but there is an issue with OCIL in that variable values are not expressed in the OCIL results format (this makes it impossible to associate arbitrary OCIL results with a set of XCCDF variable exports).  To address that problem, I have added a few new types to the “gOCIL” variables schema (see https://github.com/joval/jOVAL/blob/master/scap/schemas/ocil-2.0/ocil-variables-schema.xsd).  The new types, UserWithVariablesType and SystemWithVariablesType, make use of the OCIL results target substitution group to make it possible to add variable values to OCIL results without requiring any changes to the existing OCIL 2.0 schema.
>
> With this mechanism is place, it will be possible to define a new XCCDF ValueType that obtains its values from an external check.  We can document that, if multiple results are returned for the check system for the value, we treat the resulting values as generating discrete Rule instances.
>
> This concept already exists in XCCDF, via the Rule@multiple attribute.  We could simply disregard the sentence "For example, OVAL checks cannot produce separate results for individual instances of a target.” in table 9’s description of the RuleType@multiple attribute in the XCCDF specification, and then evaluate according to the existing specification.
>
> As a side-note, we could also document in SCAP 1.3 that a complex-value is simply a Value that can have multiple values without implying that there must be multiple corresponding Rule instances.  The OVAL check system permits variables to have multiple values, as we all well know, but OCIL and SCE do not have a concept of multi-valued variables, so it would remain invalid to use complex values in conjunction with those systems.
>
> If we accept this change, then if someone wanted to make use of an OVAL import as a Value without creating multiple instances of a downstream Rule, they could simply import it as a complex type.
>
> Let me know if you have any feedback regarding this approach.  In the meantime I’m going to investigate what would be the minimal set of changes to XCCDF that would be required to support this new value type.
>
> Best regards,
> —David Solin
>
>
> On Oct 5, 2015, at 8:13 AM, David Solin <[hidden email]<mailto:[hidden email]>> wrote:
>
> I had previously replied only to Douglas; I am forwarding that response (below) for any community feedback.
>
> Begin forwarded message:
>
> From: David Solin <[hidden email]<mailto:[hidden email]>>
> Subject: Re: [OVAL DEVELOPER] SQLEXT OVAL Extension Proposal
> Date: October 1, 2015 at 6:03:34 PM CDT
> To: "McIlroy, Douglas M CIV SPAWARSYSCEN-ATLANTIC, 58600" <[hidden email]<mailto:[hidden email]>>
>
> Thanks for your insights, Douglas.  Please see my own thoughts inline, below.
>
>
> On Oct 1, 2015, at 4:04 PM, McIlroy, Douglas M CIV SPAWARSYSCEN-ATLANTIC, 58600 <[hidden email]<mailto:[hidden email]>> wrote:
>
> David,
>
>
>
> Yes, this SQLEXT proposal supports behavior for addressing individual RDBMS instances (the term "instance" as used here refers to any query-able server process spawned by a given DBMS software installation) and named database schemas as top-level targets, and then outputting a dedicated result file for each target. Furthermore, SQLEXT is indeed a platform-agnostic SQL probe that can support DBMS products other than Microsoft SQL Server. The following Oracle, MySQL, and PostgreSQL documentation provides guidance for configuring multiple instances of a given DBMS on a host system:
>
>
>
> https://docs.oracle.com/cd/E11882_01/server.112/e40540/startup.htm#CNCPT89033
>
>
>
> https://dev.mysql.com/doc/refman/5.0/en/multiple-servers.html
>
>
>
> https://opensourcedbms.com/dbms/running-multiple-postgresql-9-2-instances-on-one-server-in-centos-6rhel-6fedora/
>
>
>
> Of course most (if not all) databases support running multiple instances on the same machine.  But apart from MS SQL Server, I don’t believe they are readily discoverable.  To determine which instances are running, for Oracle or MySQL or Postgres, it would be necessary for a tool to discover running processes, read their environments and command-line parameters, and reverse-engineer their configurations, in order to determine how to connect to each.  If the instances are not running at scan-time, then all bets are off.
>
> This makes the implementation of <instance operation=“pattern match”>.*</instance> VERY problematic.
>
>
>
>
> Also, other DBMS's aside from MS SQL Server, such as MySQL, do support hosting multiple named DB schemas per instance. One common counter-example, though, would be Oracle Database, which allocates an instance for each database schema, leading to the concepts of an Oracle DB "instance" and "database" being effectively equivalent. Therefore, the "instance" and "database" context behaviors would be interchangeable when being implemented for an Oracle DB evaluation.
>
>
> Indeed, some do.  But to discover their names, you must first connect to a server instance in a management context.  And connecting to an instance without all the connection information is problematic.
>
> Perhaps you're actually proposing that the SCAP scanning utility should be pre-populated with lists of all the instances on each machine, and how to connect to them.  That would eliminate the discovery problem, but I didn’t get that impression from the proposal.
>
>
> Furthermore, in light of the lack of traction that the SQL57 spec has seen so far, we are not sure how productive attempting to augment it any further would be. Not much so far has come of attempting to incorporate SQL57 into the DISA STIGs due to the inflexibility and insecurity of the "connection_string" entity, so SQLEXT is being proposed as an alternative that addresses those complications.
>
>
> I have to say, since it has always been possible to provide a connection_string value via an external_variable, I’ve personally never really understood the complaints.  Is it that the variable values would appear in the results?  The mask attribute might address that.
>
> In the case of Joval, it’s possible to supply a connection_string with no username/password at all, in which case we use the credential supplied for connecting to the target machine.  In practice this can actually be useful when scanning MS SQL Servers that have been configured to leverage the Windows user account database.  We have had some success running the CIS MS SQL Server content through our product using the existing features.
>
>
>
>
> Also, while extending XCCDF to support multiple top-level evaluation targets per host system is a great idea, we needed to pursue a solution that would be available in the near-term and that would support raw-OVAL evaluations that don't include an XCCDF benchmark. However, given that leveraging XCCDF to control the content processing model of a SCAP stream makes more sense than SQLEXT's raw-OVAL top-up approach, an update to the XCCDF spec would be welcome. Especially when considering other non-RDBM applications such as IIS, Apache, and Tomcat that also support being instantiated multiple times with a dedicated configuration for each instance, there definitely needs to be a discussion about how to make SCAP overall more fit for enterprise-grade applications.
>
>
> I agree.  From a technical standpoint,  a non-standard upgrade to XCCDF should at least be no “worse” than a non-standard addition to OVAL.
>
>
>
>
> ________________________________
> From: David Solin [[hidden email]<mailto:[hidden email]>]
> Sent: Wednesday, September 30, 2015 5:28 PM
> To: McIlroy, Douglas M CIV SPAWARSYSCEN-ATLANTIC, 58600
> Cc: [hidden email]<mailto:[hidden email]>; [hidden email]<mailto:[hidden email]>
> Subject: Re: [OVAL DEVELOPER] SQLEXT OVAL Extension Proposal
>
> Hi Doug (and cross-posting to xccdf-dev),
>
> I’m not really able to easily discern from the samples on Github… but, recalling the sql511 proposal, is the thrust of this proposal that the behaviors result in splitting out per-host, per-instance or per-database (depending on the behavior specified) into different result files?
>
> Notwithstanding the answer to that question, I have a few initial thoughts:
>
> This is not really a generic SQL test at all, but a Microsoft SQL Server test.  Only MSSQL has readily-discoverable instances.  Other RDBMS’s do not really have readily-discoverable instances, and also, they do not all support having multiple ‘databases’ within a single instance.  This was sort of the sole virtue of the connection_string — it identifies the target instance.  (This is also why both generic database-connectivity mechanisms I’ve personally used, ODBC and JDBC, support the concept of connection properties).
>
> This appears to me to really, at heart, be a proposal to delegate instance/database discovery to the OVAL language.  It is certainly already possible using external_variables to target a piece of OVAL content to whatever combination of instances and databases one pleases — provided that those instances and databases are known to the tool that is doing the targeting (by setting the variable values).
>
> If this is indeed the case, and if databases should indeed be treated as first-class targets, then it would make perfect sense to create entire SCAP benchmarks dedicated to evaluating databases, and measure compliance of each instance against that benchmark, rather than (as this proposal embodies) attempt to combine what should be multiple first-class target assessments into a single machine assessment result.
>
> As an alternative to this approach, I would propose making a few changes to XCCDF and SCAP that would make it possible to do exactly what you guys want and leverage the existing sql57 test:
>
> 1.  Create selRefType and selComplexRefType types in XCCDF that make it possible to reference an exported value from a check system
> 2.  Add support for the XCCDF ComplexValueType in SCAP — defining it as a mechanism to evaluate multiple instances of a check evaluated via the multi-check attribute, or if via a complex-check, according to the complex-check’s operator attribute.
>
> Was this an approach you guys have considered?  I’d be happy to collaborate with you to make these changes to XCCDF.  We could call it XCCDF 1.3.
>
> Best regards,
> —David Solin
>
>
>
> David A. Solin
> Co-Founder, Research & Technology
> [hidden email]<mailto:[hidden email]><mailto:[hidden email]>
>
> [Joval Continuous Monitoring] <http://jovalcm.com/>
>
> [Facebook] <https://www.facebook.com/jovalcm> [Linkedin]  <https://www.linkedin.com/company/joval-continuous-monitoring>
>
>
> On Sep 30, 2015, at 11:41 AM, McIlroy, Douglas M CIV SPAWARSYSCEN-ATLANTIC, 58600 <[hidden email]<mailto:[hidden email]><mailto:[hidden email]>> wrote:
>
> Due to the need for automated compliance and vulnerability checks against SQL database management systems and a lack of support for the proposed sql511 test in OVAL 5.11, SPAWAR submits this new proposal for an OVAL extension which addresses the sql511 deficiencies. The current working designation for this proposal is “sqlext” (SQL Test for the OVAL Extension Schema). This is subject to change based upon discussion with the OVAL community regarding standard naming conventions for OVAL extensions. Please see the attached proposal document for further explanation as well as the SQLEXT OVAL Sandbox GitHub fork (https://github.com/mcilroyd/Sandbox/tree/master/resources/x-ind-sqlext) for sample content, results output, and XML schemas. We are looking forward to any feedback and recomendations that the community has to share for SQLEXT.
>
> ...<SQLExt Proposal.pdf>_______________________________________________
> OVAL_Developer mailing list
> [hidden email]<mailto:[hidden email]><mailto:[hidden email]>
> http://lists.cisecurity.org/mailman/listinfo/oval_developer_lists.cisecurity.org
>
> <jovalcm.color.225.png><fb.rounded.png><li.rounded.png>
>
>
>
David A. Solin
Co-Founder, Research & Technology
[hidden email]



 


_______________________________________________
XCCDF-dev mailing list
[hidden email]
To unsubscribe, send an email message to [hidden email].

xccdf_1.2.xsd (170K) Download Attachment
arf.xml (66K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Xccdf-dev] [Non-DoD Source] [OVAL DEVELOPER] SQLEXT OVAL Extension Proposal

Vishal Palkar
UNSUBSCRIBE

________________________________________
From: [hidden email] <[hidden email]> on behalf of David Solin <[hidden email]>
Sent: Friday, December 11, 2015 9:01 PM
To: McIlroy, Douglas M CIV SPAWARSYSCEN-ATLANTIC, 58600
Cc: [hidden email]
Subject: Re: [Xccdf-dev] [Non-DoD Source] [OVAL DEVELOPER] SQLEXT OVAL  Extension Proposal

Hi Doug,

I’ve finally finished fleshing out my proposal for your use-case!

I have attached a modified xccdf_1.2.xsd, which is a modified schema for XCCDF.  It is fully backwards-compatible with XCCDF 1.2, but adds a few new types:

New Type: selImportType
Description: This new type is similar to selStringType and selComplexValueType, in that it can be used to assign a value to a ValueType and can be associated with a selector (by attribute).  However, unlike selStringType and selComplexValueType, a selImportType has the ability to import its value from an external check system.  This is achieved using an embedded CheckType.  The embedded check has some restrictions placed by the schema — it must include a single check-import (which defines the value that will be imported from the check system), and it is not permitted to include any check-exports (to eliminate the issue of Value recursion with the determination of instance values).  In place of the check-export, there is a new inline-export element that can be used to assign exported variable values for the check "on the spot”.  Finally, an attribute, “type” (possible values: “simple” and “complex”) is used to identify the result as being either a simple or complex value.

New Type: inlineExportType
Description: This type can be used to define any value that is exported by a check without reference to any valueType defined in the XCCDF document.  Think of it as a static value declaration.  Its purpose is mainly to simplify the process of defining any values that need to be exported to a check used by a selImportType, but I have modified the schema so that it can be used by any checkType in XCCDF.  (This was necessary to make it possible to use a checkType restriction as a child of the selImportType, instead of having to define a highly duplicative variation of that type).

I am also proposing a modification to some parts of the SCAP specification...

Currently, the SCAP 1.2 specification only permits the use of “simple” valueTypes in check-exports.  I believe we can decide that a “complex” value merely indicates a single valueType with multiple underlying values, and permit its use.  In OVAL, for example, a variable may hold multiple values at the same time.  We can use the XCCDF complexValueType (and its sub-type, selComplexValueType) to express such a multi-valued variable.

It’s easy to understand how a complex selImportType, whose check-import has multiple values will work.  But, what if a selImportType is defined as “simple”, but its check-import ends up producing multiple results?

Well, I propose that we say in such cases, any XCCDF check making use of such a value becomes a permutation — that is, it should behave a lot like a check whose check-content-ref has an href, but no name.  For that case, we have the multi-check attribute that defines how to express the rule results (as a single roll-up, or as a list of permutations).  In the case of a multi-valued simple value in XCCDF, we can use the heretofore unused ruleType@multiple attribute to dictate the behavior.

The attached ARF XML file illustrates the use of the new types, as well as all the behaviors I’ve described above.

These new tools will make it possible for someone to write a benchmark that (1) discovers relevant instances of a database on a target machine, and (2) implements one or more compliance rules that is applied to each of those instances, which can be reported distinctly or as a roll-up.

Thoughts? Comments?

Best regards,
—David Solin


_______________________________________________
XCCDF-dev mailing list
[hidden email]
To unsubscribe, send an email message to [hidden email].
JA
Reply | Threaded
Open this post in threaded view
|

Re: [Xccdf-dev] [Non-DoD Source] [OVAL DEVELOPER] SQLEXT OVAL Extension Proposal

JA
In reply to this post by David Solin-3
David,

this seems awesome
(but You, for sure, are awesome ;-))

We would have to investigate how we could use that with the CIS Benchmarks

Cheers

> On Dec 11, 2015, at 6:31 PM, David Solin <[hidden email]> wrote:
>
> Hi Doug,
>
> I’ve finally finished fleshing out my proposal for your use-case!
>
> I have attached a modified xccdf_1.2.xsd, which is a modified schema for XCCDF.  It is fully backwards-compatible with XCCDF 1.2, but adds a few new types:
>
> New Type: selImportType
> Description: This new type is similar to selStringType and selComplexValueType, in that it can be used to assign a value to a ValueType and can be associated with a selector (by attribute).  However, unlike selStringType and selComplexValueType, a selImportType has the ability to import its value from an external check system.  This is achieved using an embedded CheckType.  The embedded check has some restrictions placed by the schema — it must include a single check-import (which defines the value that will be imported from the check system), and it is not permitted to include any check-exports (to eliminate the issue of Value recursion with the determination of instance values).  In place of the check-export, there is a new inline-export element that can be used to assign exported variable values for the check "on the spot”.  Finally, an attribute, “type” (possible values: “simple” and “complex”) is used to identify the result as being either a simple or complex value.
>
> New Type: inlineExportType
> Description: This type can be used to define any value that is exported by a check without reference to any valueType defined in the XCCDF document.  Think of it as a static value declaration.  Its purpose is mainly to simplify the process of defining any values that need to be exported to a check used by a selImportType, but I have modified the schema so that it can be used by any checkType in XCCDF.  (This was necessary to make it possible to use a checkType restriction as a child of the selImportType, instead of having to define a highly duplicative variation of that type).
>
> I am also proposing a modification to some parts of the SCAP specification...
>
> Currently, the SCAP 1.2 specification only permits the use of “simple” valueTypes in check-exports.  I believe we can decide that a “complex” value merely indicates a single valueType with multiple underlying values, and permit its use.  In OVAL, for example, a variable may hold multiple values at the same time.  We can use the XCCDF complexValueType (and its sub-type, selComplexValueType) to express such a multi-valued variable.
>
> It’s easy to understand how a complex selImportType, whose check-import has multiple values will work.  But, what if a selImportType is defined as “simple”, but its check-import ends up producing multiple results?
>
> Well, I propose that we say in such cases, any XCCDF check making use of such a value becomes a permutation — that is, it should behave a lot like a check whose check-content-ref has an href, but no name.  For that case, we have the multi-check attribute that defines how to express the rule results (as a single roll-up, or as a list of permutations).  In the case of a multi-valued simple value in XCCDF, we can use the heretofore unused ruleType@multiple attribute to dictate the behavior.
>
> The attached ARF XML file illustrates the use of the new types, as well as all the behaviors I’ve described above.
>
> These new tools will make it possible for someone to write a benchmark that (1) discovers relevant instances of a database on a target machine, and (2) implements one or more compliance rules that is applied to each of those instances, which can be reported distinctly or as a roll-up.
>
> Thoughts? Comments?
>
> Best regards,
> —David Solin
>
> <xccdf_1.2.xsd><arf.xml>
>
>
>> On Dec 7, 2015, at 10:19 AM, Tanner, Douglas C CIV SPAWARSYSCEN-ATLANTIC, 58510 <[hidden email]> wrote:
>>
>> David -
>>
>>
>>
>> I believe you meant to send this to the other Doug on the team. I've CC'd him.
>>
>>
>>
>> Doug Tanner
>>
>> ________________________________
>> From: David Solin [[hidden email]]
>> Sent: Monday, December 07, 2015 10:35 AM
>> To: Tanner, Douglas C CIV SPAWARSYSCEN-ATLANTIC, 58510
>> Cc: [hidden email]; Waltermire, David A.
>> Subject: [Non-DoD Source] Re: [OVAL DEVELOPER] SQLEXT OVAL Extension Proposal
>>
>> Doug,
>>
>> I have not forgotten your SQLEXT proposal for the OVAL language, and have been working on some XCCDF/SCAP ground-work that is required before I suggest updates to the XCCDF schema itself, to address your use-case.
>>
>> First, we need to clarify the operation of the SCAP requirement, SCAP.R.2000.5, as this is the underlying capability that I am planning on utilizing for the solution.  Not all SCAP 1.2-validated tools meet the requirement because it was under-specified, so this is something that should be addressed in SCAP 1.3.
>>
>> I have attached a sample ARF that illustrates how the same external check, with different variable exports, can be handled for the three SCAP check systems (OVAL, OCIL, and informally, SCE).
>>
>> The model works well with OVAL and SCE, but there is an issue with OCIL in that variable values are not expressed in the OCIL results format (this makes it impossible to associate arbitrary OCIL results with a set of XCCDF variable exports).  To address that problem, I have added a few new types to the “gOCIL” variables schema (see https://github.com/joval/jOVAL/blob/master/scap/schemas/ocil-2.0/ocil-variables-schema.xsd).  The new types, UserWithVariablesType and SystemWithVariablesType, make use of the OCIL results target substitution group to make it possible to add variable values to OCIL results without requiring any changes to the existing OCIL 2.0 schema.
>>
>> With this mechanism is place, it will be possible to define a new XCCDF ValueType that obtains its values from an external check.  We can document that, if multiple results are returned for the check system for the value, we treat the resulting values as generating discrete Rule instances.
>>
>> This concept already exists in XCCDF, via the Rule@multiple attribute.  We could simply disregard the sentence "For example, OVAL checks cannot produce separate results for individual instances of a target.” in table 9’s description of the RuleType@multiple attribute in the XCCDF specification, and then evaluate according to the existing specification.
>>
>> As a side-note, we could also document in SCAP 1.3 that a complex-value is simply a Value that can have multiple values without implying that there must be multiple corresponding Rule instances.  The OVAL check system permits variables to have multiple values, as we all well know, but OCIL and SCE do not have a concept of multi-valued variables, so it would remain invalid to use complex values in conjunction with those systems.
>>
>> If we accept this change, then if someone wanted to make use of an OVAL import as a Value without creating multiple instances of a downstream Rule, they could simply import it as a complex type.
>>
>> Let me know if you have any feedback regarding this approach.  In the meantime I’m going to investigate what would be the minimal set of changes to XCCDF that would be required to support this new value type.
>>
>> Best regards,
>> —David Solin
>>
>>
>> On Oct 5, 2015, at 8:13 AM, David Solin <[hidden email]<mailto:[hidden email]>> wrote:
>>
>> I had previously replied only to Douglas; I am forwarding that response (below) for any community feedback.
>>
>> Begin forwarded message:
>>
>> From: David Solin <[hidden email]<mailto:[hidden email]>>
>> Subject: Re: [OVAL DEVELOPER] SQLEXT OVAL Extension Proposal
>> Date: October 1, 2015 at 6:03:34 PM CDT
>> To: "McIlroy, Douglas M CIV SPAWARSYSCEN-ATLANTIC, 58600" <[hidden email]<mailto:[hidden email]>>
>>
>> Thanks for your insights, Douglas.  Please see my own thoughts inline, below.
>>
>>
>> On Oct 1, 2015, at 4:04 PM, McIlroy, Douglas M CIV SPAWARSYSCEN-ATLANTIC, 58600 <[hidden email]<mailto:[hidden email]>> wrote:
>>
>> David,
>>
>>
>>
>> Yes, this SQLEXT proposal supports behavior for addressing individual RDBMS instances (the term "instance" as used here refers to any query-able server process spawned by a given DBMS software installation) and named database schemas as top-level targets, and then outputting a dedicated result file for each target. Furthermore, SQLEXT is indeed a platform-agnostic SQL probe that can support DBMS products other than Microsoft SQL Server. The following Oracle, MySQL, and PostgreSQL documentation provides guidance for configuring multiple instances of a given DBMS on a host system:
>>
>>
>>
>> https://docs.oracle.com/cd/E11882_01/server.112/e40540/startup.htm#CNCPT89033
>>
>>
>>
>> https://dev.mysql.com/doc/refman/5.0/en/multiple-servers.html
>>
>>
>>
>> https://opensourcedbms.com/dbms/running-multiple-postgresql-9-2-instances-on-one-server-in-centos-6rhel-6fedora/
>>
>>
>>
>> Of course most (if not all) databases support running multiple instances on the same machine.  But apart from MS SQL Server, I don’t believe they are readily discoverable.  To determine which instances are running, for Oracle or MySQL or Postgres, it would be necessary for a tool to discover running processes, read their environments and command-line parameters, and reverse-engineer their configurations, in order to determine how to connect to each.  If the instances are not running at scan-time, then all bets are off.
>>
>> This makes the implementation of <instance operation=“pattern match”>.*</instance> VERY problematic.
>>
>>
>>
>>
>> Also, other DBMS's aside from MS SQL Server, such as MySQL, do support hosting multiple named DB schemas per instance. One common counter-example, though, would be Oracle Database, which allocates an instance for each database schema, leading to the concepts of an Oracle DB "instance" and "database" being effectively equivalent. Therefore, the "instance" and "database" context behaviors would be interchangeable when being implemented for an Oracle DB evaluation.
>>
>>
>> Indeed, some do.  But to discover their names, you must first connect to a server instance in a management context.  And connecting to an instance without all the connection information is problematic.
>>
>> Perhaps you're actually proposing that the SCAP scanning utility should be pre-populated with lists of all the instances on each machine, and how to connect to them.  That would eliminate the discovery problem, but I didn’t get that impression from the proposal.
>>
>>
>> Furthermore, in light of the lack of traction that the SQL57 spec has seen so far, we are not sure how productive attempting to augment it any further would be. Not much so far has come of attempting to incorporate SQL57 into the DISA STIGs due to the inflexibility and insecurity of the "connection_string" entity, so SQLEXT is being proposed as an alternative that addresses those complications.
>>
>>
>> I have to say, since it has always been possible to provide a connection_string value via an external_variable, I’ve personally never really understood the complaints.  Is it that the variable values would appear in the results?  The mask attribute might address that.
>>
>> In the case of Joval, it’s possible to supply a connection_string with no username/password at all, in which case we use the credential supplied for connecting to the target machine.  In practice this can actually be useful when scanning MS SQL Servers that have been configured to leverage the Windows user account database.  We have had some success running the CIS MS SQL Server content through our product using the existing features.
>>
>>
>>
>>
>> Also, while extending XCCDF to support multiple top-level evaluation targets per host system is a great idea, we needed to pursue a solution that would be available in the near-term and that would support raw-OVAL evaluations that don't include an XCCDF benchmark. However, given that leveraging XCCDF to control the content processing model of a SCAP stream makes more sense than SQLEXT's raw-OVAL top-up approach, an update to the XCCDF spec would be welcome. Especially when considering other non-RDBM applications such as IIS, Apache, and Tomcat that also support being instantiated multiple times with a dedicated configuration for each instance, there definitely needs to be a discussion about how to make SCAP overall more fit for enterprise-grade applications.
>>
>>
>> I agree.  From a technical standpoint,  a non-standard upgrade to XCCDF should at least be no “worse” than a non-standard addition to OVAL.
>>
>>
>>
>>
>> ________________________________
>> From: David Solin [[hidden email]<mailto:[hidden email]>]
>> Sent: Wednesday, September 30, 2015 5:28 PM
>> To: McIlroy, Douglas M CIV SPAWARSYSCEN-ATLANTIC, 58600
>> Cc: [hidden email]<mailto:[hidden email]>; [hidden email]<mailto:[hidden email]>
>> Subject: Re: [OVAL DEVELOPER] SQLEXT OVAL Extension Proposal
>>
>> Hi Doug (and cross-posting to xccdf-dev),
>>
>> I’m not really able to easily discern from the samples on Github… but, recalling the sql511 proposal, is the thrust of this proposal that the behaviors result in splitting out per-host, per-instance or per-database (depending on the behavior specified) into different result files?
>>
>> Notwithstanding the answer to that question, I have a few initial thoughts:
>>
>> This is not really a generic SQL test at all, but a Microsoft SQL Server test.  Only MSSQL has readily-discoverable instances.  Other RDBMS’s do not really have readily-discoverable instances, and also, they do not all support having multiple ‘databases’ within a single instance.  This was sort of the sole virtue of the connection_string — it identifies the target instance.  (This is also why both generic database-connectivity mechanisms I’ve personally used, ODBC and JDBC, support the concept of connection properties).
>>
>> This appears to me to really, at heart, be a proposal to delegate instance/database discovery to the OVAL language.  It is certainly already possible using external_variables to target a piece of OVAL content to whatever combination of instances and databases one pleases — provided that those instances and databases are known to the tool that is doing the targeting (by setting the variable values).
>>
>> If this is indeed the case, and if databases should indeed be treated as first-class targets, then it would make perfect sense to create entire SCAP benchmarks dedicated to evaluating databases, and measure compliance of each instance against that benchmark, rather than (as this proposal embodies) attempt to combine what should be multiple first-class target assessments into a single machine assessment result.
>>
>> As an alternative to this approach, I would propose making a few changes to XCCDF and SCAP that would make it possible to do exactly what you guys want and leverage the existing sql57 test:
>>
>> 1.  Create selRefType and selComplexRefType types in XCCDF that make it possible to reference an exported value from a check system
>> 2.  Add support for the XCCDF ComplexValueType in SCAP — defining it as a mechanism to evaluate multiple instances of a check evaluated via the multi-check attribute, or if via a complex-check, according to the complex-check’s operator attribute.
>>
>> Was this an approach you guys have considered?  I’d be happy to collaborate with you to make these changes to XCCDF.  We could call it XCCDF 1.3.
>>
>> Best regards,
>> —David Solin
>>
>>
>>
>> David A. Solin
>> Co-Founder, Research & Technology
>> [hidden email]<mailto:[hidden email]><mailto:[hidden email]>
>>
>> [Joval Continuous Monitoring] <http://jovalcm.com/>
>>
>> [Facebook] <https://www.facebook.com/jovalcm> [Linkedin]  <https://www.linkedin.com/company/joval-continuous-monitoring>
>>
>>
>> On Sep 30, 2015, at 11:41 AM, McIlroy, Douglas M CIV SPAWARSYSCEN-ATLANTIC, 58600 <[hidden email]<mailto:[hidden email]><mailto:[hidden email]>> wrote:
>>
>> Due to the need for automated compliance and vulnerability checks against SQL database management systems and a lack of support for the proposed sql511 test in OVAL 5.11, SPAWAR submits this new proposal for an OVAL extension which addresses the sql511 deficiencies. The current working designation for this proposal is “sqlext” (SQL Test for the OVAL Extension Schema). This is subject to change based upon discussion with the OVAL community regarding standard naming conventions for OVAL extensions. Please see the attached proposal document for further explanation as well as the SQLEXT OVAL Sandbox GitHub fork (https://github.com/mcilroyd/Sandbox/tree/master/resources/x-ind-sqlext) for sample content, results output, and XML schemas. We are looking forward to any feedback and recomendations that the community has to share for SQLEXT.
>>
>> ...<SQLExt Proposal.pdf>_______________________________________________
>> OVAL_Developer mailing list
>> [hidden email]<mailto:[hidden email]><mailto:[hidden email]>
>> http://lists.cisecurity.org/mailman/listinfo/oval_developer_lists.cisecurity.org
>>
>> <jovalcm.color.225.png><fb.rounded.png><li.rounded.png>
>>
>>
>>
>
> David A. Solin
> Co-Founder, Research & Technology
> [hidden email]
>
>
>
>
>
> _______________________________________________
> XCCDF-dev mailing list
> [hidden email]
> To unsubscribe, send an email message to [hidden email].


_______________________________________________
XCCDF-dev mailing list
[hidden email]
To unsubscribe, send an email message to [hidden email].
JA
Reply | Threaded
Open this post in threaded view
|

Re: [Xccdf-dev] [OVAL DEVELOPER] SQLEXT OVAL Extension Proposal

JA
In reply to this post by Melvin Steward
Melvin,

I think that this would be better covered via the use of (not available yet) MITRE CybOX [1] Objects for the ICS/SCADA world.
That would be greatly beneficial if you could contribute to it.
I know that there is interest in the MITRE CybOX/CTI world for support of things like modes, etc.

I hope it makes sense.
Best regards


On Dec 9, 2015, at 1:51 PM, Melvin Steward <[hidden email]> wrote:

David 

I've been following the developments on this thread for a while now and wanted to write to you directly about using what you're developing to handle the security details for embedded devices on a industrial SCADA/DCS network 

I haven't seen very much on this thread that talks about such an application, but based on what I've seen on this topic it would pretty much follow the same pattern.

NIST has a special publication for industrial systems. This application is connected with the DHS critical infrastructure security project that's been going on since 2012.

Prince Riley is the technical lead on this and I've copied him on this email so you can reply directly back to him 

Thanks 

On Monday, December 7, 2015, David Solin <[hidden email]> wrote:
Doug,

I have not forgotten your SQLEXT proposal for the OVAL language, and have been working on some XCCDF/SCAP ground-work that is required before I suggest updates to the XCCDF schema itself, to address your use-case.

First, we need to clarify the operation of the SCAP requirement, SCAP.R.2000.5, as this is the underlying capability that I am planning on utilizing for the solution.  Not all SCAP 1.2-validated tools meet the requirement because it was under-specified, so this is something that should be addressed in SCAP 1.3.

I have attached a sample ARF that illustrates how the same external check, with different variable exports, can be handled for the three SCAP check systems (OVAL, OCIL, and informally, SCE).

The model works well with OVAL and SCE, but there is an issue with OCIL in that variable values are not expressed in the OCIL results format (this makes it impossible to associate arbitrary OCIL results with a set of XCCDF variable exports).  To address that problem, I have added a few new types to the “gOCIL” variables schema (see https://github.com/joval/jOVAL/blob/master/scap/schemas/ocil-2.0/ocil-variables-schema.xsd).  The new types, UserWithVariablesType and SystemWithVariablesType, make use of the OCIL results target substitution group to make it possible to add variable values to OCIL results without requiring any changes to the existing OCIL 2.0 schema.

With this mechanism is place, it will be possible to define a new XCCDF ValueType that obtains its values from an external check.  We can document that, if multiple results are returned for the check system for the value, we treat the resulting values as generating discrete Rule instances.

This concept already exists in XCCDF, via the Rule@multiple attribute.  We could simply disregard the sentence "For example, OVAL checks cannot produce separate results for individual instances of a target.” in table 9’s description of the RuleType@multiple attribute in the XCCDF specification, and then evaluate according to the existing specification.

As a side-note, we could also document in SCAP 1.3 that a complex-value is simply a Value that can have multiple values without implying that there must be multiple corresponding Rule instances.  The OVAL check system permits variables to have multiple values, as we all well know, but OCIL and SCE do not have a concept of multi-valued variables, so it would remain invalid to use complex values in conjunction with those systems.

If we accept this change, then if someone wanted to make use of an OVAL import as a Value without creating multiple instances of a downstream Rule, they could simply import it as a complex type.

Let me know if you have any feedback regarding this approach.  In the meantime I’m going to investigate what would be the minimal set of changes to XCCDF that would be required to support this new value type.

Best regards,
—David Solin



-- 
Sent from my BlackBerry® smartphone with SprintSpeed
++++++CONFIDENTIALITY NOTICE++++++
The information in this email may be confidential and/or privileged. This email is intended to be reviewed only by the individual or organization named above. If you are not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any review, dissemination, storage, or copying of this email and its attachments, if any, or the information contained herein is prohibited.  If you have received this email in error, please immediately notify the sender by return email and delete this email from your system- Thank you.

 
_______________________________________________
XCCDF-dev mailing list
[hidden email]
To unsubscribe, send an email message to [hidden email].


_______________________________________________
XCCDF-dev mailing list
[hidden email]
To unsubscribe, send an email message to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: [Xccdf-dev] [OVAL DEVELOPER] SQLEXT OVAL Extension Proposal

Vishal Palkar
In reply to this post by Melvin Steward
Why I am still getting this emails?

On Dec 9, 2015 4:21 PM, Melvin Steward <[hidden email]> wrote:

>
> David 
>
> I've been following the developments on this thread for a while now and wanted to write to you directly about using what you're developing to handle the security details for embedded devices on a industrial SCADA/DCS network 
>
> I haven't seen very much on this thread that talks about such an application, but based on what I've seen on this topic it would pretty much follow the same pattern.
>
> NIST has a special publication for industrial systems. This application is connected with the DHS critical infrastructure security project that's been going on since 2012.
>
> Prince Riley is the technical lead on this and I've copied him on this email so you can reply directly back to him 
>
> Thanks 
>
> On Monday, December 7, 2015, David Solin <[hidden email]> wrote:
>>
>> Doug,
>>
>> I have not forgotten your SQLEXT proposal for the OVAL language, and have been working on some XCCDF/SCAP ground-work that is required before I suggest updates to the XCCDF schema itself, to address your use-case.
>>
>> First, we need to clarify the operation of the SCAP requirement, SCAP.R.2000.5, as this is the underlying capability that I am planning on utilizing for the solution.  Not all SCAP 1.2-validated tools meet the requirement because it was under-specified, so this is something that should be addressed in SCAP 1.3.
>>
>> I have attached a sample ARF that illustrates how the same external check, with different variable exports, can be handled for the three SCAP check systems (OVAL, OCIL, and informally, SCE).
>>
>> The model works well with OVAL and SCE, but there is an issue with OCIL in that variable values are not expressed in the OCIL results format (this makes it impossible to associate arbitrary OCIL results with a set of XCCDF variable exports).  To address that problem, I have added a few new types to the “gOCIL” variables schema (see https://github.com/joval/jOVAL/blob/master/scap/schemas/ocil-2.0/ocil-variables-schema.xsd).  The new types, UserWithVariablesType and SystemWithVariablesType, make use of the OCIL results target substitution group to make it possible to add variable values to OCIL results without requiring any changes to the existing OCIL 2.0 schema.
>>
>> With this mechanism is place, it will be possible to define a new XCCDF ValueType that obtains its values from an external check.  We can document that, if multiple results are returned for the check system for the value, we treat the resulting values as generating discrete Rule instances.
>>
>> This concept already exists in XCCDF, via the Rule@multiple attribute.  We could simply disregard the sentence "For example, OVAL checks cannot produce separate results for individual instances of a target.” in table 9’s description of the RuleType@multiple attribute in the XCCDF specification, and then evaluate according to the existing specification.
>>
>> As a side-note, we could also document in SCAP 1.3 that a complex-value is simply a Value that can have multiple values without implying that there must be multiple corresponding Rule instances.  The OVAL check system permits variables to have multiple values, as we all well know, but OCIL and SCE do not have a concept of multi-valued variables, so it would remain invalid to use complex values in conjunction with those systems.
>>
>> If we accept this change, then if someone wanted to make use of an OVAL import as a Value without creating multiple instances of a downstream Rule, they could simply import it as a complex type.
>>
>> Let me know if you have any feedback regarding this approach.  In the meantime I’m going to investigate what would be the minimal set of changes to XCCDF that would be required to support this new value type.
>>
>> Best regards,
>> —David Solin
>>
>
>
> --
> Sent from my BlackBerry® smartphone with SprintSpeed
> ++++++CONFIDENTIALITY NOTICE++++++
> The information in this email may be confidential and/or privileged. This email is intended to be reviewed only by the individual or organization named above. If you are not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any review, dissemination, storage, or copying of this email and its attachments, if any, or the information contained herein is prohibited.  If you have received this email in error, please immediately notify the sender by return email and delete this email from your system- Thank you.
>
>  

_______________________________________________
XCCDF-dev mailing list
[hidden email]
To unsubscribe, send an email message to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: [Xccdf-dev] [OVAL DEVELOPER] SQLEXT OVAL Extension Proposal

Wild, Mike P.
Cuz your're super duper important like me!

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Vishal Palkar
Sent: Saturday, December 12, 2015 8:32 AM
To: [hidden email]
Cc: Pinnacle Systems Group <[hidden email]>
Subject: Re: [Xccdf-dev] [OVAL DEVELOPER] SQLEXT OVAL Extension Proposal

Why I am still getting this emails?

On Dec 9, 2015 4:21 PM, Melvin Steward <[hidden email]> wrote:

>
> David 
>
> I've been following the developments on this thread for a while now and wanted to write to you directly about using what you're developing to handle the security details for embedded devices on a industrial SCADA/DCS network 
>
> I haven't seen very much on this thread that talks about such an application, but based on what I've seen on this topic it would pretty much follow the same pattern.
>
> NIST has a special publication for industrial systems. This application is connected with the DHS critical infrastructure security project that's been going on since 2012.
>
> Prince Riley is the technical lead on this and I've copied him on this email so you can reply directly back to him 
>
> Thanks 
>
> On Monday, December 7, 2015, David Solin <[hidden email]> wrote:
>>
>> Doug,
>>
>> I have not forgotten your SQLEXT proposal for the OVAL language, and have been working on some XCCDF/SCAP ground-work that is required before I suggest updates to the XCCDF schema itself, to address your use-case.
>>
>> First, we need to clarify the operation of the SCAP requirement, SCAP.R.2000.5, as this is the underlying capability that I am planning on utilizing for the solution.  Not all SCAP 1.2-validated tools meet the requirement because it was under-specified, so this is something that should be addressed in SCAP 1.3.
>>
>> I have attached a sample ARF that illustrates how the same external check, with different variable exports, can be handled for the three SCAP check systems (OVAL, OCIL, and informally, SCE).
>>
>> The model works well with OVAL and SCE, but there is an issue with OCIL in that variable values are not expressed in the OCIL results format (this makes it impossible to associate arbitrary OCIL results with a set of XCCDF variable exports).  To address that problem, I have added a few new types to the “gOCIL” variables schema (see https://github.com/joval/jOVAL/blob/master/scap/schemas/ocil-2.0/ocil-variables-schema.xsd).  The new types, UserWithVariablesType and SystemWithVariablesType, make use of the OCIL results target substitution group to make it possible to add variable values to OCIL results without requiring any changes to the existing OCIL 2.0 schema.
>>
>> With this mechanism is place, it will be possible to define a new XCCDF ValueType that obtains its values from an external check.  We can document that, if multiple results are returned for the check system for the value, we treat the resulting values as generating discrete Rule instances.
>>
>> This concept already exists in XCCDF, via the Rule@multiple attribute.  We could simply disregard the sentence "For example, OVAL checks cannot produce separate results for individual instances of a target.” in table 9’s description of the RuleType@multiple attribute in the XCCDF specification, and then evaluate according to the existing specification.
>>
>> As a side-note, we could also document in SCAP 1.3 that a complex-value is simply a Value that can have multiple values without implying that there must be multiple corresponding Rule instances.  The OVAL check system permits variables to have multiple values, as we all well know, but OCIL and SCE do not have a concept of multi-valued variables, so it would remain invalid to use complex values in conjunction with those systems.
>>
>> If we accept this change, then if someone wanted to make use of an OVAL import as a Value without creating multiple instances of a downstream Rule, they could simply import it as a complex type.
>>
>> Let me know if you have any feedback regarding this approach.  In the meantime I’m going to investigate what would be the minimal set of changes to XCCDF that would be required to support this new value type.
>>
>> Best regards,
>> —David Solin
>>
>
>
> --
> Sent from my BlackBerry® smartphone with SprintSpeed
> ++++++CONFIDENTIALITY NOTICE++++++
> The information in this email may be confidential and/or privileged. This email is intended to be reviewed only by the individual or organization named above. If you are not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any review, dissemination, storage, or copying of this email and its attachments, if any, or the information contained herein is prohibited.  If you have received this email in error, please immediately notify the sender by return email and delete this email from your system- Thank you.
>
>  

_______________________________________________
XCCDF-dev mailing list
[hidden email]
To unsubscribe, send an email message to [hidden email].

_______________________________________________
XCCDF-dev mailing list
[hidden email]
To unsubscribe, send an email message to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: [Xccdf-dev] [OVAL DEVELOPER] SQLEXT OVAL Extension Proposal

Landfield, Kent B
Maybe you  both should take a minute and go to
http://scap.nist.gov/community.html  and select the unsubscribe link
instead of spamming hundreds or more people who are interested in what is
discussed hereŠ

Sigh..

---
Kent Landfield



On 12/14/15, 7:06 AM, "[hidden email] on behalf of Wild, Mike
P." <[hidden email] on behalf of [hidden email]> wrote:

>Cuz your're super duper important like me!
>
>-----Original Message-----
>From: [hidden email] [mailto:[hidden email]] On
>Behalf Of Vishal Palkar
>Sent: Saturday, December 12, 2015 8:32 AM
>To: [hidden email]
>Cc: Pinnacle Systems Group <[hidden email]>
>Subject: Re: [Xccdf-dev] [OVAL DEVELOPER] SQLEXT OVAL Extension Proposal
>
>Why I am still getting this emails?
>
>On Dec 9, 2015 4:21 PM, Melvin Steward <[hidden email]>
>wrote:
>>
>> David
>>
>> I've been following the developments on this thread for a while now and
>>wanted to write to you directly about using what you're developing to
>>handle the security details for embedded devices on a industrial
>>SCADA/DCS network
>>
>> I haven't seen very much on this thread that talks about such an
>>application, but based on what I've seen on this topic it would pretty
>>much follow the same pattern.
>>
>> NIST has a special publication for industrial systems. This application
>>is connected with the DHS critical infrastructure security project
>>that's been going on since 2012.
>>
>> Prince Riley is the technical lead on this and I've copied him on this
>>email so you can reply directly back to him
>>
>> Thanks
>>
>> On Monday, December 7, 2015, David Solin <[hidden email]>
>>wrote:
>>>
>>> Doug,
>>>
>>> I have not forgotten your SQLEXT proposal for the OVAL language, and
>>>have been working on some XCCDF/SCAP ground-work that is required
>>>before I suggest updates to the XCCDF schema itself, to address your
>>>use-case.
>>>
>>> First, we need to clarify the operation of the SCAP requirement,
>>>SCAP.R.2000.5, as this is the underlying capability that I am planning
>>>on utilizing for the solution.  Not all SCAP 1.2-validated tools meet
>>>the requirement because it was under-specified, so this is something
>>>that should be addressed in SCAP 1.3.
>>>
>>> I have attached a sample ARF that illustrates how the same external
>>>check, with different variable exports, can be handled for the three
>>>SCAP check systems (OVAL, OCIL, and informally, SCE).
>>>
>>> The model works well with OVAL and SCE, but there is an issue with
>>>OCIL in that variable values are not expressed in the OCIL results
>>>format (this makes it impossible to associate arbitrary OCIL results
>>>with a set of XCCDF variable exports).  To address that problem, I have
>>>added a few new types to the ³gOCIL² variables schema (see
>>>https://github.com/joval/jOVAL/blob/master/scap/schemas/ocil-2.0/ocil-va
>>>riables-schema.xsd).  The new types, UserWithVariablesType and
>>>SystemWithVariablesType, make use of the OCIL results target
>>>substitution group to make it possible to add variable values to OCIL
>>>results without requiring any changes to the existing OCIL 2.0 schema.
>>>
>>> With this mechanism is place, it will be possible to define a new
>>>XCCDF ValueType that obtains its values from an external check.  We can
>>>document that, if multiple results are returned for the check system
>>>for the value, we treat the resulting values as generating discrete
>>>Rule instances.
>>>
>>> This concept already exists in XCCDF, via the Rule@multiple attribute.
>>> We could simply disregard the sentence "For example, OVAL checks
>>>cannot produce separate results for individual instances of a target.²
>>>in table 9¹s description of the RuleType@multiple attribute in the
>>>XCCDF specification, and then evaluate according to the existing
>>>specification.
>>>
>>> As a side-note, we could also document in SCAP 1.3 that a
>>>complex-value is simply a Value that can have multiple values without
>>>implying that there must be multiple corresponding Rule instances.  The
>>>OVAL check system permits variables to have multiple values, as we all
>>>well know, but OCIL and SCE do not have a concept of multi-valued
>>>variables, so it would remain invalid to use complex values in
>>>conjunction with those systems.
>>>
>>> If we accept this change, then if someone wanted to make use of an
>>>OVAL import as a Value without creating multiple instances of a
>>>downstream Rule, they could simply import it as a complex type.
>>>
>>> Let me know if you have any feedback regarding this approach.  In the
>>>meantime I¹m going to investigate what would be the minimal set of
>>>changes to XCCDF that would be required to support this new value type.
>>>
>>> Best regards,
>>> ‹David Solin
>>>
>>
>>
>> --
>> Sent from my BlackBerry® smartphone with SprintSpeed
>> ++++++CONFIDENTIALITY NOTICE++++++
>> The information in this email may be confidential and/or privileged.
>>This email is intended to be reviewed only by the individual or
>>organization named above. If you are not the intended recipient or an
>>authorized representative of the intended recipient, you are hereby
>>notified that any review, dissemination, storage, or copying of this
>>email and its attachments, if any, or the information contained herein
>>is prohibited.  If you have received this email in error, please
>>immediately notify the sender by return email and delete this email from
>>your system- Thank you.
>>
>>  
>
>_______________________________________________
>XCCDF-dev mailing list
>[hidden email]
>To unsubscribe, send an email message to [hidden email].
>
>_______________________________________________
>XCCDF-dev mailing list
>[hidden email]
>To unsubscribe, send an email message to [hidden email].


_______________________________________________
XCCDF-dev mailing list
[hidden email]
To unsubscribe, send an email message to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: [Xccdf-dev] [OVAL DEVELOPER] SQLEXT OVAL Extension Proposal

Wild, Mike P.
Why don’t you take a long walk off a short pier and keep your jerkoff comments to yourself

-----Original Message-----
From: Landfield, Kent B [mailto:[hidden email]]
Sent: Monday, December 14, 2015 7:18 AM
To: [hidden email]
Cc: Pinnacle Systems Group <[hidden email]>; Wild, Mike P. <[hidden email]>
Subject: Re: [Xccdf-dev] [OVAL DEVELOPER] SQLEXT OVAL Extension Proposal

Maybe you  both should take a minute and go to http://scap.nist.gov/community.html  and select the unsubscribe link instead of spamming hundreds or more people who are interested in what is discussed hereŠ

Sigh..

---
Kent Landfield



On 12/14/15, 7:06 AM, "[hidden email] on behalf of Wild, Mike P." <[hidden email] on behalf of [hidden email]> wrote:

>Cuz your're super duper important like me!
>
>-----Original Message-----
>From: [hidden email] [mailto:[hidden email]] On
>Behalf Of Vishal Palkar
>Sent: Saturday, December 12, 2015 8:32 AM
>To: [hidden email]
>Cc: Pinnacle Systems Group <[hidden email]>
>Subject: Re: [Xccdf-dev] [OVAL DEVELOPER] SQLEXT OVAL Extension
>Proposal
>
>Why I am still getting this emails?
>
>On Dec 9, 2015 4:21 PM, Melvin Steward <[hidden email]>
>wrote:
>>
>> David
>>
>> I've been following the developments on this thread for a while now
>>and wanted to write to you directly about using what you're developing
>>to handle the security details for embedded devices on a industrial
>>SCADA/DCS network
>>
>> I haven't seen very much on this thread that talks about such an
>>application, but based on what I've seen on this topic it would pretty
>>much follow the same pattern.
>>
>> NIST has a special publication for industrial systems. This
>>application is connected with the DHS critical infrastructure security
>>project that's been going on since 2012.
>>
>> Prince Riley is the technical lead on this and I've copied him on
>>this email so you can reply directly back to him
>>
>> Thanks
>>
>> On Monday, December 7, 2015, David Solin
>><[hidden email]>
>>wrote:
>>>
>>> Doug,
>>>
>>> I have not forgotten your SQLEXT proposal for the OVAL language, and
>>>have been working on some XCCDF/SCAP ground-work that is required
>>>before I suggest updates to the XCCDF schema itself, to address your
>>>use-case.
>>>
>>> First, we need to clarify the operation of the SCAP requirement,
>>>SCAP.R.2000.5, as this is the underlying capability that I am
>>>planning on utilizing for the solution.  Not all SCAP 1.2-validated
>>>tools meet the requirement because it was under-specified, so this is
>>>something that should be addressed in SCAP 1.3.
>>>
>>> I have attached a sample ARF that illustrates how the same external
>>>check, with different variable exports, can be handled for the three
>>>SCAP check systems (OVAL, OCIL, and informally, SCE).
>>>
>>> The model works well with OVAL and SCE, but there is an issue with
>>>OCIL in that variable values are not expressed in the OCIL results
>>>format (this makes it impossible to associate arbitrary OCIL results
>>>with a set of XCCDF variable exports).  To address that problem, I
>>>have added a few new types to the ³gOCIL² variables schema (see
>>>https://github.com/joval/jOVAL/blob/master/scap/schemas/ocil-2.0/ocil
>>>-va riables-schema.xsd).  The new types, UserWithVariablesType and
>>>SystemWithVariablesType, make use of the OCIL results target
>>>substitution group to make it possible to add variable values to OCIL
>>>results without requiring any changes to the existing OCIL 2.0 schema.
>>>
>>> With this mechanism is place, it will be possible to define a new
>>>XCCDF ValueType that obtains its values from an external check.  We
>>>can document that, if multiple results are returned for the check
>>>system for the value, we treat the resulting values as generating
>>>discrete Rule instances.
>>>
>>> This concept already exists in XCCDF, via the Rule@multiple attribute.
>>> We could simply disregard the sentence "For example, OVAL checks
>>>cannot produce separate results for individual instances of a
>>>target.² in table 9¹s description of the RuleType@multiple attribute
>>>in the XCCDF specification, and then evaluate according to the
>>>existing specification.
>>>
>>> As a side-note, we could also document in SCAP 1.3 that a
>>>complex-value is simply a Value that can have multiple values without
>>>implying that there must be multiple corresponding Rule instances.  
>>>The OVAL check system permits variables to have multiple values, as
>>>we all well know, but OCIL and SCE do not have a concept of
>>>multi-valued variables, so it would remain invalid to use complex
>>>values in conjunction with those systems.
>>>
>>> If we accept this change, then if someone wanted to make use of an
>>>OVAL import as a Value without creating multiple instances of a
>>>downstream Rule, they could simply import it as a complex type.
>>>
>>> Let me know if you have any feedback regarding this approach.  In
>>>the meantime I¹m going to investigate what would be the minimal set
>>>of changes to XCCDF that would be required to support this new value type.
>>>
>>> Best regards,
>>> ‹David Solin
>>>
>>
>>
>> --
>> Sent from my BlackBerry® smartphone with SprintSpeed
>> ++++++CONFIDENTIALITY NOTICE++++++
>> The information in this email may be confidential and/or privileged.
>>This email is intended to be reviewed only by the individual or
>>organization named above. If you are not the intended recipient or an
>>authorized representative of the intended recipient, you are hereby
>>notified that any review, dissemination, storage, or copying of this
>>email and its attachments, if any, or the information contained herein
>>is prohibited.  If you have received this email in error, please
>>immediately notify the sender by return email and delete this email
>>from your system- Thank you.
>>
>>  
>
>_______________________________________________
>XCCDF-dev mailing list
>[hidden email]
>To unsubscribe, send an email message to [hidden email].
>
>_______________________________________________
>XCCDF-dev mailing list
>[hidden email]
>To unsubscribe, send an email message to [hidden email].


_______________________________________________
XCCDF-dev mailing list
[hidden email]
To unsubscribe, send an email message to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: [Xccdf-dev] [Non-DoD Source] [OVAL DEVELOPER] SQLEXT OVAL Extension Proposal

David Solin-3
In reply to this post by JA
Thanks, Jerome, but surely I haven’t done any more than anyone else who shared an interest in Doug's problem would have done.

There is one additional area for discussion with this approach that I neglected to mention, which is that check-imports are not very well-defined for the various check systems.

Our implementation supports checkImportType@import-names corresponding to variable IDs for OVAL and OCIL checks (and a name we call “stdout” for SCE checks, upon which the @import-xpath can operate if the output happens to be XML).  We chose to implement this because of the obvious symmetry with the checkExportType@export-name attribute.  But this requires a conscious and complex interweaving of variables and objects to insure the desired variable value is computed.

So, do we want to explicitly define any conventions about how the check-imports should work with OVAL (and potentially other check systems)?  I believe we should, and this should be hashed out as part of SCAP 1.3.

Best regards,
—David A. Solin
Co-Founder, Research & Technology
[hidden email]



 

> On Dec 11, 2015, at 10:43 PM, Jerome Athias <[hidden email]> wrote:
>
> David,
>
> this seems awesome
> (but You, for sure, are awesome ;-))
>
> We would have to investigate how we could use that with the CIS Benchmarks
>
> Cheers
>
>> On Dec 11, 2015, at 6:31 PM, David Solin <[hidden email]> wrote:
>>
>> Hi Doug,
>>
>> I’ve finally finished fleshing out my proposal for your use-case!
>>
>> I have attached a modified xccdf_1.2.xsd, which is a modified schema for XCCDF.  It is fully backwards-compatible with XCCDF 1.2, but adds a few new types:
>>
>> New Type: selImportType
>> Description: This new type is similar to selStringType and selComplexValueType, in that it can be used to assign a value to a ValueType and can be associated with a selector (by attribute).  However, unlike selStringType and selComplexValueType, a selImportType has the ability to import its value from an external check system.  This is achieved using an embedded CheckType.  The embedded check has some restrictions placed by the schema — it must include a single check-import (which defines the value that will be imported from the check system), and it is not permitted to include any check-exports (to eliminate the issue of Value recursion with the determination of instance values).  In place of the check-export, there is a new inline-export element that can be used to assign exported variable values for the check "on the spot”.  Finally, an attribute, “type” (possible values: “simple” and “complex”) is used to identify the result as being either a simple or complex value.
>>
>> New Type: inlineExportType
>> Description: This type can be used to define any value that is exported by a check without reference to any valueType defined in the XCCDF document.  Think of it as a static value declaration.  Its purpose is mainly to simplify the process of defining any values that need to be exported to a check used by a selImportType, but I have modified the schema so that it can be used by any checkType in XCCDF.  (This was necessary to make it possible to use a checkType restriction as a child of the selImportType, instead of having to define a highly duplicative variation of that type).
>>
>> I am also proposing a modification to some parts of the SCAP specification...
>>
>> Currently, the SCAP 1.2 specification only permits the use of “simple” valueTypes in check-exports.  I believe we can decide that a “complex” value merely indicates a single valueType with multiple underlying values, and permit its use.  In OVAL, for example, a variable may hold multiple values at the same time.  We can use the XCCDF complexValueType (and its sub-type, selComplexValueType) to express such a multi-valued variable.
>>
>> It’s easy to understand how a complex selImportType, whose check-import has multiple values will work.  But, what if a selImportType is defined as “simple”, but its check-import ends up producing multiple results?
>>
>> Well, I propose that we say in such cases, any XCCDF check making use of such a value becomes a permutation — that is, it should behave a lot like a check whose check-content-ref has an href, but no name.  For that case, we have the multi-check attribute that defines how to express the rule results (as a single roll-up, or as a list of permutations).  In the case of a multi-valued simple value in XCCDF, we can use the heretofore unused ruleType@multiple attribute to dictate the behavior.
>>
>> The attached ARF XML file illustrates the use of the new types, as well as all the behaviors I’ve described above.
>>
>> These new tools will make it possible for someone to write a benchmark that (1) discovers relevant instances of a database on a target machine, and (2) implements one or more compliance rules that is applied to each of those instances, which can be reported distinctly or as a roll-up.
>>
>> Thoughts? Comments?
>>
>> Best regards,
>> —David Solin
>>
>> <xccdf_1.2.xsd><arf.xml>
>>
>>
>>> On Dec 7, 2015, at 10:19 AM, Tanner, Douglas C CIV SPAWARSYSCEN-ATLANTIC, 58510 <[hidden email]> wrote:
>>>
>>> David -
>>>
>>>
>>>
>>> I believe you meant to send this to the other Doug on the team. I've CC'd him.
>>>
>>>
>>>
>>> Doug Tanner
>>>
>>> ________________________________
>>> From: David Solin [[hidden email]]
>>> Sent: Monday, December 07, 2015 10:35 AM
>>> To: Tanner, Douglas C CIV SPAWARSYSCEN-ATLANTIC, 58510
>>> Cc: [hidden email]; Waltermire, David A.
>>> Subject: [Non-DoD Source] Re: [OVAL DEVELOPER] SQLEXT OVAL Extension Proposal
>>>
>>> Doug,
>>>
>>> I have not forgotten your SQLEXT proposal for the OVAL language, and have been working on some XCCDF/SCAP ground-work that is required before I suggest updates to the XCCDF schema itself, to address your use-case.
>>>
>>> First, we need to clarify the operation of the SCAP requirement, SCAP.R.2000.5, as this is the underlying capability that I am planning on utilizing for the solution.  Not all SCAP 1.2-validated tools meet the requirement because it was under-specified, so this is something that should be addressed in SCAP 1.3.
>>>
>>> I have attached a sample ARF that illustrates how the same external check, with different variable exports, can be handled for the three SCAP check systems (OVAL, OCIL, and informally, SCE).
>>>
>>> The model works well with OVAL and SCE, but there is an issue with OCIL in that variable values are not expressed in the OCIL results format (this makes it impossible to associate arbitrary OCIL results with a set of XCCDF variable exports).  To address that problem, I have added a few new types to the “gOCIL” variables schema (see https://github.com/joval/jOVAL/blob/master/scap/schemas/ocil-2.0/ocil-variables-schema.xsd).  The new types, UserWithVariablesType and SystemWithVariablesType, make use of the OCIL results target substitution group to make it possible to add variable values to OCIL results without requiring any changes to the existing OCIL 2.0 schema.
>>>
>>> With this mechanism is place, it will be possible to define a new XCCDF ValueType that obtains its values from an external check.  We can document that, if multiple results are returned for the check system for the value, we treat the resulting values as generating discrete Rule instances.
>>>
>>> This concept already exists in XCCDF, via the Rule@multiple attribute.  We could simply disregard the sentence "For example, OVAL checks cannot produce separate results for individual instances of a target.” in table 9’s description of the RuleType@multiple attribute in the XCCDF specification, and then evaluate according to the existing specification.
>>>
>>> As a side-note, we could also document in SCAP 1.3 that a complex-value is simply a Value that can have multiple values without implying that there must be multiple corresponding Rule instances.  The OVAL check system permits variables to have multiple values, as we all well know, but OCIL and SCE do not have a concept of multi-valued variables, so it would remain invalid to use complex values in conjunction with those systems.
>>>
>>> If we accept this change, then if someone wanted to make use of an OVAL import as a Value without creating multiple instances of a downstream Rule, they could simply import it as a complex type.
>>>
>>> Let me know if you have any feedback regarding this approach.  In the meantime I’m going to investigate what would be the minimal set of changes to XCCDF that would be required to support this new value type.
>>>
>>> Best regards,
>>> —David Solin
>>>
>>>
>>> On Oct 5, 2015, at 8:13 AM, David Solin <[hidden email]<mailto:[hidden email]>> wrote:
>>>
>>> I had previously replied only to Douglas; I am forwarding that response (below) for any community feedback.
>>>
>>> Begin forwarded message:
>>>
>>> From: David Solin <[hidden email]<mailto:[hidden email]>>
>>> Subject: Re: [OVAL DEVELOPER] SQLEXT OVAL Extension Proposal
>>> Date: October 1, 2015 at 6:03:34 PM CDT
>>> To: "McIlroy, Douglas M CIV SPAWARSYSCEN-ATLANTIC, 58600" <[hidden email]<mailto:[hidden email]>>
>>>
>>> Thanks for your insights, Douglas.  Please see my own thoughts inline, below.
>>>
>>>
>>> On Oct 1, 2015, at 4:04 PM, McIlroy, Douglas M CIV SPAWARSYSCEN-ATLANTIC, 58600 <[hidden email]<mailto:[hidden email]>> wrote:
>>>
>>> David,
>>>
>>>
>>>
>>> Yes, this SQLEXT proposal supports behavior for addressing individual RDBMS instances (the term "instance" as used here refers to any query-able server process spawned by a given DBMS software installation) and named database schemas as top-level targets, and then outputting a dedicated result file for each target. Furthermore, SQLEXT is indeed a platform-agnostic SQL probe that can support DBMS products other than Microsoft SQL Server. The following Oracle, MySQL, and PostgreSQL documentation provides guidance for configuring multiple instances of a given DBMS on a host system:
>>>
>>>
>>>
>>> https://docs.oracle.com/cd/E11882_01/server.112/e40540/startup.htm#CNCPT89033
>>>
>>>
>>>
>>> https://dev.mysql.com/doc/refman/5.0/en/multiple-servers.html
>>>
>>>
>>>
>>> https://opensourcedbms.com/dbms/running-multiple-postgresql-9-2-instances-on-one-server-in-centos-6rhel-6fedora/
>>>
>>>
>>>
>>> Of course most (if not all) databases support running multiple instances on the same machine.  But apart from MS SQL Server, I don’t believe they are readily discoverable.  To determine which instances are running, for Oracle or MySQL or Postgres, it would be necessary for a tool to discover running processes, read their environments and command-line parameters, and reverse-engineer their configurations, in order to determine how to connect to each.  If the instances are not running at scan-time, then all bets are off.
>>>
>>> This makes the implementation of <instance operation=“pattern match”>.*</instance> VERY problematic.
>>>
>>>
>>>
>>>
>>> Also, other DBMS's aside from MS SQL Server, such as MySQL, do support hosting multiple named DB schemas per instance. One common counter-example, though, would be Oracle Database, which allocates an instance for each database schema, leading to the concepts of an Oracle DB "instance" and "database" being effectively equivalent. Therefore, the "instance" and "database" context behaviors would be interchangeable when being implemented for an Oracle DB evaluation.
>>>
>>>
>>> Indeed, some do.  But to discover their names, you must first connect to a server instance in a management context.  And connecting to an instance without all the connection information is problematic.
>>>
>>> Perhaps you're actually proposing that the SCAP scanning utility should be pre-populated with lists of all the instances on each machine, and how to connect to them.  That would eliminate the discovery problem, but I didn’t get that impression from the proposal.
>>>
>>>
>>> Furthermore, in light of the lack of traction that the SQL57 spec has seen so far, we are not sure how productive attempting to augment it any further would be. Not much so far has come of attempting to incorporate SQL57 into the DISA STIGs due to the inflexibility and insecurity of the "connection_string" entity, so SQLEXT is being proposed as an alternative that addresses those complications.
>>>
>>>
>>> I have to say, since it has always been possible to provide a connection_string value via an external_variable, I’ve personally never really understood the complaints.  Is it that the variable values would appear in the results?  The mask attribute might address that.
>>>
>>> In the case of Joval, it’s possible to supply a connection_string with no username/password at all, in which case we use the credential supplied for connecting to the target machine.  In practice this can actually be useful when scanning MS SQL Servers that have been configured to leverage the Windows user account database.  We have had some success running the CIS MS SQL Server content through our product using the existing features.
>>>
>>>
>>>
>>>
>>> Also, while extending XCCDF to support multiple top-level evaluation targets per host system is a great idea, we needed to pursue a solution that would be available in the near-term and that would support raw-OVAL evaluations that don't include an XCCDF benchmark. However, given that leveraging XCCDF to control the content processing model of a SCAP stream makes more sense than SQLEXT's raw-OVAL top-up approach, an update to the XCCDF spec would be welcome. Especially when considering other non-RDBM applications such as IIS, Apache, and Tomcat that also support being instantiated multiple times with a dedicated configuration for each instance, there definitely needs to be a discussion about how to make SCAP overall more fit for enterprise-grade applications.
>>>
>>>
>>> I agree.  From a technical standpoint,  a non-standard upgrade to XCCDF should at least be no “worse” than a non-standard addition to OVAL.
>>>
>>>
>>>
>>>
>>> ________________________________
>>> From: David Solin [[hidden email]<mailto:[hidden email]>]
>>> Sent: Wednesday, September 30, 2015 5:28 PM
>>> To: McIlroy, Douglas M CIV SPAWARSYSCEN-ATLANTIC, 58600
>>> Cc: [hidden email]<mailto:[hidden email]>; [hidden email]<mailto:[hidden email]>
>>> Subject: Re: [OVAL DEVELOPER] SQLEXT OVAL Extension Proposal
>>>
>>> Hi Doug (and cross-posting to xccdf-dev),
>>>
>>> I’m not really able to easily discern from the samples on Github… but, recalling the sql511 proposal, is the thrust of this proposal that the behaviors result in splitting out per-host, per-instance or per-database (depending on the behavior specified) into different result files?
>>>
>>> Notwithstanding the answer to that question, I have a few initial thoughts:
>>>
>>> This is not really a generic SQL test at all, but a Microsoft SQL Server test.  Only MSSQL has readily-discoverable instances.  Other RDBMS’s do not really have readily-discoverable instances, and also, they do not all support having multiple ‘databases’ within a single instance.  This was sort of the sole virtue of the connection_string — it identifies the target instance.  (This is also why both generic database-connectivity mechanisms I’ve personally used, ODBC and JDBC, support the concept of connection properties).
>>>
>>> This appears to me to really, at heart, be a proposal to delegate instance/database discovery to the OVAL language.  It is certainly already possible using external_variables to target a piece of OVAL content to whatever combination of instances and databases one pleases — provided that those instances and databases are known to the tool that is doing the targeting (by setting the variable values).
>>>
>>> If this is indeed the case, and if databases should indeed be treated as first-class targets, then it would make perfect sense to create entire SCAP benchmarks dedicated to evaluating databases, and measure compliance of each instance against that benchmark, rather than (as this proposal embodies) attempt to combine what should be multiple first-class target assessments into a single machine assessment result.
>>>
>>> As an alternative to this approach, I would propose making a few changes to XCCDF and SCAP that would make it possible to do exactly what you guys want and leverage the existing sql57 test:
>>>
>>> 1.  Create selRefType and selComplexRefType types in XCCDF that make it possible to reference an exported value from a check system
>>> 2.  Add support for the XCCDF ComplexValueType in SCAP — defining it as a mechanism to evaluate multiple instances of a check evaluated via the multi-check attribute, or if via a complex-check, according to the complex-check’s operator attribute.
>>>
>>> Was this an approach you guys have considered?  I’d be happy to collaborate with you to make these changes to XCCDF.  We could call it XCCDF 1.3.
>>>
>>> Best regards,
>>> —David Solin
>>>
>>>
>>>
>>> David A. Solin
>>> Co-Founder, Research & Technology
>>> [hidden email]<mailto:[hidden email]><mailto:[hidden email]>
>>>
>>> [Joval Continuous Monitoring] <http://jovalcm.com/>
>>>
>>> [Facebook] <https://www.facebook.com/jovalcm> [Linkedin]  <https://www.linkedin.com/company/joval-continuous-monitoring>
>>>
>>>
>>> On Sep 30, 2015, at 11:41 AM, McIlroy, Douglas M CIV SPAWARSYSCEN-ATLANTIC, 58600 <[hidden email]<mailto:[hidden email]><mailto:[hidden email]>> wrote:
>>>
>>> Due to the need for automated compliance and vulnerability checks against SQL database management systems and a lack of support for the proposed sql511 test in OVAL 5.11, SPAWAR submits this new proposal for an OVAL extension which addresses the sql511 deficiencies. The current working designation for this proposal is “sqlext” (SQL Test for the OVAL Extension Schema). This is subject to change based upon discussion with the OVAL community regarding standard naming conventions for OVAL extensions. Please see the attached proposal document for further explanation as well as the SQLEXT OVAL Sandbox GitHub fork (https://github.com/mcilroyd/Sandbox/tree/master/resources/x-ind-sqlext) for sample content, results output, and XML schemas. We are looking forward to any feedback and recomendations that the community has to share for SQLEXT.
>>>
>>> ...<SQLExt Proposal.pdf>_______________________________________________
>>> OVAL_Developer mailing list
>>> [hidden email]<mailto:[hidden email]><mailto:[hidden email]>
>>> http://lists.cisecurity.org/mailman/listinfo/oval_developer_lists.cisecurity.org
>>>
>>> <jovalcm.color.225.png><fb.rounded.png><li.rounded.png>
>>>
>>>
>>>
>>
>> David A. Solin
>> Co-Founder, Research & Technology
>> [hidden email]
>>
>>
>>
>>
>>
>> _______________________________________________
>> XCCDF-dev mailing list
>> [hidden email]
>> To unsubscribe, send an email message to [hidden email].
>
>
> _______________________________________________
> XCCDF-dev mailing list
> [hidden email]
> To unsubscribe, send an email message to [hidden email].


_______________________________________________
XCCDF-dev mailing list
[hidden email]
To unsubscribe, send an email message to [hidden email].
JA
Reply | Threaded
Open this post in threaded view
|

Re: [Xccdf-dev] [Non-DoD Source] [OVAL DEVELOPER] SQLEXT OVAL Extension Proposal

JA
I also see interesting capabilities doing this :)

2015-12-14 17:14 GMT+03:00 David Solin <[hidden email]>:

> Thanks, Jerome, but surely I haven’t done any more than anyone else who shared an interest in Doug's problem would have done.
>
> There is one additional area for discussion with this approach that I neglected to mention, which is that check-imports are not very well-defined for the various check systems.
>
> Our implementation supports checkImportType@import-names corresponding to variable IDs for OVAL and OCIL checks (and a name we call “stdout” for SCE checks, upon which the @import-xpath can operate if the output happens to be XML).  We chose to implement this because of the obvious symmetry with the checkExportType@export-name attribute.  But this requires a conscious and complex interweaving of variables and objects to insure the desired variable value is computed.
>
> So, do we want to explicitly define any conventions about how the check-imports should work with OVAL (and potentially other check systems)?  I believe we should, and this should be hashed out as part of SCAP 1.3.
>
> Best regards,
> —David A. Solin
> Co-Founder, Research & Technology
> [hidden email]
>
>
>
>
>
>> On Dec 11, 2015, at 10:43 PM, Jerome Athias <[hidden email]> wrote:
>>
>> David,
>>
>> this seems awesome
>> (but You, for sure, are awesome ;-))
>>
>> We would have to investigate how we could use that with the CIS Benchmarks
>>
>> Cheers
>>
>>> On Dec 11, 2015, at 6:31 PM, David Solin <[hidden email]> wrote:
>>>
>>> Hi Doug,
>>>
>>> I’ve finally finished fleshing out my proposal for your use-case!
>>>
>>> I have attached a modified xccdf_1.2.xsd, which is a modified schema for XCCDF.  It is fully backwards-compatible with XCCDF 1.2, but adds a few new types:
>>>
>>> New Type: selImportType
>>> Description: This new type is similar to selStringType and selComplexValueType, in that it can be used to assign a value to a ValueType and can be associated with a selector (by attribute).  However, unlike selStringType and selComplexValueType, a selImportType has the ability to import its value from an external check system.  This is achieved using an embedded CheckType.  The embedded check has some restrictions placed by the schema — it must include a single check-import (which defines the value that will be imported from the check system), and it is not permitted to include any check-exports (to eliminate the issue of Value recursion with the determination of instance values).  In place of the check-export, there is a new inline-export element that can be used to assign exported variable values for the check "on the spot”.  Finally, an attribute, “type” (possible values: “simple” and “complex”) is used to identify the result as being either a simple o!
 r complex value.

>>>
>>> New Type: inlineExportType
>>> Description: This type can be used to define any value that is exported by a check without reference to any valueType defined in the XCCDF document.  Think of it as a static value declaration.  Its purpose is mainly to simplify the process of defining any values that need to be exported to a check used by a selImportType, but I have modified the schema so that it can be used by any checkType in XCCDF.  (This was necessary to make it possible to use a checkType restriction as a child of the selImportType, instead of having to define a highly duplicative variation of that type).
>>>
>>> I am also proposing a modification to some parts of the SCAP specification...
>>>
>>> Currently, the SCAP 1.2 specification only permits the use of “simple” valueTypes in check-exports.  I believe we can decide that a “complex” value merely indicates a single valueType with multiple underlying values, and permit its use.  In OVAL, for example, a variable may hold multiple values at the same time.  We can use the XCCDF complexValueType (and its sub-type, selComplexValueType) to express such a multi-valued variable.
>>>
>>> It’s easy to understand how a complex selImportType, whose check-import has multiple values will work.  But, what if a selImportType is defined as “simple”, but its check-import ends up producing multiple results?
>>>
>>> Well, I propose that we say in such cases, any XCCDF check making use of such a value becomes a permutation — that is, it should behave a lot like a check whose check-content-ref has an href, but no name.  For that case, we have the multi-check attribute that defines how to express the rule results (as a single roll-up, or as a list of permutations).  In the case of a multi-valued simple value in XCCDF, we can use the heretofore unused ruleType@multiple attribute to dictate the behavior.
>>>
>>> The attached ARF XML file illustrates the use of the new types, as well as all the behaviors I’ve described above.
>>>
>>> These new tools will make it possible for someone to write a benchmark that (1) discovers relevant instances of a database on a target machine, and (2) implements one or more compliance rules that is applied to each of those instances, which can be reported distinctly or as a roll-up.
>>>
>>> Thoughts? Comments?
>>>
>>> Best regards,
>>> —David Solin
>>>
>>> <xccdf_1.2.xsd><arf.xml>
>>>
>>>
>>>> On Dec 7, 2015, at 10:19 AM, Tanner, Douglas C CIV SPAWARSYSCEN-ATLANTIC, 58510 <[hidden email]> wrote:
>>>>
>>>> David -
>>>>
>>>>
>>>>
>>>> I believe you meant to send this to the other Doug on the team. I've CC'd him.
>>>>
>>>>
>>>>
>>>> Doug Tanner
>>>>
>>>> ________________________________
>>>> From: David Solin [[hidden email]]
>>>> Sent: Monday, December 07, 2015 10:35 AM
>>>> To: Tanner, Douglas C CIV SPAWARSYSCEN-ATLANTIC, 58510
>>>> Cc: [hidden email]; Waltermire, David A.
>>>> Subject: [Non-DoD Source] Re: [OVAL DEVELOPER] SQLEXT OVAL Extension Proposal
>>>>
>>>> Doug,
>>>>
>>>> I have not forgotten your SQLEXT proposal for the OVAL language, and have been working on some XCCDF/SCAP ground-work that is required before I suggest updates to the XCCDF schema itself, to address your use-case.
>>>>
>>>> First, we need to clarify the operation of the SCAP requirement, SCAP.R.2000.5, as this is the underlying capability that I am planning on utilizing for the solution.  Not all SCAP 1.2-validated tools meet the requirement because it was under-specified, so this is something that should be addressed in SCAP 1.3.
>>>>
>>>> I have attached a sample ARF that illustrates how the same external check, with different variable exports, can be handled for the three SCAP check systems (OVAL, OCIL, and informally, SCE).
>>>>
>>>> The model works well with OVAL and SCE, but there is an issue with OCIL in that variable values are not expressed in the OCIL results format (this makes it impossible to associate arbitrary OCIL results with a set of XCCDF variable exports).  To address that problem, I have added a few new types to the “gOCIL” variables schema (see https://github.com/joval/jOVAL/blob/master/scap/schemas/ocil-2.0/ocil-variables-schema.xsd).  The new types, UserWithVariablesType and SystemWithVariablesType, make use of the OCIL results target substitution group to make it possible to add variable values to OCIL results without requiring any changes to the existing OCIL 2.0 schema.
>>>>
>>>> With this mechanism is place, it will be possible to define a new XCCDF ValueType that obtains its values from an external check.  We can document that, if multiple results are returned for the check system for the value, we treat the resulting values as generating discrete Rule instances.
>>>>
>>>> This concept already exists in XCCDF, via the Rule@multiple attribute.  We could simply disregard the sentence "For example, OVAL checks cannot produce separate results for individual instances of a target.” in table 9’s description of the RuleType@multiple attribute in the XCCDF specification, and then evaluate according to the existing specification.
>>>>
>>>> As a side-note, we could also document in SCAP 1.3 that a complex-value is simply a Value that can have multiple values without implying that there must be multiple corresponding Rule instances.  The OVAL check system permits variables to have multiple values, as we all well know, but OCIL and SCE do not have a concept of multi-valued variables, so it would remain invalid to use complex values in conjunction with those systems.
>>>>
>>>> If we accept this change, then if someone wanted to make use of an OVAL import as a Value without creating multiple instances of a downstream Rule, they could simply import it as a complex type.
>>>>
>>>> Let me know if you have any feedback regarding this approach.  In the meantime I’m going to investigate what would be the minimal set of changes to XCCDF that would be required to support this new value type.
>>>>
>>>> Best regards,
>>>> —David Solin
>>>>
>>>>
>>>> On Oct 5, 2015, at 8:13 AM, David Solin <[hidden email]<mailto:[hidden email]>> wrote:
>>>>
>>>> I had previously replied only to Douglas; I am forwarding that response (below) for any community feedback.
>>>>
>>>> Begin forwarded message:
>>>>
>>>> From: David Solin <[hidden email]<mailto:[hidden email]>>
>>>> Subject: Re: [OVAL DEVELOPER] SQLEXT OVAL Extension Proposal
>>>> Date: October 1, 2015 at 6:03:34 PM CDT
>>>> To: "McIlroy, Douglas M CIV SPAWARSYSCEN-ATLANTIC, 58600" <[hidden email]<mailto:[hidden email]>>
>>>>
>>>> Thanks for your insights, Douglas.  Please see my own thoughts inline, below.
>>>>
>>>>
>>>> On Oct 1, 2015, at 4:04 PM, McIlroy, Douglas M CIV SPAWARSYSCEN-ATLANTIC, 58600 <[hidden email]<mailto:[hidden email]>> wrote:
>>>>
>>>> David,
>>>>
>>>>
>>>>
>>>> Yes, this SQLEXT proposal supports behavior for addressing individual RDBMS instances (the term "instance" as used here refers to any query-able server process spawned by a given DBMS software installation) and named database schemas as top-level targets, and then outputting a dedicated result file for each target. Furthermore, SQLEXT is indeed a platform-agnostic SQL probe that can support DBMS products other than Microsoft SQL Server. The following Oracle, MySQL, and PostgreSQL documentation provides guidance for configuring multiple instances of a given DBMS on a host system:
>>>>
>>>>
>>>>
>>>> https://docs.oracle.com/cd/E11882_01/server.112/e40540/startup.htm#CNCPT89033
>>>>
>>>>
>>>>
>>>> https://dev.mysql.com/doc/refman/5.0/en/multiple-servers.html
>>>>
>>>>
>>>>
>>>> https://opensourcedbms.com/dbms/running-multiple-postgresql-9-2-instances-on-one-server-in-centos-6rhel-6fedora/
>>>>
>>>>
>>>>
>>>> Of course most (if not all) databases support running multiple instances on the same machine.  But apart from MS SQL Server, I don’t believe they are readily discoverable.  To determine which instances are running, for Oracle or MySQL or Postgres, it would be necessary for a tool to discover running processes, read their environments and command-line parameters, and reverse-engineer their configurations, in order to determine how to connect to each.  If the instances are not running at scan-time, then all bets are off.
>>>>
>>>> This makes the implementation of <instance operation=“pattern match”>.*</instance> VERY problematic.
>>>>
>>>>
>>>>
>>>>
>>>> Also, other DBMS's aside from MS SQL Server, such as MySQL, do support hosting multiple named DB schemas per instance. One common counter-example, though, would be Oracle Database, which allocates an instance for each database schema, leading to the concepts of an Oracle DB "instance" and "database" being effectively equivalent. Therefore, the "instance" and "database" context behaviors would be interchangeable when being implemented for an Oracle DB evaluation.
>>>>
>>>>
>>>> Indeed, some do.  But to discover their names, you must first connect to a server instance in a management context.  And connecting to an instance without all the connection information is problematic.
>>>>
>>>> Perhaps you're actually proposing that the SCAP scanning utility should be pre-populated with lists of all the instances on each machine, and how to connect to them.  That would eliminate the discovery problem, but I didn’t get that impression from the proposal.
>>>>
>>>>
>>>> Furthermore, in light of the lack of traction that the SQL57 spec has seen so far, we are not sure how productive attempting to augment it any further would be. Not much so far has come of attempting to incorporate SQL57 into the DISA STIGs due to the inflexibility and insecurity of the "connection_string" entity, so SQLEXT is being proposed as an alternative that addresses those complications.
>>>>
>>>>
>>>> I have to say, since it has always been possible to provide a connection_string value via an external_variable, I’ve personally never really understood the complaints.  Is it that the variable values would appear in the results?  The mask attribute might address that.
>>>>
>>>> In the case of Joval, it’s possible to supply a connection_string with no username/password at all, in which case we use the credential supplied for connecting to the target machine.  In practice this can actually be useful when scanning MS SQL Servers that have been configured to leverage the Windows user account database.  We have had some success running the CIS MS SQL Server content through our product using the existing features.
>>>>
>>>>
>>>>
>>>>
>>>> Also, while extending XCCDF to support multiple top-level evaluation targets per host system is a great idea, we needed to pursue a solution that would be available in the near-term and that would support raw-OVAL evaluations that don't include an XCCDF benchmark. However, given that leveraging XCCDF to control the content processing model of a SCAP stream makes more sense than SQLEXT's raw-OVAL top-up approach, an update to the XCCDF spec would be welcome. Especially when considering other non-RDBM applications such as IIS, Apache, and Tomcat that also support being instantiated multiple times with a dedicated configuration for each instance, there definitely needs to be a discussion about how to make SCAP overall more fit for enterprise-grade applications.
>>>>
>>>>
>>>> I agree.  From a technical standpoint,  a non-standard upgrade to XCCDF should at least be no “worse” than a non-standard addition to OVAL.
>>>>
>>>>
>>>>
>>>>
>>>> ________________________________
>>>> From: David Solin [[hidden email]<mailto:[hidden email]>]
>>>> Sent: Wednesday, September 30, 2015 5:28 PM
>>>> To: McIlroy, Douglas M CIV SPAWARSYSCEN-ATLANTIC, 58600
>>>> Cc: [hidden email]<mailto:[hidden email]>; [hidden email]<mailto:[hidden email]>
>>>> Subject: Re: [OVAL DEVELOPER] SQLEXT OVAL Extension Proposal
>>>>
>>>> Hi Doug (and cross-posting to xccdf-dev),
>>>>
>>>> I’m not really able to easily discern from the samples on Github… but, recalling the sql511 proposal, is the thrust of this proposal that the behaviors result in splitting out per-host, per-instance or per-database (depending on the behavior specified) into different result files?
>>>>
>>>> Notwithstanding the answer to that question, I have a few initial thoughts:
>>>>
>>>> This is not really a generic SQL test at all, but a Microsoft SQL Server test.  Only MSSQL has readily-discoverable instances.  Other RDBMS’s do not really have readily-discoverable instances, and also, they do not all support having multiple ‘databases’ within a single instance.  This was sort of the sole virtue of the connection_string — it identifies the target instance.  (This is also why both generic database-connectivity mechanisms I’ve personally used, ODBC and JDBC, support the concept of connection properties).
>>>>
>>>> This appears to me to really, at heart, be a proposal to delegate instance/database discovery to the OVAL language.  It is certainly already possible using external_variables to target a piece of OVAL content to whatever combination of instances and databases one pleases — provided that those instances and databases are known to the tool that is doing the targeting (by setting the variable values).
>>>>
>>>> If this is indeed the case, and if databases should indeed be treated as first-class targets, then it would make perfect sense to create entire SCAP benchmarks dedicated to evaluating databases, and measure compliance of each instance against that benchmark, rather than (as this proposal embodies) attempt to combine what should be multiple first-class target assessments into a single machine assessment result.
>>>>
>>>> As an alternative to this approach, I would propose making a few changes to XCCDF and SCAP that would make it possible to do exactly what you guys want and leverage the existing sql57 test:
>>>>
>>>> 1.  Create selRefType and selComplexRefType types in XCCDF that make it possible to reference an exported value from a check system
>>>> 2.  Add support for the XCCDF ComplexValueType in SCAP — defining it as a mechanism to evaluate multiple instances of a check evaluated via the multi-check attribute, or if via a complex-check, according to the complex-check’s operator attribute.
>>>>
>>>> Was this an approach you guys have considered?  I’d be happy to collaborate with you to make these changes to XCCDF.  We could call it XCCDF 1.3.
>>>>
>>>> Best regards,
>>>> —David Solin
>>>>
>>>>
>>>>
>>>> David A. Solin
>>>> Co-Founder, Research & Technology
>>>> [hidden email]<mailto:[hidden email]><mailto:[hidden email]>
>>>>
>>>> [Joval Continuous Monitoring] <http://jovalcm.com/>
>>>>
>>>> [Facebook] <https://www.facebook.com/jovalcm> [Linkedin]  <https://www.linkedin.com/company/joval-continuous-monitoring>
>>>>
>>>>
>>>> On Sep 30, 2015, at 11:41 AM, McIlroy, Douglas M CIV SPAWARSYSCEN-ATLANTIC, 58600 <[hidden email]<mailto:[hidden email]><mailto:[hidden email]>> wrote:
>>>>
>>>> Due to the need for automated compliance and vulnerability checks against SQL database management systems and a lack of support for the proposed sql511 test in OVAL 5.11, SPAWAR submits this new proposal for an OVAL extension which addresses the sql511 deficiencies. The current working designation for this proposal is “sqlext” (SQL Test for the OVAL Extension Schema). This is subject to change based upon discussion with the OVAL community regarding standard naming conventions for OVAL extensions. Please see the attached proposal document for further explanation as well as the SQLEXT OVAL Sandbox GitHub fork (https://github.com/mcilroyd/Sandbox/tree/master/resources/x-ind-sqlext) for sample content, results output, and XML schemas. We are looking forward to any feedback and recomendations that the community has to share for SQLEXT.
>>>>
>>>> ...<SQLExt Proposal.pdf>_______________________________________________
>>>> OVAL_Developer mailing list
>>>> [hidden email]<mailto:[hidden email]><mailto:[hidden email]>
>>>> http://lists.cisecurity.org/mailman/listinfo/oval_developer_lists.cisecurity.org
>>>>
>>>> <jovalcm.color.225.png><fb.rounded.png><li.rounded.png>
>>>>
>>>>
>>>>
>>>
>>> David A. Solin
>>> Co-Founder, Research & Technology
>>> [hidden email]
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> XCCDF-dev mailing list
>>> [hidden email]
>>> To unsubscribe, send an email message to [hidden email].
>>
>>
>> _______________________________________________
>> XCCDF-dev mailing list
>> [hidden email]
>> To unsubscribe, send an email message to [hidden email].
>
>
> _______________________________________________
> XCCDF-dev mailing list
> [hidden email]
> To unsubscribe, send an email message to [hidden email].

_______________________________________________
XCCDF-dev mailing list
[hidden email]
To unsubscribe, send an email message to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: [Xccdf-dev] [Non-DoD Source] [OVAL DEVELOPER] SQLEXT OVAL Extension Proposal

mcilroydm
In reply to this post by David Solin-3
David,



Our e-mail server keeps blocking your attachments. Could you try retransmitting your attachments in a zip archive (change the zip name extension or it'll get blocked too)? I'm having trouble wrapping my brain around your proposal without being able to look at your samples.



Thanks,

Douglas M.



________________________________
From: David Solin [[hidden email]]
Sent: Friday, December 11, 2015 10:31 AM
To: McIlroy, Douglas M CIV SPAWARSYSCEN-ATLANTIC, 58600
Cc: [hidden email]; Waltermire, David A.
Subject: Re: [Non-DoD Source] [OVAL DEVELOPER] SQLEXT OVAL Extension Proposal

Hi Doug,

I’ve finally finished fleshing out my proposal for your use-case!

I have attached a modified xccdf_1.2.xsd, which is a modified schema for XCCDF.  It is fully backwards-compatible with XCCDF 1.2, but adds a few new types:

New Type: selImportType
Description: This new type is similar to selStringType and selComplexValueType, in that it can be used to assign a value to a ValueType and can be associated with a selector (by attribute).  However, unlike selStringType and selComplexValueType, a selImportType has the ability to import its value from an external check system.  This is achieved using an embedded CheckType.  The embedded check has some restrictions placed by the schema — it must include a single check-import (which defines the value that will be imported from the check system), and it is not permitted to include any check-exports (to eliminate the issue of Value recursion with the determination of instance values).  In place of the check-export, there is a new inline-export element that can be used to assign exported variable values for the check "on the spot”.  Finally, an attribute, “type” (possible values: “simple” and “complex”) is used to identify the result as being either a simple or complex value.

New Type: inlineExportType
Description: This type can be used to define any value that is exported by a check without reference to any valueType defined in the XCCDF document.  Think of it as a static value declaration.  Its purpose is mainly to simplify the process of defining any values that need to be exported to a check used by a selImportType, but I have modified the schema so that it can be used by any checkType in XCCDF.  (This was necessary to make it possible to use a checkType restriction as a child of the selImportType, instead of having to define a highly duplicative variation of that type).

I am also proposing a modification to some parts of the SCAP specification...

Currently, the SCAP 1.2 specification only permits the use of “simple” valueTypes in check-exports.  I believe we can decide that a “complex” value merely indicates a single valueType with multiple underlying values, and permit its use.  In OVAL, for example, a variable may hold multiple values at the same time.  We can use the XCCDF complexValueType (and its sub-type, selComplexValueType) to express such a multi-valued variable.

It’s easy to understand how a complex selImportType, whose check-import has multiple values will work.  But, what if a selImportType is defined as “simple”, but its check-import ends up producing multiple results?

Well, I propose that we say in such cases, any XCCDF check making use of such a value becomes a permutation — that is, it should behave a lot like a check whose check-content-ref has an href, but no name.  For that case, we have the multi-check attribute that defines how to express the rule results (as a single roll-up, or as a list of permutations).  In the case of a multi-valued simple value in XCCDF, we can use the heretofore unused ruleType@multiple attribute to dictate the behavior.

The attached ARF XML file illustrates the use of the new types, as well as all the behaviors I’ve described above.

These new tools will make it possible for someone to write a benchmark that (1) discovers relevant instances of a database on a target machine, and (2) implements one or more compliance rules that is applied to each of those instances, which can be reported distinctly or as a roll-up.

Thoughts? Comments?

Best regards,
—David Solin




> On Dec 7, 2015, at 10:19 AM, Tanner, Douglas C CIV SPAWARSYSCEN-ATLANTIC, 58510 <[hidden email]> wrote:
>
> David -
>
>
>
> I believe you meant to send this to the other Doug on the team. I've CC'd him.
>
>
>
> Doug Tanner
>
> ________________________________
> From: David Solin [[hidden email]]
> Sent: Monday, December 07, 2015 10:35 AM
> To: Tanner, Douglas C CIV SPAWARSYSCEN-ATLANTIC, 58510
> Cc: [hidden email]; Waltermire, David A.
> Subject: [Non-DoD Source] Re: [OVAL DEVELOPER] SQLEXT OVAL Extension Proposal
>
> Doug,
>
> I have not forgotten your SQLEXT proposal for the OVAL language, and have been working on some XCCDF/SCAP ground-work that is required before I suggest updates to the XCCDF schema itself, to address your use-case.
>
> First, we need to clarify the operation of the SCAP requirement, SCAP.R.2000.5, as this is the underlying capability that I am planning on utilizing for the solution.  Not all SCAP 1.2-validated tools meet the requirement because it was under-specified, so this is something that should be addressed in SCAP 1.3.
>
> I have attached a sample ARF that illustrates how the same external check, with different variable exports, can be handled for the three SCAP check systems (OVAL, OCIL, and informally, SCE).
>
> The model works well with OVAL and SCE, but there is an issue with OCIL in that variable values are not expressed in the OCIL results format (this makes it impossible to associate arbitrary OCIL results with a set of XCCDF variable exports).  To address that problem, I have added a few new types to the “gOCIL” variables schema (see https://github.com/joval/jOVAL/blob/master/scap/schemas/ocil-2.0/ocil-variables-schema.xsd).  The new types, UserWithVariablesType and SystemWithVariablesType, make use of the OCIL results target substitution group to make it possible to add variable values to OCIL results without requiring any changes to the existing OCIL 2.0 schema.
>
> With this mechanism is place, it will be possible to define a new XCCDF ValueType that obtains its values from an external check.  We can document that, if multiple results are returned for the check system for the value, we treat the resulting values as generating discrete Rule instances.
>
> This concept already exists in XCCDF, via the Rule@multiple attribute.  We could simply disregard the sentence "For example, OVAL checks cannot produce separate results for individual instances of a target.” in table 9’s description of the RuleType@multiple attribute in the XCCDF specification, and then evaluate according to the existing specification.
>
> As a side-note, we could also document in SCAP 1.3 that a complex-value is simply a Value that can have multiple values without implying that there must be multiple corresponding Rule instances.  The OVAL check system permits variables to have multiple values, as we all well know, but OCIL and SCE do not have a concept of multi-valued variables, so it would remain invalid to use complex values in conjunction with those systems.
>
> If we accept this change, then if someone wanted to make use of an OVAL import as a Value without creating multiple instances of a downstream Rule, they could simply import it as a complex type.
>
> Let me know if you have any feedback regarding this approach.  In the meantime I’m going to investigate what would be the minimal set of changes to XCCDF that would be required to support this new value type.
>
> Best regards,
> —David Solin
>
>
> On Oct 5, 2015, at 8:13 AM, David Solin <[hidden email]<mailto:[hidden email]>> wrote:
>
> I had previously replied only to Douglas; I am forwarding that response (below) for any community feedback.
>
> Begin forwarded message:
>
> From: David Solin <[hidden email]<mailto:[hidden email]>>
> Subject: Re: [OVAL DEVELOPER] SQLEXT OVAL Extension Proposal
> Date: October 1, 2015 at 6:03:34 PM CDT
> To: "McIlroy, Douglas M CIV SPAWARSYSCEN-ATLANTIC, 58600" <[hidden email]<mailto:[hidden email]>>
>
> Thanks for your insights, Douglas.  Please see my own thoughts inline, below.
>
>
> On Oct 1, 2015, at 4:04 PM, McIlroy, Douglas M CIV SPAWARSYSCEN-ATLANTIC, 58600 <[hidden email]<mailto:[hidden email]>> wrote:
>
> David,
>
>
>
> Yes, this SQLEXT proposal supports behavior for addressing individual RDBMS instances (the term "instance" as used here refers to any query-able server process spawned by a given DBMS software installation) and named database schemas as top-level targets, and then outputting a dedicated result file for each target. Furthermore, SQLEXT is indeed a platform-agnostic SQL probe that can support DBMS products other than Microsoft SQL Server. The following Oracle, MySQL, and PostgreSQL documentation provides guidance for configuring multiple instances of a given DBMS on a host system:
>
>
>
> https://docs.oracle.com/cd/E11882_01/server.112/e40540/startup.htm#CNCPT89033
>
>
>
> https://dev.mysql.com/doc/refman/5.0/en/multiple-servers.html
>
>
>
> https://opensourcedbms.com/dbms/running-multiple-postgresql-9-2-instances-on-one-server-in-centos-6rhel-6fedora/
>
>
>
> Of course most (if not all) databases support running multiple instances on the same machine.  But apart from MS SQL Server, I don’t believe they are readily discoverable.  To determine which instances are running, for Oracle or MySQL or Postgres, it would be necessary for a tool to discover running processes, read their environments and command-line parameters, and reverse-engineer their configurations, in order to determine how to connect to each.  If the instances are not running at scan-time, then all bets are off.
>
> This makes the implementation of <instance operation=“pattern match”>.*</instance> VERY problematic.
>
>
>
>
> Also, other DBMS's aside from MS SQL Server, such as MySQL, do support hosting multiple named DB schemas per instance. One common counter-example, though, would be Oracle Database, which allocates an instance for each database schema, leading to the concepts of an Oracle DB "instance" and "database" being effectively equivalent. Therefore, the "instance" and "database" context behaviors would be interchangeable when being implemented for an Oracle DB evaluation.
>
>
> Indeed, some do.  But to discover their names, you must first connect to a server instance in a management context.  And connecting to an instance without all the connection information is problematic.
>
> Perhaps you're actually proposing that the SCAP scanning utility should be pre-populated with lists of all the instances on each machine, and how to connect to them.  That would eliminate the discovery problem, but I didn’t get that impression from the proposal.
>
>
> Furthermore, in light of the lack of traction that the SQL57 spec has seen so far, we are not sure how productive attempting to augment it any further would be. Not much so far has come of attempting to incorporate SQL57 into the DISA STIGs due to the inflexibility and insecurity of the "connection_string" entity, so SQLEXT is being proposed as an alternative that addresses those complications.
>
>
> I have to say, since it has always been possible to provide a connection_string value via an external_variable, I’ve personally never really understood the complaints.  Is it that the variable values would appear in the results?  The mask attribute might address that.
>
> In the case of Joval, it’s possible to supply a connection_string with no username/password at all, in which case we use the credential supplied for connecting to the target machine.  In practice this can actually be useful when scanning MS SQL Servers that have been configured to leverage the Windows user account database.  We have had some success running the CIS MS SQL Server content through our product using the existing features.
>
>
>
>
> Also, while extending XCCDF to support multiple top-level evaluation targets per host system is a great idea, we needed to pursue a solution that would be available in the near-term and that would support raw-OVAL evaluations that don't include an XCCDF benchmark. However, given that leveraging XCCDF to control the content processing model of a SCAP stream makes more sense than SQLEXT's raw-OVAL top-up approach, an update to the XCCDF spec would be welcome. Especially when considering other non-RDBM applications such as IIS, Apache, and Tomcat that also support being instantiated multiple times with a dedicated configuration for each instance, there definitely needs to be a discussion about how to make SCAP overall more fit for enterprise-grade applications.
>
>
> I agree.  From a technical standpoint,  a non-standard upgrade to XCCDF should at least be no “worse” than a non-standard addition to OVAL.
>
>
>
>
> ________________________________
> From: David Solin [[hidden email]<mailto:[hidden email]>]
> Sent: Wednesday, September 30, 2015 5:28 PM
> To: McIlroy, Douglas M CIV SPAWARSYSCEN-ATLANTIC, 58600
> Cc: [hidden email]<mailto:[hidden email]>; [hidden email]<mailto:[hidden email]>
> Subject: Re: [OVAL DEVELOPER] SQLEXT OVAL Extension Proposal
>
> Hi Doug (and cross-posting to xccdf-dev),
>
> I’m not really able to easily discern from the samples on Github… but, recalling the sql511 proposal, is the thrust of this proposal that the behaviors result in splitting out per-host, per-instance or per-database (depending on the behavior specified) into different result files?
>
> Notwithstanding the answer to that question, I have a few initial thoughts:
>
> This is not really a generic SQL test at all, but a Microsoft SQL Server test.  Only MSSQL has readily-discoverable instances.  Other RDBMS’s do not really have readily-discoverable instances, and also, they do not all support having multiple ‘databases’ within a single instance.  This was sort of the sole virtue of the connection_string — it identifies the target instance.  (This is also why both generic database-connectivity mechanisms I’ve personally used, ODBC and JDBC, support the concept of connection properties).
>
> This appears to me to really, at heart, be a proposal to delegate instance/database discovery to the OVAL language.  It is certainly already possible using external_variables to target a piece of OVAL content to whatever combination of instances and databases one pleases — provided that those instances and databases are known to the tool that is doing the targeting (by setting the variable values).
>
> If this is indeed the case, and if databases should indeed be treated as first-class targets, then it would make perfect sense to create entire SCAP benchmarks dedicated to evaluating databases, and measure compliance of each instance against that benchmark, rather than (as this proposal embodies) attempt to combine what should be multiple first-class target assessments into a single machine assessment result.
>
> As an alternative to this approach, I would propose making a few changes to XCCDF and SCAP that would make it possible to do exactly what you guys want and leverage the existing sql57 test:
>
> 1.  Create selRefType and selComplexRefType types in XCCDF that make it possible to reference an exported value from a check system
> 2.  Add support for the XCCDF ComplexValueType in SCAP — defining it as a mechanism to evaluate multiple instances of a check evaluated via the multi-check attribute, or if via a complex-check, according to the complex-check’s operator attribute.
>
> Was this an approach you guys have considered?  I’d be happy to collaborate with you to make these changes to XCCDF.  We could call it XCCDF 1.3.
>
> Best regards,
> —David Solin
>
>
>
> David A. Solin
> Co-Founder, Research & Technology
> [hidden email]<mailto:[hidden email]><mailto:[hidden email]<mailto:[hidden email]%3E%3Cmailto:[hidden email]>>
>
> [Joval Continuous Monitoring] <http://jovalcm.com/>
>
> [Facebook] <https://www.facebook.com/jovalcm> [Linkedin]  <https://www.linkedin.com/company/joval-continuous-monitoring>
>
>
> On Sep 30, 2015, at 11:41 AM, McIlroy, Douglas M CIV SPAWARSYSCEN-ATLANTIC, 58600 <[hidden email]<mailto:[hidden email]><mailto:[hidden email]>> wrote:
>
> Due to the need for automated compliance and vulnerability checks against SQL database management systems and a lack of support for the proposed sql511 test in OVAL 5.11, SPAWAR submits this new proposal for an OVAL extension which addresses the sql511 deficiencies. The current working designation for this proposal is “sqlext” (SQL Test for the OVAL Extension Schema). This is subject to change based upon discussion with the OVAL community regarding standard naming conventions for OVAL extensions. Please see the attached proposal document for further explanation as well as the SQLEXT OVAL Sandbox GitHub fork (https://github.com/mcilroyd/Sandbox/tree/master/resources/x-ind-sqlext) for sample content, results output, and XML schemas. We are looking forward to any feedback and recomendations that the community has to share for SQLEXT.
>
> ...<SQLExt Proposal.pdf>_______________________________________________
> OVAL_Developer mailing list
> [hidden email]<mailto:[hidden email]><mailto:[hidden email]>
> http://lists.cisecurity.org/mailman/listinfo/oval_developer_lists.cisecurity.org
>
> <jovalcm.color.225.png><fb.rounded.png><li.rounded.png>
>
>
>

David A. Solin
Co-Founder, Research & Technology
[hidden email]






_______________________________________________
XCCDF-dev mailing list
[hidden email]
To unsubscribe, send an email message to [hidden email].