I am here with Shawn Wells today and we would like your help in developing the requirements for a possible inclusion of SELinux requirements to be included in the RHEL7 STIG. As we move away from legacy file permissions to type enforcement, we would like to work with the community to understand security relevant configuration options such as SELinux Booleans used in operational environments. To calm any fears associated with SELinux, we are only considering targeted policy and not the MLS enablement. Shawn will be working to gather your input. Any of your input would be appreciated if we could get it by Tuesday March 22, 2016 at the end of business.
On 03/16/2016 07:26 PM, Mackanick, Jason W CIV DISA RE (US) wrote:
I am here with Shawn Wells today and we would like your help in developing the requirements for a possible inclusion of SELinux requirements to be included in the RHEL7 STIG. As we move away from legacy file permissions to type enforcement, we would like to work with the community to understand security relevant configuration options such as SELinux Booleans used in operational environments. To calm any fears associated with SELinux, we are only considering targeted policy and not the MLS enablement. Shawn will be working to gather your input. Any of your input would be appreciated if we could get it by Tuesday March 22, 2016 at the end of business.
Hello Jason,
After talking with selinux crew here in Red Hat, I have learned that defaults for selinux booleans are set rather defensively. The default is always the more secure unless too generic use-case would be restricted.
There is over 300 houndred selinux booleans in Red Hat Enterprise Linux 7. I wonder where we can start. Or do you have some specific booleans in mind?
Perhaps it makes sense to go through these 300 hundreds and put them into some kind of buckets? Something like
booleans that should absolutely always be true booleans that should always be false
booleans that default to true, but operators may often need to turn them false ...
booleans that default to true, but stig advices to keep them false ...
Thoughts? ~š.
On 3/21/16 10:44 AM, Šimon Lukašík wrote:
On 03/16/2016 07:26 PM, Mackanick, Jason W CIV DISA RE (US) wrote:
I am here with Shawn Wells today and we would like your help in developing the requirements for a possible inclusion of SELinux requirements to be included in the RHEL7 STIG. As we move away from legacy file permissions to type enforcement, we would like to work with the community to understand security relevant configuration options such as SELinux Booleans used in operational environments. To calm any fears associated with SELinux, we are only considering targeted policy and not the MLS enablement. Shawn will be working to gather your input. Any of your input would be appreciated if we could get it by Tuesday March 22, 2016 at the end of business.
Hello Jason,
After talking with selinux crew here in Red Hat, I have learned that defaults for selinux booleans are set rather defensively. The default is always the more secure unless too generic use-case would be restricted.
There is over 300 houndred selinux booleans in Red Hat Enterprise Linux 7. I wonder where we can start. Or do you have some specific booleans in mind?
Perhaps it makes sense to go through these 300 hundreds and put them into some kind of buckets? Something like
booleans that should absolutely always be true booleans that should always be false
booleans that default to true, but operators may often need to turn them false ...
booleans that default to true, but stig advices to keep them false ...
Thoughts?
To ensure everyone is on the same page of booleans, here's a list of the ~300 RHEL7 booleans (output of 'semanage boolean -l'): http://people.redhat.com/swells/boolean_list.txt
One of the things discussed with DISA was proper scoping of what a RHEL7 STIG looks like. In the past, the RHEL STIGs have been a catch-all and included configuration settings for things like OpenLDAP Server, HTTPD, and other 3rd party software (defined as non Operation System functionality).
An example is the "all software library files must be {owned grouped chmod'd}" rules. In such a case, the RHEL STIG *should* cover RHEL-provided library files under /usr/lib/{kernel systemd} directories, but not /usr/lib/3rd_party_app.
Part of this descoping is the reflection that DISA's Application SRG [0][1] has been maturing. 3rd party software deployments, such as java middleware servers, should be covered by the Application SRG requirements. Not lumped into the Operating System STIG.
RHEL7 may ship SELinux booleans for 3rd party software (e.g. httpd_can_connect_mythtv, or ftpd_connect_db) however their existence doesn't correlate to inclusion in the *operating system* STIG. The above booleans would appropriately placed in the Apache STIG or FTP Server STIG, while the RHEL STIG should ensure SELinux is enforcing and should have system-level booleans set (e.g. selinuxuser_execmod, use_ecryptfs_home_dirs, staff_exec_content).
Your buckets idea is really great. Through the above lens, perhaps we can modify the groupings to something like below:
- Operating System booleans that should be true - Operating System booleans that should be false - Non-OS booleans to include in 3rd party STIGs (helping DISA identify these will expedite their inclusion in things like Apache and JBoss STIGs).
When writing XCCDF rules, their description tag will included cases where modification of setting may be called for. The OVAL side can use selinuxboolean_test to automate everything. Thankfully remediation is a bash 1-liner.
[0] http://iasecontent.disa.mil/stigs/zip/Oct2015/U_Application_Server_V2R2_SRG.... [1] http://iase.disa.mil/stigs/Documents/u_application_server_srg_v2_release_mem...
On Mar 21, 2016, at 12:12 PM, Shawn Wells shawn@redhat.com wrote:
On 3/21/16 10:44 AM, Šimon Lukašík wrote:
On 03/16/2016 07:26 PM, Mackanick, Jason W CIV DISA RE (US) wrote:
I am here with Shawn Wells today and we would like your help in developing the requirements for a possible inclusion of SELinux requirements to be included in the RHEL7 STIG. As we move away from legacy file permissions to type enforcement, we would like to work with the community to understand security relevant configuration options such as SELinux Booleans used in operational environments. To calm any fears associated with SELinux, we are only considering targeted policy and not the MLS enablement. Shawn will be working to gather your input. Any of your input would be appreciated if we could get it by Tuesday March 22, 2016 at the end of business.
Hello Jason,
After talking with selinux crew here in Red Hat, I have learned that defaults for selinux booleans are set rather defensively. The default is always the more secure unless too generic use-case would be restricted.
There is over 300 houndred selinux booleans in Red Hat Enterprise Linux 7. I wonder where we can start. Or do you have some specific booleans in mind?
Perhaps it makes sense to go through these 300 hundreds and put them into some kind of buckets? Something like
booleans that should absolutely always be true booleans that should always be false
booleans that default to true, but operators may often need to turn them false ...
booleans that default to true, but stig advices to keep them false ...
Thoughts?
To ensure everyone is on the same page of booleans, here's a list of the ~300 RHEL7 booleans (output of 'semanage boolean -l'): http://people.redhat.com/swells/boolean_list.txt
One of the things discussed with DISA was proper scoping of what a RHEL7 STIG looks like. In the past, the RHEL STIGs have been a catch-all and included configuration settings for things like OpenLDAP Server, HTTPD, and other 3rd party software (defined as non Operation System functionality).
An example is the "all software library files must be {owned grouped chmod'd}" rules. In such a case, the RHEL STIG *should* cover RHEL-provided library files under /usr/lib/{kernel systemd} directories, but not /usr/lib/3rd_party_app.
Part of this descoping is the reflection that DISA's Application SRG [0][1] has been maturing. 3rd party software deployments, such as java middleware servers, should be covered by the Application SRG requirements. Not lumped into the Operating System STIG.
RHEL7 may ship SELinux booleans for 3rd party software (e.g. httpd_can_connect_mythtv, or ftpd_connect_db) however their existence doesn't correlate to inclusion in the *operating system* STIG. The above booleans would appropriately placed in the Apache STIG or FTP Server STIG, while the RHEL STIG should ensure SELinux is enforcing and should have system-level booleans set (e.g. selinuxuser_execmod, use_ecryptfs_home_dirs, staff_exec_content).
Your buckets idea is really great. Through the above lens, perhaps we can modify the groupings to something like below:
- Operating System booleans that should be true
- Operating System booleans that should be false
- Non-OS booleans to include in 3rd party STIGs (helping DISA identify these will expedite their inclusion in things like Apache and JBoss STIGs).
When writing XCCDF rules, their description tag will included cases where modification of setting may be called for. The OVAL side can use selinuxboolean_test to automate everything. Thankfully remediation is a bash 1-liner.
[0] http://iasecontent.disa.mil/stigs/zip/Oct2015/U_Application_Server_V2R2_SRG.... [1] http://iase.disa.mil/stigs/Documents/u_application_server_srg_v2_release_mem...
We have customers that must meet the STIG requirements but also need to have custom policy written. Who is the intended audience that must meet this requirement? I would assume it’s all federal systems running RHEL 7. I have some concerns about failing STIG checks and getting push back because of it. I know that for the majority of the government these STIG checks will actually be a good thing and will help them ensure that the SELinux policy is the most “secure" state possible given their environment. However, I want to understand how this change might impact those of us that do more customization of the policy or completely replace it with one of our own. I’d imagine that it would just be a documentation exercise to state that the solution has custom policy but hopefully the audience on this list can validate that assumption.
-- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/scap-security-guide@lists.fedorah... https://github.com/OpenSCAP/scap-security-guide/
I'm 100% on board with requiring SELinux to be enabled in targeted mode moving forward.
The SIMP (https://github.com/NationalSecurityAgency/SIMP) stack runs with both SELinux targetd mode enabled and FIPS mode enabled in all of our tests and in our default installation. We identify where there are issues and we write custom policies as necessary to make our applications function properly.
I don't know that I would restrict network connections by default (we don't....yet) but it's certainly something to strive toward. As is all outbound connections blocked by IPTables by default. (If my phone can do it, it shouldn't be a giant hurdle)
The SELinux ecosystem has improved to the point where it is usable and maintainable by most administrators. That said, there does need to be the understanding that the process for moving forward if SELinux does not work should be:
1) Set SELinux to permissive on that system (never disable it or your contexts will be a mess when you try to enable it later) 2) Create an action plan to create the proper policy for your application 3) Create the application policy 4) Implement the application policy 5) Re-enable SELinux in targeted mode
Any broken policy, shipped by a vendor, should be seen as a high priority incident for that vendor and a patch should be shipped publicly as quickly as feasible.
The SELinux community seems to have also gotten to the point where there is some realization that some policy is better than no policy. So that's a big win overall. You may end up with a weaker policy surrounding your application than you would like but that's 100% better than disabling SELinux across the system for one application.
Thanks,
Trevor
On Mon, Mar 21, 2016 at 12:12 PM, Shawn Wells shawn@redhat.com wrote:
On 3/21/16 10:44 AM, Šimon Lukašík wrote:
On 03/16/2016 07:26 PM, Mackanick, Jason W CIV DISA RE (US) wrote:
I am here with Shawn Wells today and we would like your help in developing the requirements for a possible inclusion of SELinux requirements to be included in the RHEL7 STIG. As we move away from legacy file permissions to type enforcement, we would like to work with the community to understand security relevant configuration options such as SELinux Booleans used in operational environments. To calm any fears associated with SELinux, we are only considering targeted policy and not the MLS enablement. Shawn will be working to gather your input. Any of your input would be appreciated if we could get it by Tuesday March 22, 2016 at the end of business.
Hello Jason,
After talking with selinux crew here in Red Hat, I have learned that defaults for selinux booleans are set rather defensively. The default is always the more secure unless too generic use-case would be restricted.
There is over 300 houndred selinux booleans in Red Hat Enterprise Linux 7. I wonder where we can start. Or do you have some specific booleans in mind?
Perhaps it makes sense to go through these 300 hundreds and put them into some kind of buckets? Something like
booleans that should absolutely always be true booleans that should always be false
booleans that default to true, but operators may often need to turn them false ...
booleans that default to true, but stig advices to keep them false ...
Thoughts?
To ensure everyone is on the same page of booleans, here's a list of the ~300 RHEL7 booleans (output of 'semanage boolean -l'): http://people.redhat.com/swells/boolean_list.txt
One of the things discussed with DISA was proper scoping of what a RHEL7 STIG looks like. In the past, the RHEL STIGs have been a catch-all and included configuration settings for things like OpenLDAP Server, HTTPD, and other 3rd party software (defined as non Operation System functionality).
An example is the "all software library files must be {owned grouped chmod'd}" rules. In such a case, the RHEL STIG *should* cover RHEL-provided library files under /usr/lib/{kernel systemd} directories, but not /usr/lib/3rd_party_app.
Part of this descoping is the reflection that DISA's Application SRG [0][1] has been maturing. 3rd party software deployments, such as java middleware servers, should be covered by the Application SRG requirements. Not lumped into the Operating System STIG.
RHEL7 may ship SELinux booleans for 3rd party software (e.g. httpd_can_connect_mythtv, or ftpd_connect_db) however their existence doesn't correlate to inclusion in the *operating system* STIG. The above booleans would appropriately placed in the Apache STIG or FTP Server STIG, while the RHEL STIG should ensure SELinux is enforcing and should have system-level booleans set (e.g. selinuxuser_execmod, use_ecryptfs_home_dirs, staff_exec_content).
Your buckets idea is really great. Through the above lens, perhaps we can modify the groupings to something like below:
- Operating System booleans that should be true
- Operating System booleans that should be false
- Non-OS booleans to include in 3rd party STIGs (helping DISA identify
these will expedite their inclusion in things like Apache and JBoss STIGs).
When writing XCCDF rules, their description tag will included cases where modification of setting may be called for. The OVAL side can use selinuxboolean_test to automate everything. Thankfully remediation is a bash 1-liner.
[0] http://iasecontent.disa.mil/stigs/zip/Oct2015/U_Application_Server_V2R2_SRG.... [1] http://iase.disa.mil/stigs/Documents/u_application_server_srg_v2_release_mem...
-- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/scap-security-guide@lists.fedorah... https://github.com/OpenSCAP/scap-security-guide/
On Friday, April 08, 2016 09:42:52 AM Trevor Vaughan wrote:
I'm 100% on board with requiring SELinux to be enabled in targeted mode moving forward.
The SIMP (https://github.com/NationalSecurityAgency/SIMP) stack runs with both SELinux targetd mode enabled and FIPS mode enabled in all of our tests and in our default installation. We identify where there are issues and we write custom policies as necessary to make our applications function properly.
I don't know that I would restrict network connections by default (we don't....yet) but it's certainly something to strive toward. As is all outbound connections blocked by IPTables by default. (If my phone can do it, it shouldn't be a giant hurdle)
The SELinux ecosystem has improved to the point where it is usable and maintainable by most administrators. That said, there does need to be the understanding that the process for moving forward if SELinux does not work should be:
- Set SELinux to permissive on that system (never disable it or your
contexts will be a mess when you try to enable it later)
Shouldn't the recipe be to put the application that is not working into a permissive domain?
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/htm...
RHEL7 also supports permissive domains.
Then if you still have problems, put the whole machine into permissive mode.
-Steve
- Create an action plan to create the proper policy for your application
- Create the application policy
- Implement the application policy
- Re-enable SELinux in targeted mode
Any broken policy, shipped by a vendor, should be seen as a high priority incident for that vendor and a patch should be shipped publicly as quickly as feasible.
The SELinux community seems to have also gotten to the point where there is some realization that some policy is better than no policy. So that's a big win overall. You may end up with a weaker policy surrounding your application than you would like but that's 100% better than disabling SELinux across the system for one application.
Thanks,
Trevor
On Mon, Mar 21, 2016 at 12:12 PM, Shawn Wells shawn@redhat.com wrote:
On 3/21/16 10:44 AM, Šimon Lukašík wrote:
On 03/16/2016 07:26 PM, Mackanick, Jason W CIV DISA RE (US) wrote:
I am here with Shawn Wells today and we would like your help in developing the requirements for a possible inclusion of SELinux requirements to be included in the RHEL7 STIG. As we move away from legacy file permissions to type enforcement, we would like to work with the community to understand security relevant configuration options such as SELinux Booleans used in operational environments. To calm any fears associated with SELinux, we are only considering targeted policy and not the MLS enablement. Shawn will be working to gather your input. Any of your input would be appreciated if we could get it by Tuesday March 22, 2016 at the end of business.
Hello Jason,
After talking with selinux crew here in Red Hat, I have learned that defaults for selinux booleans are set rather defensively. The default is always the more secure unless too generic use-case would be restricted.
There is over 300 houndred selinux booleans in Red Hat Enterprise Linux 7. I wonder where we can start. Or do you have some specific booleans in mind?
Perhaps it makes sense to go through these 300 hundreds and put them into some kind of buckets? Something like
booleans that should absolutely always be true booleans that should always be false
booleans that default to true, but operators may often need to turn
them false
...
booleans that default to true, but stig advices to keep them false ...
Thoughts?
To ensure everyone is on the same page of booleans, here's a list of the ~300 RHEL7 booleans (output of 'semanage boolean -l'): http://people.redhat.com/swells/boolean_list.txt
One of the things discussed with DISA was proper scoping of what a RHEL7 STIG looks like. In the past, the RHEL STIGs have been a catch-all and included configuration settings for things like OpenLDAP Server, HTTPD, and other 3rd party software (defined as non Operation System functionality).
An example is the "all software library files must be {owned grouped chmod'd}" rules. In such a case, the RHEL STIG *should* cover RHEL-provided library files under /usr/lib/{kernel systemd} directories, but not /usr/lib/3rd_party_app.
Part of this descoping is the reflection that DISA's Application SRG [0][1] has been maturing. 3rd party software deployments, such as java middleware servers, should be covered by the Application SRG requirements. Not lumped into the Operating System STIG.
RHEL7 may ship SELinux booleans for 3rd party software (e.g. httpd_can_connect_mythtv, or ftpd_connect_db) however their existence doesn't correlate to inclusion in the *operating system* STIG. The above booleans would appropriately placed in the Apache STIG or FTP Server STIG, while the RHEL STIG should ensure SELinux is enforcing and should have system-level booleans set (e.g. selinuxuser_execmod, use_ecryptfs_home_dirs, staff_exec_content).
Your buckets idea is really great. Through the above lens, perhaps we can modify the groupings to something like below:
- Operating System booleans that should be true
- Operating System booleans that should be false
- Non-OS booleans to include in 3rd party STIGs (helping DISA identify
these will expedite their inclusion in things like Apache and JBoss STIGs).
When writing XCCDF rules, their description tag will included cases where modification of setting may be called for. The OVAL side can use selinuxboolean_test to automate everything. Thankfully remediation is a bash 1-liner.
[0] http://iasecontent.disa.mil/stigs/zip/Oct2015/U_Application_Server_V2R2_SR G.zip [1] http://iase.disa.mil/stigs/Documents/u_application_server_srg_v2_release_m emo.pdf
-- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/scap-security-guide@lists.fedor ahosted.org https://github.com/OpenSCAP/scap-security-guide/
Hello Daniel,
thank you for contacting us.
----- Original Message -----
From: "Dan Warburton" dan.warburton@jvncomm.com To: "SCAP Security Guide" scap-security-guide@lists.fedorahosted.org Sent: Tuesday, March 22, 2016 8:36:27 PM Subject: cnssi No 1253 profile needed
http://static.open-scap.org/ssg-guides/ssg-rhel6-guide-nist-cl-il-al.html
I cannot locate this guide. I have redhat scap-security-guide 0.10.21-3.el6 which yum says is the latest.
This (CNSSI No. 1253) profile has been introduced starting from upstream scap-security-guide-0.1.27 release: [1] https://github.com/OpenSCAP/scap-security-guide/releases/tag/v0.1.27
thus as such is not included in scap-security-guide-0.1.21-3.el6 version yet you mention above.
I think the profile for National Security Systems Instruction (CNSSI) No. 1253, "Security Categorization and Control Selection for National Security Systems""
How can I get this? rpm preferred
AFAIK Red Hat Enterprise Linux 6.8 Beta includes scap-security-guide RPM based on upstream 0.1.28 version already:
http://www.redhat.com/en/about/blog/red-hat-enterprise-linux-68-beta-now-ava...
therefore you can obtain the updated scap-security-guide RPM from that release for now, till the moment Red Hat Enterprise Linux 6 Update 8 is generally available.
Hope this helps.
Let us know if we can be of any further guidance.
Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team
Thanks.
-- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/scap-security-guide@lists.fedorah... https://github.com/OpenSCAP/scap-security-guide/
On 3/23/16 6:25 AM, Jan Lieskovsky wrote:
Hello Daniel,
thank you for contacting us.
----- Original Message -----
From: "Dan Warburton"dan.warburton@jvncomm.com To: "SCAP Security Guide"scap-security-guide@lists.fedorahosted.org Sent: Tuesday, March 22, 2016 8:36:27 PM Subject: cnssi No 1253 profile needed
http://static.open-scap.org/ssg-guides/ssg-rhel6-guide-nist-cl-il-al.html
I cannot locate this guide. I have redhat scap-security-guide 0.10.21-3.el6 which yum says is the latest.
This (CNSSI No. 1253) profile has been introduced starting from upstream scap-security-guide-0.1.27 release: [1]https://github.com/OpenSCAP/scap-security-guide/releases/tag/v0.1.27
thus as such is not included in scap-security-guide-0.1.21-3.el6 version yet you mention above.
I think the profile for National Security Systems Instruction (CNSSI) No. 1253, "Security Categorization and Control Selection for National Security Systems""
How can I get this? rpm preferred
AFAIK Red Hat Enterprise Linux 6.8 Beta includes scap-security-guide RPM based on upstream 0.1.28 version already:
http://www.redhat.com/en/about/blog/red-hat-enterprise-linux-68-beta-now-ava...
therefore you can obtain the updated scap-security-guide RPM from that release for now, till the moment Red Hat Enterprise Linux 6 Update 8 is generally available.
Hope this helps.
Let us know if we can be of any further guidance.
Direct link to the beta RPM: https://access.redhat.com/downloads/content/rhel---6/x86_64/160/scap-securit...
In regards to a CNSSI profile, we're trying to sort out what that'd actually mean. NSA's CNSSI 12-53 is different than NRO, which is different than DISA... who's CNSSI 12-53 overlay to we follow? What would be most useful/applicable?
This actually highlights, what we're coming to realize as a serious issue with the current SSG content.
I should be able to *easily* start from a base, replace the parts that I need to, trace back to the original information, and set my own parameters.
Setting my own parameters is reasonably easy, but the rest isn't.
My answer to your question:
1) There should be a base CNSS 1253 policy that is the common XCCDF ground 2) Each branch should have their own derived CNSS 1253 policies that override the requisite XCCDF and OVAL content as necessary 3) Nothing should be repeated that is not overridden 4) Overrides should be understood in the derived content 5) This should be easy...it's not (actually, it appears to be impossible without tying yourself in knots)
Since we implement controls in a cross-system manner, per application, SIMP has needed to derive the various controls and change OVAL content to match the way we do things. This should be *easy*. It is absolutely not easy and I don't think we'll see larger ground level adoption until it is.
Thanks,
Trevor
On Thu, Mar 24, 2016 at 12:48 PM, Shawn Wells shawn@redhat.com wrote:
On 3/23/16 6:25 AM, Jan Lieskovsky wrote:
Hello Daniel,
thank you for contacting us.
----- Original Message -----
From: "Dan Warburton"dan.warburton@jvncomm.com To: "SCAP Security Guide"scap-security-guide@lists.fedorahosted.org Sent: Tuesday, March 22, 2016 8:36:27 PM Subject: cnssi No 1253 profile needed
http://static.open-scap.org/ssg-guides/ssg-rhel6-guide-nist-cl-il-al.html
I cannot locate this guide. I have redhat scap-security-guide
0.10.21-3.el6
which yum says is the latest.
This (CNSSI No. 1253) profile has been introduced starting from upstream scap-security-guide-0.1.27 release: [1] https://github.com/OpenSCAP/scap-security-guide/releases/tag/v0.1.27
thus as such is not included in scap-security-guide-0.1.21-3.el6 version yet you mention above.
I think the profile for National Security Systems Instruction (CNSSI)
No.
1253, "Security Categorization and Control Selection for National
Security
Systems""
How can I get this? rpm preferred
AFAIK Red Hat Enterprise Linux 6.8 Beta includes scap-security-guide RPM based on upstream 0.1.28 version already:
http://www.redhat.com/en/about/blog/red-hat-enterprise-linux-68-beta-now-ava...
therefore you can obtain the updated scap-security-guide RPM from that release for now, till the moment Red Hat Enterprise Linux 6 Update 8 is generally available.
Hope this helps.
Let us know if we can be of any further guidance.
Direct link to the beta RPM:
https://access.redhat.com/downloads/content/rhel---6/x86_64/160/scap-securit...
In regards to a CNSSI profile, we're trying to sort out what that'd actually mean. NSA's CNSSI 12-53 is different than NRO, which is different than DISA... who's CNSSI 12-53 overlay to we follow? What would be most useful/applicable?
-- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/scap-security-guide@lists.fedorah... https://github.com/OpenSCAP/scap-security-guide/
-----Original Message----- From: Trevor Vaughan [mailto:tvaughan@onyxpoint.com] Sent: Friday, April 08, 2016 9:51 AM
I should be able to *easily* start from a base, replace the parts that I need to, trace back to the original information, and set my own parameters.
- There should be a base CNSS 1253 policy that is the common XCCDF
ground
- Each branch should have their own derived CNSS 1253 policies that
override the requisite XCCDF and OVAL content as necessary
Nothing should be repeated that is not overridden
Overrides should be understood in the derived content
This should be easy...it's not (actually, it appears to be impossible without
tying yourself in knots)
This is my understanding of what tailoring files are intended to do, do they fall short in your use case?
Matt Micene DLT Solutions Solution Architect RHCA# 100-002-435 Direct 703-773-1195
On Thu, Mar 24, 2016 at 12:48 PM, Shawn Wells <shawn@redhat.com mailto:shawn@redhat.com > wrote:
On 3/23/16 6:25 AM, Jan Lieskovsky wrote:
Hello Daniel, thank you for contacting us. ----- Original Message ----- >From: "DanWarburton"<dan.warburton@jvncomm.com mailto:dan.warburton@jvncomm.com > >To: "SCAP Security Guide"<scap-security- guide@lists.fedorahosted.org mailto:scap-security- guide@lists.fedorahosted.org > >Sent: Tuesday, March 22, 2016 8:36:27 PM >Subject: cnssi No 1253 profile needed > > > > > > >http://static.open-scap.org/ssg-guides/ssg-rhel6- guide-nist-cl-il-al.html > >I cannot locate this guide. I have redhat scap- security-guide 0.10.21-3.el6 >which yum says is the latest.
This (CNSSI No. 1253) profile has been introduced startingfrom upstream scap-security-guide-0.1.27 release: [1]https://github.com/OpenSCAP/scap-security- guide/releases/tag/v0.1.27
thus as such is not included in scap-security-guide-0.1.21-3.el6 version yet you mention above.
> > >I think the profile for National Security SystemsInstruction (CNSSI) No. >1253, "Security Categorization and Control Selection for National Security >Systems"" > > > > > >How can I get this? rpm preferred
AFAIK Red Hat Enterprise Linux 6.8 Beta includes scap-security-guide RPM based on upstream 0.1.28 version already:
http://www.redhat.com/en/about/blog/red-hat-enterprise-linux-68-beta-now-available
therefore you can obtain the updated scap-security-guideRPM from that release for now, till the moment Red Hat Enterprise Linux 6 Update 8 is generally available.
Hope this helps. Let us know if we can be of any further guidance.Direct link to the beta RPM: https://access.redhat.com/downloads/content/rhel--- 6/x86_64/160/scap-security-guide/0.1.28-2.el6/noarch/f21541eb/package
In regards to a CNSSI profile, we're trying to sort out what that'd actually mean. NSA's CNSSI 12-53 is different than NRO, which is different than DISA... who's CNSSI 12-53 overlay to we follow? What would be most useful/applicable?
-- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org mailto:scap-security- guide@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/scap-security- guide@lists.fedorahosted.org https://github.com/OpenSCAP/scap-security-guide/
--
Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699
-- This account not approved for unencrypted proprietary information --
When we attempted the tailoring files it was quite easy to override individual values but it didn't seem to be able to enhance entire sets of both XCCDF and OVAL ties.
100% open to the possibility that we're missing something and I haven't really found any instances of how to do this particular action. The GUI tools are targeted toward simple selectors which is too simplistic for what we need to do.
Thanks,
Trevor
On Tue, Apr 12, 2016 at 9:57 AM, Matt Micene matt.micene@dlt.com wrote:
-----Original Message----- From: Trevor Vaughan [mailto:tvaughan@onyxpoint.com] Sent: Friday, April 08, 2016 9:51 AM
I should be able to *easily* start from a base, replace the parts that I
need
to, trace back to the original information, and set my own parameters.
- There should be a base CNSS 1253 policy that is the common XCCDF
ground
- Each branch should have their own derived CNSS 1253 policies that
override the requisite XCCDF and OVAL content as necessary
Nothing should be repeated that is not overridden
Overrides should be understood in the derived content
This should be easy...it's not (actually, it appears to be impossible
without
tying yourself in knots)
This is my understanding of what tailoring files are intended to do, do they fall short in your use case?
Matt Micene DLT Solutions Solution Architect RHCA# 100-002-435 Direct 703-773-1195
On Thu, Mar 24, 2016 at 12:48 PM, Shawn Wells <shawn@redhat.com mailto:shawn@redhat.com > wrote:
On 3/23/16 6:25 AM, Jan Lieskovsky wrote: Hello Daniel, thank you for contacting us. ----- Original Message ----- >From: "DanWarburton"<dan.warburton@jvncomm.com mailto:dan.warburton@jvncomm.com > >To: "SCAP Security Guide"<scap-security- guide@lists.fedorahosted.org mailto:scap-security- guide@lists.fedorahosted.org > >Sent: Tuesday, March 22, 2016 8:36:27 PM >Subject: cnssi No 1253 profile needed > > > > > > >http://static.open-scap.org/ssg-guides/ssg-rhel6- guide-nist-cl-il-al.html > >I cannot locate this guide. I have redhat scap- security-guide 0.10.21-3.el6 >which yum says is the latest.
This (CNSSI No. 1253) profile has been introduced startingfrom upstream scap-security-guide-0.1.27 release: [1]https://github.com/OpenSCAP/scap-security- guide/releases/tag/v0.1.27
thus as such is not included in scap-security-guide-0.1.21-3.el6 version yet you mention above.
> > >I think the profile for National Security SystemsInstruction (CNSSI) No. >1253, "Security Categorization and Control
Selection
for National Security >Systems"" > > > > > >How can I get this? rpm preferred
AFAIK Red Hat Enterprise Linux 6.8 Beta includes scap-security-guide RPM based on upstream 0.1.28 version already:
http://www.redhat.com/en/about/blog/red-hat-enterprise-linux-68-beta-now-available
therefore you can obtain the updated scap-security-guideRPM from that release for now, till the moment Red Hat Enterprise Linux 6 Update 8 is generally available.
Hope this helps. Let us know if we can be of any further guidance. Direct link to the beta RPM: https://access.redhat.com/downloads/content/rhel---6/x86_64/160/scap-security-guide/0.1.28-2.el6/noarch/f21541eb/package
In regards to a CNSSI profile, we're trying to sort out what that'dactually mean. NSA's CNSSI 12-53 is different than NRO, which is
different
than DISA... who's CNSSI 12-53 overlay to we follow? What would be most useful/applicable?
-- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org <mailto:scap-security-guide@lists.fedorahosted.org> https://lists.fedorahosted.org/admin/lists/scap-security- guide@lists.fedorahosted.org https://github.com/OpenSCAP/scap-security-guide/
--
Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699
-- This account not approved for unencrypted proprietary information --
-- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/scap-security-guide@lists.fedorah... https://github.com/OpenSCAP/scap-security-guide/
----- Original Message -----
From: "Trevor Vaughan" tvaughan@onyxpoint.com To: "SCAP Security Guide" scap-security-guide@lists.fedorahosted.org Sent: Tuesday, April 12, 2016 11:11:55 AM Subject: Re: cnssi No 1253 profile needed
When we attempted the tailoring files it was quite easy to override individual values but it didn't seem to be able to enhance entire sets of both XCCDF and OVAL ties.
This depends heavily on how the underlying content is written. Good flexible can be tailored to a great extent. If everything is hardcoded it can't really be tailored.
Which content were you experimenting with?
The main RH6 and RH7 SSG profiles.
On Thu, Apr 21, 2016 at 11:21 AM, Martin Preisler mpreisle@redhat.com wrote:
----- Original Message -----
From: "Trevor Vaughan" tvaughan@onyxpoint.com To: "SCAP Security Guide" scap-security-guide@lists.fedorahosted.org Sent: Tuesday, April 12, 2016 11:11:55 AM Subject: Re: cnssi No 1253 profile needed
When we attempted the tailoring files it was quite easy to override individual values but it didn't seem to be able to enhance entire sets of both XCCDF and OVAL ties.
This depends heavily on how the underlying content is written. Good flexible can be tailored to a great extent. If everything is hardcoded it can't really be tailored.
Which content were you experimenting with?
-- Martin Preisler Identity Management and Platform Security | Red Hat, Inc. -- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/scap-security-guide@lists.fedorah... https://github.com/OpenSCAP/scap-security-guide/
----- Original Message -----
From: "Trevor Vaughan" tvaughan@onyxpoint.com To: "SCAP Security Guide" scap-security-guide@lists.fedorahosted.org Sent: Sunday, April 24, 2016 2:03:25 PM Subject: Re: cnssi No 1253 profile needed
The main RH6 and RH7 SSG profiles.
Could you write up the use-cases and report it as a bug? Probably we can expose something in the rules as variables and then you will be able to tailor it in the way you need.
On 4/25/16 2:51 PM, Martin Preisler wrote:
----- Original Message -----
From: "Trevor Vaughan"tvaughan@onyxpoint.com To: "SCAP Security Guide"scap-security-guide@lists.fedorahosted.org Sent: Sunday, April 24, 2016 2:03:25 PM Subject: Re: cnssi No 1253 profile needed
The main RH6 and RH7 SSG profiles.
Could you write up the use-cases and report it as a bug? Probably we can expose something in the rules as variables and then you will be able to tailor it in the way you need.
We're polishing out the RHEL7 STIG. Once that activity clears, we'll start working on a DoD Secure Host Baseline. (Interesting to talk about incorporating/elevating SIMP into that. Lets hold that conversation for a minute though.)
The working intent is something like this: - RHEL7 USGCB is a "base profile" that is aligned to NIAP's Operating System Protection Profile. Ref: https://github.com/OpenSCAP/scap-security-guide/blob/master/RHEL/7/input/pro...
- RHEL7 STIG extends base NIAP profile with whatever things DISA feels is relevant: https://github.com/OpenSCAP/scap-security-guide/blob/master/RHEL/7/input/pro...
- The DoD Secure Baseline will extend the NIAP profile with CNSSI 1253 overlay controls.
These three common/related profiles should set the base configurations for US Government. They'll all ship natively in the installer, allowing users to directly deploy into these configurations (as hopefully been useful with the RHEL7 Vendor STIG!).
That leads to solving how people will tailor these baselines. In the most simplistic use case, users can load SCAP Workbench and modify rule selections and refine values. SCAP Workbench will generate custom RPMs (if ran on RHEL hosts), and/or a "tailoring file" that outlines how you drifted from the common baseline. More advanced users can cryptographically hash things for integrity checking. The content can also be imported into Satellite for central config management/scanning.
Trevor, how do you think you'll need to modify these for your use?
Apologies for the late reply, I fell off of the planet for a while there.
So, let's take this for instance: https://github.com/OpenSCAP/scap-security-guide/blob/master/RHEL/7/input/pro...
That's a good setting, and a useful variable, however I need to modify the OVAL *checks* themselves to understand an LDAP-aware environment as well as accepting either the cracklib or pwquality PAM plugins since they are both functionally accurate.
If I meet this requirement in LDAP, it should also be done on the host, but both are valid methods for enforcing the policy.
Additionally, I now have a method for mapping my variables into policy with our compliance_markup function https://github.com/simp/pupmod-simp-compliance_markup. And these can be validated over time against set variables. The first working example file can be found at https://github.com/simp/simp-core/blob/5.1.X/src/puppet/bootstrap/environmen... .
Each of these variables should, in practice, map back to some level of SCAP verifiable code. But, we implement items that are not yet in the SSG/STIG/Whatever. To this end, we need to be able to easily extend the content, without forking, in a user friendly manner. I think we *may* be able to do this by rolling additional files into a Data Stream but I'm not quite certain from the existing documentation.
Finally, we're starting to revamp the way that we do documentation to be application-centric with the goal of having our acceptance tests run micro-SCAP scans and have the output injected into our security documentation at build time.
This is all well and good but, to really be successful, we need to be able to override specific OVAL content to test the way that we implement in a non-monolithic method.
I didn't find any tools for this and I *really* don't want to fork the whole thing to change OVAL content.
Fundamentally, I want to enable a 'trust but verify' model where Puppet enforces our configuration and feeds data into a SCAP scanning system but the SCAP scanner actually validates that the system is performing as expected.
But again, perhaps I'm just doing it incorrectly and hopefully this helps clarify my use case.
Thanks,
Trevor
On Tue, Apr 26, 2016 at 1:49 PM, Shawn Wells shawn@redhat.com wrote:
On 4/25/16 2:51 PM, Martin Preisler wrote:
----- Original Message -----
From: "Trevor Vaughan"tvaughan@onyxpoint.com To: "SCAP Security Guide"scap-security-guide@lists.fedorahosted.org Sent: Sunday, April 24, 2016 2:03:25 PM Subject: Re: cnssi No 1253 profile needed
The main RH6 and RH7 SSG profiles.
Could you write up the use-cases and report it as a bug? Probably we can expose something in the rules as variables and then you will be able to tailor it in the way you need.
We're polishing out the RHEL7 STIG. Once that activity clears, we'll start working on a DoD Secure Host Baseline. (Interesting to talk about incorporating/elevating SIMP into that. Lets hold that conversation for a minute though.)
The working intent is something like this:
- RHEL7 USGCB is a "base profile" that is aligned to NIAP's Operating
System Protection Profile. Ref:
https://github.com/OpenSCAP/scap-security-guide/blob/master/RHEL/7/input/pro...
- RHEL7 STIG extends base NIAP profile with whatever things DISA feels is
relevant:
https://github.com/OpenSCAP/scap-security-guide/blob/master/RHEL/7/input/pro...
- The DoD Secure Baseline will extend the NIAP profile with CNSSI 1253
overlay controls.
These three common/related profiles should set the base configurations for US Government. They'll all ship natively in the installer, allowing users to directly deploy into these configurations (as hopefully been useful with the RHEL7 Vendor STIG!).
That leads to solving how people will tailor these baselines. In the most simplistic use case, users can load SCAP Workbench and modify rule selections and refine values. SCAP Workbench will generate custom RPMs (if ran on RHEL hosts), and/or a "tailoring file" that outlines how you drifted from the common baseline. More advanced users can cryptographically hash things for integrity checking. The content can also be imported into Satellite for central config management/scanning.
Trevor, how do you think you'll need to modify these for your use?
-- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/scap-security-guide@lists.fedorah... https://github.com/OpenSCAP/scap-security-guide/
scap-security-guide@lists.fedorahosted.org
-
Brandon Whalen -
Dan Warburton -
Jan Lieskovsky -
Mackanick, Jason W CIV DISA RE (US) -
Martin Preisler -
Matt Micene -
Shawn Wells -
Steve Grubb -
Trevor Vaughan -
Šimon Lukašík