Good day. I am trying to apply current RHEL7 STIG guidance to AWS EC2 instances and have run into issues. Could someone check my conclusions below and let me know if I missed something?
- OpenSCAP doesn't yet support RHEL7 STIG V2R6 in its in-tree code (including remediation code) - The NIST NCP for RHEL7 from https://github.com/ComplianceAsCode/content/tree/master/rhel7 doesn't yet include STIG V2R4 remediations - The actual DISA RHEL7 STIG XCCDF file does not include fixes, such that OpenSCAP could use it to generate remediation scripts - https://github.com/MindPointGroup/RHEL7-STIG is probably the best RHEL7 STIG remediation script that's publicly available
Thanks for any corrections,
On Thu, Mar 5, 2020, at 12:57 PM, Jeff Bachtel wrote:
Good day. I am trying to apply current RHEL7 STIG guidance to AWS EC2 instances and have run into issues. Could someone check my conclusions below and let me know if I missed something?
- OpenSCAP doesn't yet support RHEL7 STIG V2R6 in its in-tree code
(including remediation code)
- The NIST NCP for RHEL7 from
https://github.com/ComplianceAsCode/content/tree/master/rhel7 doesn't yet include STIG V2R4 remediations
- The actual DISA RHEL7 STIG XCCDF file does not include fixes, such
that OpenSCAP could use it to generate remediation scripts
- https://github.com/MindPointGroup/RHEL7-STIG is probably the best
RHEL7 STIG remediation script that's publicly available
All correct from my perspective.
V/r, James Cassell
On 3/5/20 1:00 PM, James Cassell wrote:
On Thu, Mar 5, 2020, at 12:57 PM, Jeff Bachtel wrote:
Good day. I am trying to apply current RHEL7 STIG guidance to AWS EC2 instances and have run into issues. Could someone check my conclusions below and let me know if I missed something?
- OpenSCAP doesn't yet support RHEL7 STIG V2R6 in its in-tree code
(including remediation code)
- The NIST NCP for RHEL7 from
https://github.com/ComplianceAsCode/content/tree/master/rhel7 doesn't yet include STIG V2R4 remediations
- The actual DISA RHEL7 STIG XCCDF file does not include fixes, such
that OpenSCAP could use it to generate remediation scripts -https://github.com/MindPointGroup/RHEL7-STIG is probably the best RHEL7 STIG remediation script that's publicly available
All correct from my perspective.
To the best of our knowledge there haven't been any substantive changes to the DISA content. At least we haven't been informed of any (eg rule selections/removals, changing variables like password length, etc).
That said, could be interesting to run the Red Hat provided remediations and then re-scan with the DISA-provided content. Goal would be to see if anything fails... in theory showing any gaps between the content.
Would you be interested/able to help do that? Here's the ansible content:
On Thu, Mar 5, 2020, at 9:57 PM, Shawn Wells wrote:
On 3/5/20 1:00 PM, James Cassell wrote:
On Thu, Mar 5, 2020, at 12:57 PM, Jeff Bachtel wrote:
Good day. I am trying to apply current RHEL7 STIG guidance to AWS EC2
instances and have run into issues. Could someone check my conclusions below and let me know if I missed something?
- OpenSCAP doesn't yet support RHEL7 STIG V2R6 in its in-tree code
(including remediation code)
- The NIST NCP for RHEL7 from
https://github.com/ComplianceAsCode/content/tree/master/rhel7 doesn't
yet include STIG V2R4 remediations
- The actual DISA RHEL7 STIG XCCDF file does not include fixes, such
that OpenSCAP could use it to generate remediation scripts
- https://github.com/MindPointGroup/RHEL7-STIG is probably the best
RHEL7 STIG remediation script that's publicly available
All correct from my perspective.
To the best of our knowledge there haven't been any substantive changes to the DISA content. At least we haven't been informed of any (eg rule selections/removals, changing variables like password length, etc).
That said, could be interesting to run the Red Hat provided remediations and then re-scan with the DISA-provided content. Goal
It's concerning that this hasn't already been done.
would be to see if anything fails... in theory showing any gaps between the content.
Would you be interested/able to help do that? Here's the ansible content:
Unfortunately, that "RedHatOfficial" ansible role has some problems:
1. It does not follow ansible best practices such as prefixing each role variable with a variable namespace unique to the role, such as a `rhel7_stig_` prefix.
2. It is not idempotent
3. There is no explanation for any of the variables.
4. It's nearly impossible to audit any changes: https://github.com/RedHatOfficial/ansible-role-rhel7-stig/commit/3cdf26b66cc...
"7,176 additions, 8,160 deletions not shown because the diff is too large. Please use a local Git client to view these changes. "
5. The thing is a monstrosity at 16K lines for its tasks, so even if you audit it once, good luck auditing half of it again next time an update is pushed. (The ansible-lockdown ( https://github.com/ansible/ansible-lockdown ) role currently under the MindPointGroup org is also not tiny at 3.8K lines for its tasks.)
6. Does not practice DRY (don't repeat yourself), contributing to (4). RedHatOfficial show 578 tasks when run with `--list-tasks` whereas MindPointGroup shows 314 tasks. (RH lists "only" 84% more unique tasks, but has 420% more lines to audit.)
7. It's not really an open source project, but generated code from an open source project.
8. All PRs to the role are being ignored: https://github.com/RedHatOfficial/ansible-role-rhel7-stig/pulls
9. It clearly hasn't been audited by anyone who is familiar both with implementing STIG requirements as a System Administrator and with writing and consuming Ansible roles.
10. It clearly is not used nor even tested by Red Hat itself. Such things as setting the login banner text to the literal REGEX that should match the banner, which is completely illegible, and would fail the DISA content check. It doesn't look like Red Hat even uses their shipped scap-security-guide package to test the "RedHatOfficial" ansible role, as this would certainly have been caught.
(Yes, they literally set the banner as a regex displayed to the user): `(^You[\s\n]+are[\s\n]+accessing[\s\n]+a[\s\n]+U.S.[\s\n]+Government[\s\n]+`...
I'd previously opened issues against the repo for these and other items, but they have been "disappeared", so I can't even refer you to them, and it appears that issues have now been turned off entirely for the repo.
Other things I'd be concerned about but haven't checked due to the items above:
11. Does it remediate a system without bricking it or severely disabling it? (scap-security-guide bash remediations did not have this property last time I tried 2+ years ago.)
12. Does it support ansible check_mode?
13. Does check_mode accurately report changes that would be made if it were run for real?
14. Does every task that reports "OK" (i.e., "not changed") when run for real, actually leave the system untouched?
Consider the above my review of the https://github.com/RedHatOfficial/ansible-role-rhel7-stig ansible role. I Didn't expect to write so much, but there you have it.
V/r, James Cassell
Hi James,
From what I've seen of the project (someone please correct me if I'm wrong), the Ansible code from the SSG was meant to help you address individual items without really being a cohesive infrastructure. Cohesive infrastructures take a LOT of time to build and test.
What you're asking for is what we do in the FOSS SIMP project https://simp-project.com and we actually run the SSG tests against our enforcement components on a regular basis as well as InSpect tests and compare the two. By doing this, we've found issues in our code, the SSG rules, and the InSpec rules over time.
We'd love more interested people to take a look and help us close the feedback loop between the two projects.
Thanks,
Trevor
On Fri, Mar 6, 2020 at 12:14 AM James Cassell fedoraproject@cyberpear.com wrote:
On Thu, Mar 5, 2020, at 9:57 PM, Shawn Wells wrote:
On 3/5/20 1:00 PM, James Cassell wrote:
On Thu, Mar 5, 2020, at 12:57 PM, Jeff Bachtel wrote:
Good day. I am trying to apply current RHEL7 STIG guidance to AWS EC2
instances and have run into issues. Could someone check my conclusions below and let me know if I missed something?
- OpenSCAP doesn't yet support RHEL7 STIG V2R6 in its in-tree code
(including remediation code)
- The NIST NCP for RHEL7 from
https://github.com/ComplianceAsCode/content/tree/master/rhel7
doesn't
yet include STIG V2R4 remediations
- The actual DISA RHEL7 STIG XCCDF file does not include fixes, such
that OpenSCAP could use it to generate remediation scripts
- https://github.com/MindPointGroup/RHEL7-STIG is probably the best
RHEL7 STIG remediation script that's publicly available
All correct from my perspective.
To the best of our knowledge there haven't been any substantive changes to the DISA content. At least we haven't been informed of any (eg rule selections/removals, changing variables like password length, etc).
That said, could be interesting to run the Red Hat provided remediations and then re-scan with the DISA-provided content. Goal
It's concerning that this hasn't already been done.
would be to see if anything fails... in theory showing any gaps between the content.
Would you be interested/able to help do that? Here's the ansible content:
Unfortunately, that "RedHatOfficial" ansible role has some problems:
- It does not follow ansible best practices such as prefixing each role
variable with a variable namespace unique to the role, such as a `rhel7_stig_` prefix.
It is not idempotent
There is no explanation for any of the variables.
It's nearly impossible to audit any changes:
https://github.com/RedHatOfficial/ansible-role-rhel7-stig/commit/3cdf26b66cc...
"7,176 additions, 8,160 deletions not shown because the diff is too
large. Please use a local Git client to view these changes. "
- The thing is a monstrosity at 16K lines for its tasks, so even if you
audit it once, good luck auditing half of it again next time an update is pushed. (The ansible-lockdown ( https://github.com/ansible/ansible-lockdown ) role currently under the MindPointGroup org is also not tiny at 3.8K lines for its tasks.)
- Does not practice DRY (don't repeat yourself), contributing to (4).
RedHatOfficial show 578 tasks when run with `--list-tasks` whereas MindPointGroup shows 314 tasks. (RH lists "only" 84% more unique tasks, but has 420% more lines to audit.)
- It's not really an open source project, but generated code from an open
source project.
- All PRs to the role are being ignored:
https://github.com/RedHatOfficial/ansible-role-rhel7-stig/pulls
- It clearly hasn't been audited by anyone who is familiar both with
implementing STIG requirements as a System Administrator and with writing and consuming Ansible roles.
- It clearly is not used nor even tested by Red Hat itself. Such things
as setting the login banner text to the literal REGEX that should match the banner, which is completely illegible, and would fail the DISA content check. It doesn't look like Red Hat even uses their shipped scap-security-guide package to test the "RedHatOfficial" ansible role, as this would certainly have been caught.
(Yes, they literally set the banner as a regex displayed to the user):
`(^You[\s\n]+are[\s\n]+accessing[\s\n]+a[\s\n]+U.S.[\s\n]+Government[\s\n]+`...
I'd previously opened issues against the repo for these and other items, but they have been "disappeared", so I can't even refer you to them, and it appears that issues have now been turned off entirely for the repo.
Other things I'd be concerned about but haven't checked due to the items above:
- Does it remediate a system without bricking it or severely disabling
it? (scap-security-guide bash remediations did not have this property last time I tried 2+ years ago.)
Does it support ansible check_mode?
Does check_mode accurately report changes that would be made if it
were run for real?
- Does every task that reports "OK" (i.e., "not changed") when run for
real, actually leave the system untouched?
Consider the above my review of the https://github.com/RedHatOfficial/ansible-role-rhel7-stig ansible role. I Didn't expect to write so much, but there you have it.
V/r, James Cassell _______________________________________________ scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedor...
On Fri, Mar 6, 2020, at 8:48 AM, Trevor Vaughan wrote:
Hi James,
From what I've seen of the project (someone please correct me if I'm wrong), the Ansible code from the SSG was meant to help you address individual items without really being a cohesive infrastructure. Cohesive infrastructures take a LOT of time to build and test.
What you're asking for is what we do in the FOSS SIMP project https://simp-project.com and we actually run the SSG tests against our enforcement components on a regular basis as well as InSpect tests and compare the two. By doing this, we've found issues in our code, the SSG rules, and the InSpec rules over time.
We'd love more interested people to take a look and help us close the feedback loop between the two projects.
Looks like a nice project. I'm just not interested in puppet these days. I'll recommend your project to folks who are puppet shops if I come across them. (Everyone I work with is using ansible these days.)
V/r, James Cassell
Thanks,
Trevor
On Fri, Mar 6, 2020 at 12:14 AM James Cassell fedoraproject@cyberpear.com wrote:
On Thu, Mar 5, 2020, at 9:57 PM, Shawn Wells wrote:
On 3/5/20 1:00 PM, James Cassell wrote:
On Thu, Mar 5, 2020, at 12:57 PM, Jeff Bachtel wrote:
Good day. I am trying to apply current RHEL7 STIG guidance to AWS EC2
instances and have run into issues. Could someone check my conclusions below and let me know if I missed something?
- OpenSCAP doesn't yet support RHEL7 STIG V2R6 in its in-tree code
(including remediation code)
- The NIST NCP for RHEL7 from
https://github.com/ComplianceAsCode/content/tree/master/rhel7 doesn't
yet include STIG V2R4 remediations
- The actual DISA RHEL7 STIG XCCDF file does not include fixes, such
that OpenSCAP could use it to generate remediation scripts
- https://github.com/MindPointGroup/RHEL7-STIG is probably the best
RHEL7 STIG remediation script that's publicly available
All correct from my perspective.
To the best of our knowledge there haven't been any substantive changes to the DISA content. At least we haven't been informed of any (eg rule selections/removals, changing variables like password length, etc).
That said, could be interesting to run the Red Hat provided remediations and then re-scan with the DISA-provided content. Goal
It's concerning that this hasn't already been done.
would be to see if anything fails... in theory showing any gaps between the content.
Would you be interested/able to help do that? Here's the ansible content:
Unfortunately, that "RedHatOfficial" ansible role has some problems:
It does not follow ansible best practices such as prefixing each role variable with a variable namespace unique to the role, such as a `rhel7_stig_` prefix.
It is not idempotent
There is no explanation for any of the variables.
It's nearly impossible to audit any changes: https://github.com/RedHatOfficial/ansible-role-rhel7-stig/commit/3cdf26b66cc...
"7,176 additions, 8,160 deletions not shown because the diff is too large. Please use a local Git client to view these changes. "
The thing is a monstrosity at 16K lines for its tasks, so even if you audit it once, good luck auditing half of it again next time an update is pushed. (The ansible-lockdown ( https://github.com/ansible/ansible-lockdown ) role currently under the MindPointGroup org is also not tiny at 3.8K lines for its tasks.)
Does not practice DRY (don't repeat yourself), contributing to (4). RedHatOfficial show 578 tasks when run with `--list-tasks` whereas MindPointGroup shows 314 tasks. (RH lists "only" 84% more unique tasks, but has 420% more lines to audit.)
It's not really an open source project, but generated code from an open source project.
All PRs to the role are being ignored: https://github.com/RedHatOfficial/ansible-role-rhel7-stig/pulls
It clearly hasn't been audited by anyone who is familiar both with implementing STIG requirements as a System Administrator and with writing and consuming Ansible roles.
It clearly is not used nor even tested by Red Hat itself. Such things as setting the login banner text to the literal REGEX that should match the banner, which is completely illegible, and would fail the DISA content check. It doesn't look like Red Hat even uses their shipped scap-security-guide package to test the "RedHatOfficial" ansible role, as this would certainly have been caught.
(Yes, they literally set the banner as a regex displayed to the user): `(^You[\s\n]+are[\s\n]+accessing[\s\n]+a[\s\n]+U.S.[\s\n]+Government[\s\n]+`...
I'd previously opened issues against the repo for these and other items, but they have been "disappeared", so I can't even refer you to them, and it appears that issues have now been turned off entirely for the repo.
Other things I'd be concerned about but haven't checked due to the items above:
Does it remediate a system without bricking it or severely disabling it? (scap-security-guide bash remediations did not have this property last time I tried 2+ years ago.)
Does it support ansible check_mode?
Does check_mode accurately report changes that would be made if it were run for real?
Does every task that reports "OK" (i.e., "not changed") when run for real, actually leave the system untouched?
Consider the above my review of the https://github.com/RedHatOfficial/ansible-role-rhel7-stig ansible role. I Didn't expect to write so much, but there you have it.
V/r, James Cassell _______________________________________________ scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedor...
-- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 x788
No problem. We'll take Ansible ports of the code into the project as well but there are some things that Ansible can't do around (that I know of) around compliance introspection of the codebase that keeps us with puppet so far.
Thanks,
Trevor
On Fri, Mar 6, 2020 at 10:05 AM James Cassell fedoraproject@cyberpear.com wrote:
On Fri, Mar 6, 2020, at 8:48 AM, Trevor Vaughan wrote:
Hi James,
From what I've seen of the project (someone please correct me if I'm wrong), the Ansible code from the SSG was meant to help you address individual items without really being a cohesive infrastructure. Cohesive infrastructures take a LOT of time to build and test.
What you're asking for is what we do in the FOSS SIMP project https://simp-project.com and we actually run the SSG tests against our enforcement components on a regular basis as well as InSpect tests and compare the two. By doing this, we've found issues in our code, the SSG rules, and the InSpec rules over time.
We'd love more interested people to take a look and help us close the feedback loop between the two projects.
Looks like a nice project. I'm just not interested in puppet these days. I'll recommend your project to folks who are puppet shops if I come across them. (Everyone I work with is using ansible these days.)
V/r, James Cassell
Thanks,
Trevor
On Fri, Mar 6, 2020 at 12:14 AM James Cassell fedoraproject@cyberpear.com wrote:
On Thu, Mar 5, 2020, at 9:57 PM, Shawn Wells wrote:
On 3/5/20 1:00 PM, James Cassell wrote:
On Thu, Mar 5, 2020, at 12:57 PM, Jeff Bachtel wrote:
Good day. I am trying to apply current RHEL7 STIG guidance to
AWS EC2
instances and have run into issues. Could someone check my
conclusions
below and let me know if I missed something?
- OpenSCAP doesn't yet support RHEL7 STIG V2R6 in its in-tree code
(including remediation code)
- The NIST NCP for RHEL7 from
https://github.com/ComplianceAsCode/content/tree/master/rhel7
doesn't
yet include STIG V2R4 remediations
- The actual DISA RHEL7 STIG XCCDF file does not include fixes,
such
that OpenSCAP could use it to generate remediation scripts
- https://github.com/MindPointGroup/RHEL7-STIG is probably the
best
RHEL7 STIG remediation script that's publicly available
All correct from my perspective.
To the best of our knowledge there haven't been any substantive
changes
to the DISA content. At least we haven't been informed of any (eg
rule
selections/removals, changing variables like password length, etc).
That said, could be interesting to run the Red Hat provided remediations and then re-scan with the DISA-provided content. Goal
It's concerning that this hasn't already been done.
would be to see if anything fails... in theory showing any gaps
between
the content.
Would you be interested/able to help do that? Here's the ansible
content:
Unfortunately, that "RedHatOfficial" ansible role has some problems:
- It does not follow ansible best practices such as prefixing each
role variable with a variable namespace unique to the role, such as a `rhel7_stig_` prefix.
It is not idempotent
There is no explanation for any of the variables.
It's nearly impossible to audit any changes:
https://github.com/RedHatOfficial/ansible-role-rhel7-stig/commit/3cdf26b66cc...
> "7,176 additions, 8,160 deletions not shown because the diff is
too large. Please use a local Git client to view these changes. "
- The thing is a monstrosity at 16K lines for its tasks, so even if
you audit it once, good luck auditing half of it again next time an update is pushed. (The ansible-lockdown ( https://github.com/ansible/ansible-lockdown ) role currently under the MindPointGroup org is also not tiny at 3.8K lines for its tasks.)
- Does not practice DRY (don't repeat yourself), contributing to
(4). RedHatOfficial show 578 tasks when run with `--list-tasks` whereas MindPointGroup shows 314 tasks. (RH lists "only" 84% more unique tasks, but has 420% more lines to audit.)
- It's not really an open source project, but generated code from an
open source project.
- All PRs to the role are being ignored:
https://github.com/RedHatOfficial/ansible-role-rhel7-stig/pulls
- It clearly hasn't been audited by anyone who is familiar both with
implementing STIG requirements as a System Administrator and with writing and consuming Ansible roles.
- It clearly is not used nor even tested by Red Hat itself. Such
things as setting the login banner text to the literal REGEX that should match the banner, which is completely illegible, and would fail the DISA content check. It doesn't look like Red Hat even uses their shipped scap-security-guide package to test the "RedHatOfficial" ansible role, as this would certainly have been caught.
(Yes, they literally set the banner as a regex displayed to the user):
`(^You[\s\n]+are[\s\n]+accessing[\s\n]+a[\s\n]+U.S.[\s\n]+Government[\s\n]+`...
I'd previously opened issues against the repo for these and other
items, but they have been "disappeared", so I can't even refer you to them, and it appears that issues have now been turned off entirely for the repo.
Other things I'd be concerned about but haven't checked due to the
items above:
- Does it remediate a system without bricking it or severely
disabling it? (scap-security-guide bash remediations did not have this property last time I tried 2+ years ago.)
Does it support ansible check_mode?
Does check_mode accurately report changes that would be made if
it were run for real?
- Does every task that reports "OK" (i.e., "not changed") when run
for real, actually leave the system untouched?
Consider the above my review of the
https://github.com/RedHatOfficial/ansible-role-rhel7-stig ansible role. I Didn't expect to write so much, but there you have it.
V/r, James Cassell _______________________________________________ scap-security-guide mailing list --
scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to
scap-security-guide-leave@lists.fedorahosted.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedor...
-- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 x788
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedor...
Trevor,
Can you provide details on the compliance introspection? If it’s What I think it is, we have the same concerns and I’m looking for ways to tackle it.
Sent from my iPhone
On Mar 6, 2020, at 11:11 AM, Trevor Vaughan tvaughan@onyxpoint.com wrote:
No problem. We'll take Ansible ports of the code into the project as well but there are some things that Ansible can't do around (that I know of) around compliance introspection of the codebase that keeps us with puppet so far.
Thanks,
Trevor
On Fri, Mar 6, 2020 at 10:05 AM James Cassell <fedoraproject@cyberpear.commailto:fedoraproject@cyberpear.com> wrote:
On Fri, Mar 6, 2020, at 8:48 AM, Trevor Vaughan wrote:
Hi James,
From what I've seen of the project (someone please correct me if I'm wrong), the Ansible code from the SSG was meant to help you address individual items without really being a cohesive infrastructure. Cohesive infrastructures take a LOT of time to build and test.
What you're asking for is what we do in the FOSS SIMP project https://simp-project.com and we actually run the SSG tests against our enforcement components on a regular basis as well as InSpect tests and compare the two. By doing this, we've found issues in our code, the SSG rules, and the InSpec rules over time.
We'd love more interested people to take a look and help us close the feedback loop between the two projects.
Looks like a nice project. I'm just not interested in puppet these days. I'll recommend your project to folks who are puppet shops if I come across them. (Everyone I work with is using ansible these days.)
V/r, James Cassell
Thanks,
Trevor
On Fri, Mar 6, 2020 at 12:14 AM James Cassell <fedoraproject@cyberpear.commailto:fedoraproject@cyberpear.com> wrote:
On Thu, Mar 5, 2020, at 9:57 PM, Shawn Wells wrote:
On 3/5/20 1:00 PM, James Cassell wrote:
On Thu, Mar 5, 2020, at 12:57 PM, Jeff Bachtel wrote:
Good day. I am trying to apply current RHEL7 STIG guidance to AWS EC2
instances and have run into issues. Could someone check my conclusions below and let me know if I missed something?
- OpenSCAP doesn't yet support RHEL7 STIG V2R6 in its in-tree code
(including remediation code)
- The NIST NCP for RHEL7 from
https://github.com/ComplianceAsCode/content/tree/master/rhel7 doesn't
yet include STIG V2R4 remediations
- The actual DISA RHEL7 STIG XCCDF file does not include fixes, such
that OpenSCAP could use it to generate remediation scripts
- https://github.com/MindPointGroup/RHEL7-STIG is probably the best
RHEL7 STIG remediation script that's publicly available
All correct from my perspective.
To the best of our knowledge there haven't been any substantive changes to the DISA content. At least we haven't been informed of any (eg rule selections/removals, changing variables like password length, etc).
That said, could be interesting to run the Red Hat provided remediations and then re-scan with the DISA-provided content. Goal
It's concerning that this hasn't already been done.
would be to see if anything fails... in theory showing any gaps between the content.
Would you be interested/able to help do that? Here's the ansible content:
Unfortunately, that "RedHatOfficial" ansible role has some problems:
It does not follow ansible best practices such as prefixing each role variable with a variable namespace unique to the role, such as a `rhel7_stig_` prefix.
It is not idempotent
There is no explanation for any of the variables.
It's nearly impossible to audit any changes: https://github.com/RedHatOfficial/ansible-role-rhel7-stig/commit/3cdf26b66cc...
"7,176 additions, 8,160 deletions not shown because the diff is too large. Please use a local Git client to view these changes. "
The thing is a monstrosity at 16K lines for its tasks, so even if you audit it once, good luck auditing half of it again next time an update is pushed. (The ansible-lockdown ( https://github.com/ansible/ansible-lockdown ) role currently under the MindPointGroup org is also not tiny at 3.8K lines for its tasks.)
Does not practice DRY (don't repeat yourself), contributing to (4). RedHatOfficial show 578 tasks when run with `--list-tasks` whereas MindPointGroup shows 314 tasks. (RH lists "only" 84% more unique tasks, but has 420% more lines to audit.)
It's not really an open source project, but generated code from an open source project.
All PRs to the role are being ignored: https://github.com/RedHatOfficial/ansible-role-rhel7-stig/pulls
It clearly hasn't been audited by anyone who is familiar both with implementing STIG requirements as a System Administrator and with writing and consuming Ansible roles.
It clearly is not used nor even tested by Red Hat itself. Such things as setting the login banner text to the literal REGEX that should match the banner, which is completely illegible, and would fail the DISA content check. It doesn't look like Red Hat even uses their shipped scap-security-guide package to test the "RedHatOfficial" ansible role, as this would certainly have been caught.
(Yes, they literally set the banner as a regex displayed to the user): `(^You[\s\n]+are[\s\n]+accessing[\s\n]+a[\s\n]+U.S.[\s\n]+Government[\s\n]+`...
I'd previously opened issues against the repo for these and other items, but they have been "disappeared", so I can't even refer you to them, and it appears that issues have now been turned off entirely for the repo.
Other things I'd be concerned about but haven't checked due to the items above:
Does it remediate a system without bricking it or severely disabling it? (scap-security-guide bash remediations did not have this property last time I tried 2+ years ago.)
Does it support ansible check_mode?
Does check_mode accurately report changes that would be made if it were run for real?
Does every task that reports "OK" (i.e., "not changed") when run for real, actually leave the system untouched?
Consider the above my review of the https://github.com/RedHatOfficial/ansible-role-rhel7-stig ansible role. I Didn't expect to write so much, but there you have it.
V/r, James Cassell _______________________________________________ scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.orgmailto:scap-security-guide-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedor...
-- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 x788
_______________________________________________ scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.orgmailto:scap-security-guide-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedor...
-- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 x788
-- This account not approved for unencrypted proprietary information -- _______________________________________________ scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedor...
Puppet is a compiler and the end state of the compiled artifacts is known prior to application on the target system.
Given this, the parameters of each artifact can be inspected prior to delivery and we can ensure that parameters meet the requirements before sending any information to the target system for application.
Ansible is procedural instead of declarative in execution which means that the final state cannot be known with the overall application of playbooks. However, this makes Ansible more suited to cross-system orchestration and dynamic one-off system configuration.
We've worked with several customers using Puppet as the 'over time' approach for compliance consistency and other tools (Ansible, Bolt, Salt, Chef, SSH in a loop, whatever) for the one-off approach.
We also like being able to disable the Ansible agent so that all inbound connections to systems are closed for maximum security.
Thanks,
Trevor
On Fri, Mar 6, 2020 at 2:16 PM Albrecht, Thomas C < thomas.c.albrecht@lmco.com> wrote:
Trevor,
Can you provide details on the compliance introspection? If it’s What I think it is, we have the same concerns and I’m looking for ways to tackle it.
Sent from my iPhone
On Mar 6, 2020, at 11:11 AM, Trevor Vaughan tvaughan@onyxpoint.com wrote:
No problem. We'll take Ansible ports of the code into the project as well but there are some things that Ansible can't do around (that I know of) around compliance introspection of the codebase that keeps us with puppet so far.
Thanks,
Trevor
On Fri, Mar 6, 2020 at 10:05 AM James Cassell <fedoraproject@cyberpear.com mailto:fedoraproject@cyberpear.com> wrote:
On Fri, Mar 6, 2020, at 8:48 AM, Trevor Vaughan wrote:
Hi James,
From what I've seen of the project (someone please correct me if I'm wrong), the Ansible code from the SSG was meant to help you address individual items without really being a cohesive infrastructure. Cohesive infrastructures take a LOT of time to build and test.
What you're asking for is what we do in the FOSS SIMP project https://simp-project.com and we actually run the SSG tests against our enforcement components on a regular basis as well as InSpect tests and compare the two. By doing this, we've found issues in our code, the SSG rules, and the InSpec rules over time.
We'd love more interested people to take a look and help us close the feedback loop between the two projects.
Looks like a nice project. I'm just not interested in puppet these days. I'll recommend your project to folks who are puppet shops if I come across them. (Everyone I work with is using ansible these days.)
V/r, James Cassell
Thanks,
Trevor
On Fri, Mar 6, 2020 at 12:14 AM James Cassell <fedoraproject@cyberpear.commailto:fedoraproject@cyberpear.com> wrote:
On Thu, Mar 5, 2020, at 9:57 PM, Shawn Wells wrote:
On 3/5/20 1:00 PM, James Cassell wrote:
On Thu, Mar 5, 2020, at 12:57 PM, Jeff Bachtel wrote:
Good day. I am trying to apply current RHEL7 STIG guidance to
AWS EC2
instances and have run into issues. Could someone check my
conclusions
below and let me know if I missed something?
- OpenSCAP doesn't yet support RHEL7 STIG V2R6 in its in-tree code
(including remediation code)
- The NIST NCP for RHEL7 from
https://github.com/ComplianceAsCode/content/tree/master/rhel7
doesn't
yet include STIG V2R4 remediations
- The actual DISA RHEL7 STIG XCCDF file does not include fixes, such
that OpenSCAP could use it to generate remediation scripts
- https://github.com/MindPointGroup/RHEL7-STIG is probably the best
RHEL7 STIG remediation script that's publicly available
All correct from my perspective.
To the best of our knowledge there haven't been any substantive
changes
to the DISA content. At least we haven't been informed of any (eg
rule
selections/removals, changing variables like password length, etc).
That said, could be interesting to run the Red Hat provided remediations and then re-scan with the DISA-provided content. Goal
It's concerning that this hasn't already been done.
would be to see if anything fails... in theory showing any gaps
between
the content.
Would you be interested/able to help do that? Here's the ansible
content:
Unfortunately, that "RedHatOfficial" ansible role has some problems:
- It does not follow ansible best practices such as prefixing each
role variable with a variable namespace unique to the role, such as a `rhel7_stig_` prefix.
It is not idempotent
There is no explanation for any of the variables.
It's nearly impossible to audit any changes:
https://github.com/RedHatOfficial/ansible-role-rhel7-stig/commit/3cdf26b66cc...
> "7,176 additions, 8,160 deletions not shown because the diff is
too large. Please use a local Git client to view these changes. "
- The thing is a monstrosity at 16K lines for its tasks, so even if
you audit it once, good luck auditing half of it again next time an update is pushed. (The ansible-lockdown ( https://github.com/ansible/ansible-lockdown ) role currently under the MindPointGroup org is also not tiny at 3.8K lines for its tasks.)
- Does not practice DRY (don't repeat yourself), contributing to
(4). RedHatOfficial show 578 tasks when run with `--list-tasks` whereas MindPointGroup shows 314 tasks. (RH lists "only" 84% more unique tasks, but has 420% more lines to audit.)
- It's not really an open source project, but generated code from an
open source project.
- All PRs to the role are being ignored:
https://github.com/RedHatOfficial/ansible-role-rhel7-stig/pulls
- It clearly hasn't been audited by anyone who is familiar both with
implementing STIG requirements as a System Administrator and with writing and consuming Ansible roles.
- It clearly is not used nor even tested by Red Hat itself. Such
things as setting the login banner text to the literal REGEX that should match the banner, which is completely illegible, and would fail the DISA content check. It doesn't look like Red Hat even uses their shipped scap-security-guide package to test the "RedHatOfficial" ansible role, as this would certainly have been caught.
(Yes, they literally set the banner as a regex displayed to the user):
`(^You[\s\n]+are[\s\n]+accessing[\s\n]+a[\s\n]+U.S.[\s\n]+Government[\s\n]+`...
I'd previously opened issues against the repo for these and other
items, but they have been "disappeared", so I can't even refer you to them, and it appears that issues have now been turned off entirely for the repo.
Other things I'd be concerned about but haven't checked due to the
items above:
- Does it remediate a system without bricking it or severely
disabling it? (scap-security-guide bash remediations did not have this property last time I tried 2+ years ago.)
Does it support ansible check_mode?
Does check_mode accurately report changes that would be made if
it were run for real?
- Does every task that reports "OK" (i.e., "not changed") when run
for real, actually leave the system untouched?
Consider the above my review of the
https://github.com/RedHatOfficial/ansible-role-rhel7-stig ansible role. I Didn't expect to write so much, but there you have it.
V/r, James Cassell _______________________________________________ scap-security-guide mailing list --
scap-security-guide@lists.fedorahosted.orgmailto: scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to
scap-security-guide-leave@lists.fedorahosted.orgmailto: scap-security-guide-leave@lists.fedorahosted.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedor...
-- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 x788
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.orgmailto: scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.orgmailto: scap-security-guide-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedor...
-- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 x788
-- This account not approved for unencrypted proprietary information -- _______________________________________________ scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedor... _______________________________________________ scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedor...
On 3/6/20 12:14 AM, James Cassell wrote:
On Thu, Mar 5, 2020, at 9:57 PM, Shawn Wells wrote:
On 3/5/20 1:00 PM, James Cassell wrote:
On Thu, Mar 5, 2020, at 12:57 PM, Jeff Bachtel wrote:
Good day. I am trying to apply current RHEL7 STIG guidance to AWS EC2
instances and have run into issues. Could someone check my conclusions below and let me know if I missed something?
- OpenSCAP doesn't yet support RHEL7 STIG V2R6 in its in-tree code
(including remediation code)
- The NIST NCP for RHEL7 from
https://github.com/ComplianceAsCode/content/tree/master/rhel7 doesn't
yet include STIG V2R4 remediations
- The actual DISA RHEL7 STIG XCCDF file does not include fixes, such
that OpenSCAP could use it to generate remediation scripts -https://github.com/MindPointGroup/RHEL7-STIG is probably the best RHEL7 STIG remediation script that's publicly available
All correct from my perspective.
To the best of our knowledge there haven't been any substantive changes to the DISA content. At least we haven't been informed of any (eg rule selections/removals, changing variables like password length, etc).
That said, could be interesting to run the Red Hat provided remediations and then re-scan with the DISA-provided content. Goal
It's concerning that this hasn't already been done.
would be to see if anything fails... in theory showing any gaps between the content.
Would you be interested/able to help do that? Here's the ansible content:
Unfortunately, that "RedHatOfficial" ansible role has some problems:
It does not follow ansible best practices such as prefixing each role variable with a variable namespace unique to the role, such as a `rhel7_stig_` prefix.
It is not idempotent
There is no explanation for any of the variables.
It's nearly impossible to audit any changes:https://github.com/RedHatOfficial/ansible-role-rhel7-stig/commit/3cdf26b66cc...
"7,176 additions, 8,160 deletions not shown because the diff is too large. Please use a local Git client to view these changes."
The thing is a monstrosity at 16K lines for its tasks, so even if you audit it once, good luck auditing half of it again next time an update is pushed. (The ansible-lockdown (https://github.com/ansible/ansible-lockdown ) role currently under the MindPointGroup org is also not tiny at 3.8K lines for its tasks.)
Does not practice DRY (don't repeat yourself), contributing to (4). RedHatOfficial show 578 tasks when run with `--list-tasks` whereas MindPointGroup shows 314 tasks. (RH lists "only" 84% more unique tasks, but has 420% more lines to audit.)
It's not really an open source project, but generated code from an open source project.
All PRs to the role are being ignored:https://github.com/RedHatOfficial/ansible-role-rhel7-stig/pulls
It clearly hasn't been audited by anyone who is familiar both with implementing STIG requirements as a System Administrator and with writing and consuming Ansible roles.
It clearly is not used nor even tested by Red Hat itself. Such things as setting the login banner text to the literal REGEX that should match the banner, which is completely illegible, and would fail the DISA content check. It doesn't look like Red Hat even uses their shipped scap-security-guide package to test the "RedHatOfficial" ansible role, as this would certainly have been caught.
(Yes, they literally set the banner as a regex displayed to the user): `(^You[\s\n]+are[\s\n]+accessing[\s\n]+a[\s\n]+U.S.[\s\n]+Government[\s\n]+`...
I'd previously opened issues against the repo for these and other items, but they have been "disappeared", so I can't even refer you to them, and it appears that issues have now been turned off entirely for the repo.
Other things I'd be concerned about but haven't checked due to the items above:
Does it remediate a system without bricking it or severely disabling it? (scap-security-guide bash remediations did not have this property last time I tried 2+ years ago.)
Does it support ansible check_mode?
Does check_mode accurately report changes that would be made if it were run for real?
Does every task that reports "OK" (i.e., "not changed") when run for real, actually leave the system untouched?
Consider the above my review of thehttps://github.com/RedHatOfficial/ansible-role-rhel7-stig ansible role. I Didn't expect to write so much, but there you have it.
Hi James - Wanted to say thanks for the actionable feedback. Have been scrambling getting the teams prepped to work from home. But this is very actionable -- will revisit next week.
On Thu, Mar 5, 2020 at 7:57 PM Shawn Wells shawn@redhat.com wrote:
On 3/5/20 1:00 PM, James Cassell wrote:
On Thu, Mar 5, 2020, at 12:57 PM, Jeff Bachtel wrote:
Good day. I am trying to apply current RHEL7 STIG guidance to AWS EC2 instances and have run into issues. Could someone check my conclusions below and let me know if I missed something?
- OpenSCAP doesn't yet support RHEL7 STIG V2R6 in its in-tree code
(including remediation code)
- The NIST NCP for RHEL7 from https://github.com/ComplianceAsCode/content/tree/master/rhel7 doesn't
yet include STIG V2R4 remediations
- The actual DISA RHEL7 STIG XCCDF file does not include fixes, such
that OpenSCAP could use it to generate remediation scripts
- https://github.com/MindPointGroup/RHEL7-STIG is probably the best
RHEL7 STIG remediation script that's publicly available
All correct from my perspective.
To the best of our knowledge there haven't been any substantive changes to the DISA content. At least we haven't been informed of any (eg rule selections/removals, changing variables like password length, etc).
That said, could be interesting to run the Red Hat provided remediations and then re-scan with the DISA-provided content. Goal would be to see if anything fails... in theory showing any gaps between the content.
Would you be interested/able to help do that? Here's the ansible content:
Ah, I actually HAVE done this. I ran the SCAP Ansible role for rhel7-stig (same as the galaxy link above, correct? Looks the same) against an AMI then launched and ran Tenable's STIG r2v4 scan against it. 150-something findings, because the STIG changed validations of things in a way that the role no longer solves. I was tricked a bit in my own head because SSG made a release right after the new STIG (r2v6) and I thought it was to keep up with the rev, but that was not the case.
So in short if RH is recommending the SSG / rhel7_stig role to customers to get close to compliant with modern STIG guidance, uh, it doesn't work. To be fair, the CIS RHEL7 STIG AMI is also Really Bad for hitting scan compliance.
I do appreciate everyone's answers on the thread, though. If the SSG rhel7-stig Ansible role is generated from XCCDF fix statements (I don't know that that's the case), would the solution then be to update the SSG RHEL7 STIG XCCDF from the DISA release, and put in new fixes?
Jeff
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedor...
scap-security-guide@lists.fedorahosted.org