Folks,
I'm not sure this ML is correct place to ask or not, but I'm wondering the status of CCE.
https://nvd.nist.gov/config/cce/index
It seems these CCE quite old, so does somebody know how is the status for new version of CCE?
Kind Regards,
OMO
On 4/27/17 1:01 AM, 面和毅 wrote:
Folks,
I'm not sure this ML is correct place to ask or not, but I'm wondering the status of CCE.
https://nvd.nist.gov/config/cce/index
It seems these CCE quite old, so does somebody know how is the status for new version of CCE?
I had a phone call with our friends at NIST in January about this.
In short, an XSLT needs to be created that transforms our CCE data and creates an XML file formatted like this: https://nvd.nist.gov/static/feeds/xml/cce/cce-COMBINED-5.20130214.xml
<cce cce_id="CCE-XXXX-Y" platform="rhel7" modified="YYYY-MM-DD"> <description> Rule title </description> <parameters> <parameter>enabled / disabled</parameter> </parameters> <technical_mechanisms> <technical_mechanism>via chkconfig</technical_mechanism> </technical_mechanisms> <references> <reference resource_id="NIST 800-53 control">AU-6</reference> <reference resource_id="DISA SRG">RHEL-07-00000</reference> </references> </cce>
That listing can then be submitted to NIST.
Challenges: - The <parameter> tag does not cleanly map to configuration checks. Most things are not just "enabled" or "disabled," they're configured (e.g. password lengths via refine-value elements). - How can we identify (in code) whether a check is enabling or disabling something? Some rules follow a naming scheme, like service_XX_enabled and sysctl checks. Others are more nebulous. - How do we automate <technical_mechanism>? The means to evaluate a check vary per rule, and are not always machine-identifiable.
Generating a CCE list keeps getting delayed because the challenges above. There have been much larger problems users have identified that need fixing first.
That said - if a CCE list is something you feel would be valuable, patches more than welcome!
Dear Shawn,
Many thanks for your feedback.
Now I'm writing some web article regarding with OpenSCAP, then I wish to make clear each SCAP Components current status, relation, and so on.
Kind Regards,
OMO
2017-04-28 7:43 GMT+09:00 Shawn Wells shawn@redhat.com:
On 4/27/17 1:01 AM, 面和毅 wrote:
Folks,
I'm not sure this ML is correct place to ask or not, but I'm wondering the status of CCE.
https://nvd.nist.gov/config/cce/index
It seems these CCE quite old, so does somebody know how is the status for new version of CCE?
I had a phone call with our friends at NIST in January about this.
In short, an XSLT needs to be created that transforms our CCE data and creates an XML file formatted like this: https://nvd.nist.gov/static/feeds/xml/cce/cce-COMBINED-5.20130214.xml
<cce cce_id="CCE-XXXX-Y" platform="rhel7" modified="YYYY-MM-DD"> <description> Rule title </description> <parameters> <parameter>enabled / disabled</parameter> </parameters> <technical_mechanisms> <technical_mechanism>via chkconfig</technical_mechanism> </technical_mechanisms> <references> <reference resource_id="NIST 800-53 control">AU-6</reference> <reference resource_id="DISA SRG">RHEL-07-00000</reference> </references> </cce>
That listing can then be submitted to NIST.
Challenges:
- The <parameter> tag does not cleanly map to configuration checks. Most
things are not just "enabled" or "disabled," they're configured (e.g. password lengths via refine-value elements).
- How can we identify (in code) whether a check is enabling or disabling
something? Some rules follow a naming scheme, like service_XX_enabled and sysctl checks. Others are more nebulous.
- How do we automate <technical_mechanism>? The means to evaluate a check
vary per rule, and are not always machine-identifiable.
Generating a CCE list keeps getting delayed because the challenges above. There have been much larger problems users have identified that need fixing first.
That said - if a CCE list is something you feel would be valuable, patches more than welcome!
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org
On 4/28/17 9:10 AM, 面和毅 wrote:
Dear Shawn,
Many thanks for your feedback.
Now I'm writing some web article regarding with OpenSCAP, then I wish to make clear each SCAP Components current status, relation, and so on.
Certainly can't speak for NIST or other content providers, but SSG actively uses (+maintains) CCEs for included configuration checks.
e.g. for CCE to NIST 800-53 mappings: http://people.redhat.com/swells/scap-security-guide/RHEL/7/output/table-rhel...
CCE to CIS: http://people.redhat.com/swells/scap-security-guide/RHEL/7/output/table-rhel...
and master list: http://people.redhat.com/swells/scap-security-guide/RHEL/7/output/table-rhel...
Those tables are generated as part of the build process. URLs above are not official, just a development dropbox for myself. Official table mappings ship downstream via the scap-security-guide-docs RPM in RHEL
Dear Shawn,
Many thanks. Those URLs are quite valuable for us.
Kind Regards,
OMO
2017-04-28 22:53 GMT+09:00 Shawn Wells shawn@redhat.com:
On 4/28/17 9:10 AM, 面和毅 wrote:
Dear Shawn,
Many thanks for your feedback.
Now I'm writing some web article regarding with OpenSCAP, then I wish to make clear each SCAP Components current status, relation, and so on.
Certainly can't speak for NIST or other content providers, but SSG actively uses (+maintains) CCEs for included configuration checks.
e.g. for CCE to NIST 800-53 mappings: http://people.redhat.com/swells/scap-security-guide/RHEL/7/output/table-rhel...
CCE to CIS: http://people.redhat.com/swells/scap-security-guide/RHEL/7/output/table-rhel...
and master list: http://people.redhat.com/swells/scap-security-guide/RHEL/7/output/table-rhel...
Those tables are generated as part of the build process. URLs above are not official, just a development dropbox for myself. Official table mappings ship downstream via the scap-security-guide-docs RPM in RHEL _______________________________________________ scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org
scap-security-guide@lists.fedorahosted.org
-
Shawn Wells -
面和毅