Hello Henry,
On Thu, Dec 17, 2020 at 3:03 PM Link, Henry L II CTR USN NIWC ATLANTIC SC
(USA) <henry.l.link1.ctr(a)navy.mil> wrote:
Speaking for myself, such aggregation would indeed be helpful
Two other instances of such that come to mind (from the RHEL7 v3r1 STIG)
are:
RHEL-07-021030
RHEL-07-021031
Since indiscriminately changing file or directory ownership is
problematic, listing the paths for which these apply is fine, so they may
be adjudicated on a case by case basis.
Thank you for the examples, I see a subtle difference in the use case.
The STIG Items above are clear on what a finding is (a directory that is
world-writable not owned by root) and it is straightforward to identify
them in an automated manner.
I see the manual inspection as needed to distinguish between a finding that
can be waived for the deployed system or not.
In the example I gave in the previous email, about officially supported
repositories:
It can be clear what a finding is (repos not officially supported by a
distro or organization), but identifying these in an automated manner seems
tricky to me.
As there would not be a way to identify the findings, the check would
actually list all installed repos for someone to identify the findings and
adjudicate them.
In one case the manual inspection is about going through the findings and
waiving them;
the other case is about going through all concerned items, identifying
whether the item is a finding, and waving it.
With that said, I still think whether it makes sense to differentiate
between these cases. After all, they are just about listing items for human
inspection.
Someone can get confused why some rules are listing actually compliant
items for manual inspection, but proper rule description may be enough to
mitigate this.
RHEL-07-010010
Ah, the ever-beloved RHEL-07-010010.
In one particular case, the recommended fix of rpm --setperms did nothing
for one directory, /run/dbus from dbus-daemon, because the permissions for
the directory inside the rpm was flawed and resulted in an open case and
later remediation. Listing the items on which to be taken action in a
report of some kind, or even the items on which actions were taken, apart
from the default play output, would be useful. In this case, we already
have the list_of_packages, list_of_files_with_incorrect_ownership, and
list_of_files_with_incorrect_permissions vars already established, it
wouldn't be much to direct those to a flat or JSON output. (I'm undecided
about which would be more useful, the most useful being a report which
cross-referenced path, ownership, permissions, and permissions/ownership on
disk, but that might be a bit much.)
Here I take that the concern is about controlling the extent of the
remediation, the fix script doesn't care if a certain path can be
skipped/waived so that it is not reset to RPM defaults.
I guess some waving mechanism that provides info about waived items for the
remediation script would be required, but for the moment I don't dare guess
how that could be done, :)
Another point you make is about keeping track of the items on which actions
were taken.
As you mention, the easiest way to have this info would be from the output
of the Ansible playbooks, the same level of tracking would be difficult to
achieve with Bash remediations.
For that matter, a callback plugin similar to DISA's stig_xml.py would be
useful as well, which auto-generates the XCCDF content for import into a
CKL, but that might me outside the scope of this specific topic.
I'm not familiar with the script you mention, but the intention seems to be
to import evaluation results into the DISA STIG viewer.
OpenSCAP can generate XCCDF results compatible when "--stig-viewer" option
is used combined with "--results".
--Henry Link
*From:* Watson Sato <wsato(a)redhat.com>
*Sent:* Wednesday, December 16, 2020 3:50 PM
*To:* SCAP Security Guide <scap-security-guide(a)lists.fedorahosted.org>
*Subject:* [Non-DoD Source] Collecting system info with SCAP rules for
manual inspection - informational rules
Hello all,
Most of the Rules implemented in ComplianceAsCode/content
<
https://no-click.mil/?https://github.com/ComplianceAsCode/content> (if
not all of them) have been focused on checking and remediating a specific
configuration. Typically configurations that are easy to automate.
For example, ensuring that packages installed have the signature verified
is implemented by a rule checking that the repo files have "gpgcheck = 1".
But there are cases where automation is not reasonably achievable, they
would require hard coding parameters or an extensive tailoring harness for
the rule.
For example, how to ensure that configured repositories are the ones
officially supported by the distro.
In these cases the check needs to be done by some other process, maybe
manually checking the repositories enabled, or some administrative process
guarantees it.
I don't know details of the auditory nor how these non-automatable
requirements are handled.
So I wonder if an Informational Rule that would collect the data for
manual analysis would be of help.
Following the examples, this informational rule would collect the list of
repositories enabled, and present it / aggregate it somehow.
Regards,
--
*Watson Sato *
Software Engineer
Red Hat EMEA <
https://no-click.mil/?https://www.redhat.com>
[image: Image removed by sender.]
<
https://no-click.mil/?https://www.redhat.com>
_______________________________________________
scap-security-guide mailing list --
scap-security-guide(a)lists.fedorahosted.org
To unsubscribe send an email to
scap-security-guide-leave(a)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.fe...
--
Watson Sato
Software Engineer
Red Hat EMEA <
https://www.redhat.com>
<
https://www.redhat.com>