search

ansible-lockdown / RHEL7-STIG

Ansible role for Red Hat 7 STIG Baseline
MIT License
284 stars 143 forks source link

Update for v2r1 #174

Closed jamescassell closed 3 years ago

jamescassell commented 6 years ago

Here's a fairly comprehensive list:

Global Changes

Modified Rules

Deleted

Added

Cosmetic Changes

shepdelacreme commented 6 years ago

I sent a couple emails to the DISA STIG support mailbox about this. This new "version" has no revision history and they don't plan on releasing one. So trying to figure out the differences is going to be a painful process of comparing XML documents or going rule by rule with STIG viewer.

jamescassell commented 6 years ago

Yeah, I saw that... I might get around to doing that in the next week depending on what else comes up.

jamescassell commented 6 years ago

edit: moved changelog to first comment

jamescassell commented 6 years ago

I've updated the first comment with a fairly comprehensive changelog, based on diffing the V1R4 and the V2R1 STIGs. As @shepdelacreme pointed out, DISA declined to provide this change log.

amkuchta commented 5 years ago

Is there a particular way that you guys would like PRs for the items in the original issue report (e.g. a separate PR for each task, or a PR for each category, etc.)?

I am currently working on the low-hanging (but tedious) fruit of knocking out the title updates, and want to make sure I am providing my changes in a way that is

  1. easy to review, and
  2. jives with what you expect

Also, as a side note, VSCode wants to change the formatting for each file on save - I've disabled this while I am making the updates, but am curious as to whether or not anyone else is running into that issue...

Thanks in advance!

shepdelacreme commented 5 years ago

I think generally we like to see related changes grouped. If you are updating titles across a lot of different items I think it is ok to group them in one PR but try and split out the changes in separate commits within the same PR to make it easy to review/comment.

For functional changes to existing tasks or newly implemented remediations, we prefer to have those changes in their own PR.

I'm not sure about the VSCode thing. I use it exclusively and I don't run into this issue...maybe its an extension? Are your yml files recognized as YAML or as Ansible files?

amkuchta commented 5 years ago

@shepdelacreme I'll keep that in mind - I'll be pushing all of the title updates in one go, but will be breaking out each individual change moving forward so that they are easier to track and review.

With regards to the VSCode issue, it looks like it may have been an extension (either "Prettier" or "Beautify" - I disabled both).

Thanks for the input!

amkuchta commented 5 years ago

Can we mark all of the cosmetic changes that are just command -> syscall to be completed? Looking at them, there is no action to update the playbooks. Same can be said for RHEL-07-020250

amkuchta commented 5 years ago

RHEL-07-030880 through RHEL-07-030920 also seem to be done...

shepdelacreme commented 5 years ago

Thanks! I went through a verified and checked off some more. Need to do a full audit of this list and update soon.

amkuchta commented 5 years ago

@shepdelacreme I actually ran a SCAP against a box (CentOS, but still), and am verifying quite a few non-SCAP findings manually. I'll be providing a list of everything that I see as being closed- it's extensive, and shows that this effort is much further along than the checklist details!

amkuchta commented 5 years ago

