Dear OpenScap community,
I'm currently working for my company on checking the RHEL 7 SSG profile (0.1.36 version) coverage against STIG 1.3 release.
While browsing the 0.1.36 release, I discovered the stig-overlays.xml which shows the matching between SSG rule and STIG rule.
Can anybody confirm that I can use that file in order to check the coverage rate of the SSG profile ?
Thanks for your answers.
Regards, Olivier Bonhomme
On 15/11/17 13:15, Olivier BONHOMME wrote:
Dear OpenScap community,
I'm currently working for my company on checking the RHEL 7 SSG profile (0.1.36 version) coverage against STIG 1.3 release.
While browsing the 0.1.36 release, I discovered the stig-overlays.xml which shows the matching between SSG rule and STIG rule.
Can anybody confirm that I can use that file in order to check the coverage rate of the SSG profile ?
Hello, Olivier.
I'd say yes, as the stig_overlay maps Rules in STIG to Rules in SSG. Rules that don't map to any Rule in SSG will have ruleid="XXXX".
Last time stig_overlay.xml was updated in upstream was around 8 months ago, so the version there probably isn't STIG 1.3. And unfortunately I couldn't find to witch version it corresponds.
To generate an updated stig_overlays.xml file, please refer to our Developer Guide [1].
[1] https://github.com/OpenSCAP/scap-security-guide/blob/master/docs/manual/deve...
On Wed, Nov 15, 2017 at 05:52:35PM +0100, Watson Yuuma Sato wrote:
On 15/11/17 13:15, Olivier BONHOMME wrote:
Dear OpenScap community,
I'm currently working for my company on checking the RHEL 7 SSG profile (0.1.36 version) coverage against STIG 1.3 release.
While browsing the 0.1.36 release, I discovered the stig-overlays.xml which shows the matching between SSG rule and STIG rule.
Can anybody confirm that I can use that file in order to check the coverage rate of the SSG profile ?
Hello, Olivier.
I'd say yes, as the stig_overlay maps Rules in STIG to Rules in SSG. Rules that don't map to any Rule in SSG will have ruleid="XXXX".
Last time stig_overlay.xml was updated in upstream was around 8 months ago, so the version there probably isn't STIG 1.3. And unfortunately I couldn't find to witch version it corresponds.
To generate an updated stig_overlays.xml file, please refer to our Developer Guide [1].
[1] https://github.com/OpenSCAP/scap-security-guide/blob/master/docs/manual/deve...
Hello Watson,
Thanks for that clear answer. I followed the documentation from the dev guide and the result is that there is only two rules which are not matched against the STIG v1.3. So congrats to the team for such a good job !
I also have a more "senstive" question. It's about the same task but with CentOS profile but when I used the create-stig-overlay.py script, all the rules were tagged XXXX.
After some investigations, I identified that when the derivative distribution generation is enabled, the matching with STIG is removed which is bad for doing a coverage check for the CentOS profile.
I fully understand the reason provided in the commit message when it has been enabled but I would be curious if it would be possible to let the RHEL stigid rules in a very unofficial way adding a CMake option ?
Regards, Olivier Bonhomme
On Thu, Nov 16, 2017 at 8:49 AM, Olivier BONHOMME obonhomme@nerim.net wrote:
On Wed, Nov 15, 2017 at 05:52:35PM +0100, Watson Yuuma Sato wrote:
On 15/11/17 13:15, Olivier BONHOMME wrote:
Dear OpenScap community,
I'm currently working for my company on checking the RHEL 7 SSG
profile (0.1.36 version) coverage against STIG 1.3 release.
While browsing the 0.1.36 release, I discovered the stig-overlays.xml
which shows the matching between SSG rule and STIG rule.
Can anybody confirm that I can use that file in order to check the
coverage rate of the SSG profile ?
Hello, Olivier.
I'd say yes, as the stig_overlay maps Rules in STIG to Rules in SSG. Rules that don't map to any Rule in SSG will have ruleid="XXXX".
Last time stig_overlay.xml was updated in upstream was around 8 months ago, so the version there probably isn't STIG 1.3. And unfortunately I couldn't find to witch version it corresponds.
To generate an updated stig_overlays.xml file, please refer to our Developer Guide [1].
master/docs/manual/developer_guide.adoc#stig-overlay-content
Hello Watson,
Thanks for that clear answer. I followed the documentation from the dev guide and the result is that there is only two rules which are not matched against the STIG v1.3. So congrats to the team for such a good job !
I also have a more "senstive" question. It's about the same task but with CentOS profile but when I used the create-stig-overlay.py script, all the rules were tagged XXXX.
After some investigations, I identified that when the derivative distribution generation is enabled, the matching with STIG is removed which is bad for doing a coverage check for the CentOS profile.
I fully understand the reason provided in the commit message when it has been enabled but I would be curious if it would be possible to let the RHEL stigid rules in a very unofficial way adding a CMake option ?
This is expected behaviour. A separate CentOS STIG has to be created and exist for a stig_overlay.xml to be created and exist.CentOS *does not* meet STIG compliance equirements nor do Red Hat certificationstransfer or follow down to the derivatives. The CentOS project also echos this statement at https://wiki.centos.org/FAQ/General#head-4b2dd1ea6dcc1243d6e3886dc3e5d1ebb25... For this reason, all RHEL identifiers have been stripped out of the derivative profiles.
You should not have to check coverage of the CentOS profile as the CentOS profile is almost an exact copy of the RHEL profile just with some changes to work on CentOS.
Also, some RHEL checks/rules in the STIG are duplicates of others, or they are no longer valid for the latest release. Any of duplicated/outdated checks/rules have been remove/updated (as much as feasibly possible) for the latest release. So if there are missing RHEL identifiers, it is usually because of duplication or new content that has yet to be added.
On Thu, Nov 16, 2017 at 09:59:02AM -0700, Gabe Alford wrote: Hello Gabe,
This is expected behaviour. A separate CentOS STIG has to be created and exist for a stig_overlay.xml to be created and exist.CentOS *does not* meet STIG compliance equirements nor do Red Hat certificationstransfer or follow down to the derivatives. The CentOS project also echos this statement at https://wiki.centos.org/FAQ/General#head-4b2dd1ea6dcc1243d6e3886dc3e5d1ebb25... For this reason, all RHEL identifiers have been stripped out of the derivative profiles.
You should not have to check coverage of the CentOS profile as the CentOS profile is almost an exact copy of the RHEL profile just with some changes to work on CentOS.
I understand your point and the fact that CentOS profile is a copy of the RHEL profile but with a different CPE. But actually, for now I'm not looking for a certification and I'm fully aware that CentOS goal is not to provide certified things.
In my mind actually, it sounds more like applying the RHEL profile on a CentOS just for having a status against STIG but not a certification at all. It's just in order to have a general idea of how my CentOS is secured (or not) against a known guide.
I know for example that FIPS rule will always fail and I'm okay with that but for most of others rules, I expect the same behaviour between an RHEL and a CentOS. For example, rules about paritionning are applicable in the same way on CentOS or RHEL.
That's why my action plan was, how is the CentOS guide against STIG in order to see if I have rules to write by myself in order to have a relevant OpenSCAP profile (and of course contribute to the SSG project :)).
Correct me if i'm wrong but i don't think it's in the project roadmap to have a dedicated SSG profile for CentOS which is standalone and not a derivative from the RHEL one.
Also, some RHEL checks/rules in the STIG are duplicates of others, or they are no longer valid for the latest release. Any of duplicated/outdated checks/rules have been remove/updated (as much as feasibly possible) for the latest release. So if there are missing RHEL identifiers, it is usually because of duplication or new content that has yet to be added.
Does that mean that actually, the SSG team considers there is a full coverage against RHEL STIG V1.2 ?
Regards, Olivier Bonhomme
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 Thu, Nov 16, 2017 at 10:21 AM, Olivier BONHOMME obonhomme@nerim.net wrote:
On Thu, Nov 16, 2017 at 09:59:02AM -0700, Gabe Alford wrote: Hello Gabe,
This is expected behaviour. A separate CentOS STIG has to be created and exist for a stig_overlay.xml to be created and exist.CentOS *does not* meet STIG compliance equirements nor do Red Hat certificationstransfer or follow down to the derivatives. The CentOS project also echos this statement at https://wiki.centos.org/FAQ/General#head-4b2dd1ea6dcc1243d6e
3886dc3e5d1ebb252c194
For this reason, all RHEL identifiers have been stripped out of the derivative profiles.
You should not have to check coverage of the CentOS profile as the CentOS profile is almost an exact copy of the RHEL profile just with some changes to
work
on CentOS.
I understand your point and the fact that CentOS profile is a copy of the RHEL profile but with a different CPE. But actually, for now I'm not looking for a certification and I'm fully aware that CentOS goal is not to provide certified things.
In my mind actually, it sounds more like applying the RHEL profile on a CentOS just for having a status against STIG but not a certification at all. It's just in order to have a general idea of how my CentOS is secured (or not) against a known guide.
You shouldn't have to apply the RHEL content to a CentOS machine at all. The profiles in ssg-centos7-xccdf.xml are the exact same as what is in ssg-rhel7-xccdf.xml. So, a new rule gets added to the STIG profile in ssg-rhel7-xccdf.xml then that same rule will get added to ssg-centos7-xccdf.xml when the content is built.
I know for example that FIPS rule will always fail and I'm okay with that but for most of others rules, I expect the same behaviour between an RHEL and a CentOS. For example, rules about paritionning are applicable in the same way on CentOS or RHEL.
That's why my action plan was, how is the CentOS guide against STIG in order to see if I have rules to write by myself in order to have a relevant OpenSCAP profile (and of course contribute to the SSG project :)).
Correct me if i'm wrong but i don't think it's in the project roadmap to have a dedicated SSG profile for CentOS which is standalone and not a derivative from the RHEL one.
That is correct. Same thing with ScientificLinux.
Also, some RHEL checks/rules in the STIG are duplicates of others, or
they
are no longer valid for the latest release. Any of duplicated/outdated checks/rules have been remove/updated (as much as feasibly possible) for the latest release. So if there are missing
RHEL
identifiers, it is usually because of duplication or new content that has yet to be added.
Does that mean that actually, the SSG team considers there is a full coverage against RHEL STIG V1.2 ?
Regards, Olivier Bonhomme
scap-security-guide mailing list -- scap-security-guide@lists.fedo
rahosted.org
To unsubscribe send an email to scap-security-guide-leave@list
s.fedorahosted.org _______________________________________________ scap-security-guide mailing list -- scap-security-guide@lists.fedo rahosted.org To unsubscribe send an email to scap-security-guide-leave@list s.fedorahosted.org
scap-security-guide@lists.fedorahosted.org
-
Gabe Alford -
Olivier BONHOMME -
Watson Yuuma Sato