@jamescassell @shepdelacreme I went ahead and ran the playbook against a CentOS system, SCAP'd it, and completed a manual checklist, which I've attached for your review. My initial impression is that the playbook looks awesome and is ready for a release (with the exception of the PR (#238) that I submitted yesterday), but I will leave that to your discretion. As a side note, ignore the comments about OpenLDAP - that is what we use in our environment, and are specific to the next steps my group is going to have to take.

RHEL7_MPG_20190425_REDACTED.ckl.zip

jamescassell commented 5 years ago

Updated checklist to reflect current status. Added recommendations to some of the outstanding items.

georgenalen commented 3 years ago

Hello, I wanted to reach out and let you know that this issue is being closed. We have re-worked the role and want to start with a fresh issues list with this latest version. There was a post in the Ansible-Lockdown google group (https://groups.google.com/g/ansible-lockdown) with the details of the changes that are coming. Please checkout the thread titled RHEL 7 CIS and STIG Changes for all of the details, I also have the message pasted at below. Please as you use the latest version and open issue tickets as you find them, it is the best way for us to improve the role for everyone. Thank you for being part of the community and providing awareness of problems or advice on improvement. Reporting is a huge part of improving this project.

Hello, Thank you to everyone in the Ansible-Lockdown community who has contributed to RHEL7 STIG/CIS. Our team at MindPoint Group has been working with the entirety of the Ansible-Lockdown project, and we have some significant updates for both RHEL 7 STIG and CIS. With these updates, some larger changes have been made. I have these changes/updates outlined below. Testing:

  1. CI/CD - We have implemented some automated testing pipelines to test pull requests into the devel and main branches. With the current workflow, the community will PR into the devel branch (never the main branch) for review by the administrators. When your PR is created, the first check will remain the DCO check. The second check is a functional testing pipeline that will automatically perform a functional test of the branch the PR is initiated from. Once both tests pass, someone from the Administrator Team will review the changes and merge them into the devel branch. From there, an additional review is completed before the devel branch is merged into the main branch. Only the Admin Team will perform PRs/merges into the main branch. There is also an automated pipeline for PRs from devel to main. Please do not edit the .github/workflows files since those are used as part of the pipeline.
  2. Compliance Checking – MindPoint Group has been working to create our own compliance audit scan tool. The tool uses a goss framework executable to run custom checks that we have created. The goal is to provide a more thorough check for control compliance and decrease the number of false positives/negatives. For example, it will check the configuration file related to the control and as well as checking if that configuration is active. With a smarter scan, we can hopefully identify attempts to trick scanners as well (for example stacking a parameter in a config file where the first instance is enabled and second disabled. Most audit tools search for the first instance but the application might look for the last instance of the parameter, thus making the scanning tool think it's enabled). In testing, we have found that our audit scan runs significantly faster than other audit tools, reducing audit times. Our audit tool and profiles will have their own repositories in the Ansible-Lockdown org, but within the remediation role there will be an integrated way to incorporate the audit. Keep an eye out for the audit tools as they are released. We plan on developing a goss audit profile for each current remediation role. Going forward, we plan to release a remediation role and goss audit tool profile simultaneously. Role Updates:
  3. RHEL 7 STIG/CIS – We have re-written much of the RHEL 7 STIG and CIS roles to increase clarity and readability and address some functionality items. We performed these updates while creating our goss testing framework for each of these roles. We plan on pushing our update to the devel and main branches. We will move the current devel and master branches to a develstable and masterstable branch in the respective repositories. Accordingly, community members who rely on the current version can still use that version going forward; this process will not remove what is currently there. The latest versions of the roles have also been updated to comply with the latest benchmarks.
  4. Role Architecture – All roles will change with regard to the structure in the tasks folder. Taking CIS as an example, there will be a folder per section and yaml files for each sub-section. For example control 1.2.1 in CIS will be located in RHEL7-CIS/tasks/section_1/cis_1.2.x.yml. The cis_1.2.x.yml file will contain all controls related to section 1.2.x. This will hopefully make updates to roles a bit easier with less risk. This matches the architecture of our audit tool, creating consistency across remediation and audit platforms. The end goal is to repeat this architecture (the best we can) on STIG roles, but we are starting with CIS.
  5. Existing PRs and Issues – With all of these changes comes the task of cleaning up existing PR’s and issues. Our plan is to close all of the existing PR’s and issues because of the re-work. Our team is growing and should be able to stay on top of the new issues and PRs as they come in. Again, I would like to thank the community for your involvement in this project. The input and work from the community has contributed significantly to the success of this project. Please keep an eye out for these changes, which will be rolling out in the coming weeks.