Hello,
I think there is a problem in the SSG content. I think that the current content is intended to check the system configuration. This would be done by examining the files on disk to warn about changes or thing that are misconfigured. There is also another category of testing that is forensics which checks the ephemeral / current values being enforced. Both are necessary and useful, but they should not be mixed.
Some examples to illustrate the point:
Forensic Configuration ----------------------------------------------------------------- auditctl -l vs cat /etc/audit/audit.rules mount vs cat /etc/fstab sysctl -a vs cat/etc/sysctl.conf service ip6tables status vs chkconfig ip6tables --list
All these need to be changed in the prose to better express what the SCAP tool is actually checking. IOW, you can get different results by hand than the tool itself would report.
This really needs to be addressed before anyone else uses SSG as the basis of their own recommendations. Again, forensic checking is useful and I would say content should be specifically designed with that in mind. But it is not what should be in a baseline.
Thanks, -Steve
On 10/31/14, 10:31 AM, Steve Grubb wrote:
Hello,
I think there is a problem in the SSG content. I think that the current content is intended to check the system configuration. This would be done by examining the files on disk to warn about changes or thing that are misconfigured. There is also another category of testing that is forensics which checks the ephemeral / current values being enforced. Both are necessary and useful, but they should not be mixed.
Some examples to illustrate the point:
Forensic Configuration
auditctl -l vs cat /etc/audit/audit.rules mount vs cat /etc/fstab sysctl -a vs cat/etc/sysctl.conf service ip6tables status vs chkconfig ip6tables --list
All these need to be changed in the prose to better express what the SCAP tool is actually checking. IOW, you can get different results by hand than the tool itself would report.
Emphatically agree there needs to be better separation. Thanks for starting the discussion.
The auditctl usage in OCIL vs the regex on audit.rules in OVAL is a perfect example of this (which was patched earlier this week btw).
I've opened tickets to track mount vs fstab, sysctl, and service vs chkconfig:
"persistent vs runtime in OVAL+OCIL for mount checks" https://github.com/OpenSCAP/scap-security-guide/issues/320
"persistent vs runtime in OVAL+OCIL for sysctl checks" https://github.com/OpenSCAP/scap-security-guide/issues/321
"persistent vs runtime in OVAL+OCIL for service/chkconfig" https://github.com/OpenSCAP/scap-security-guide/issues/322
As/if you identify additional sections which need better separation, please bring them to our attention!
This really needs to be addressed before anyone else uses SSG as the basis of their own recommendations. Again, forensic checking is useful and I would say content should be specifically designed with that in mind. But it is not what should be in a baseline.
That's a bit strong of language. SSG represents a catalog of controls, from which agencies make selections for formal baselines that we turn into profiles. Often (e.g. with the STIG) the agency wishes to include capabilities for static/persistent configuration (e.g. sysctl.conf) *and* ephemeral system state (sysctl -a).
On Friday, October 31, 2014 10:47:37 AM Shawn Wells wrote:
On 10/31/14, 10:31 AM, Steve Grubb wrote:
I think there is a problem in the SSG content. I think that the current content is intended to check the system configuration. This would be done by examining the files on disk to warn about changes or thing that are misconfigured. There is also another category of testing that is forensics which checks the ephemeral / current values being enforced. Both are necessary and useful, but they should not be mixed.
<snip>
I've opened tickets to track mount vs fstab, sysctl, and service vs chkconfig:
Thanks!
As/if you identify additional sections which need better separation, please bring them to our attention!
Well, in a very brief look, the selinux label check in /dev is wrong, it should be:
find /dev -context *:device_t:* ( -type c -o -type b )
I think the guide should get a thorough review.
This really needs to be addressed before anyone else uses SSG as the basis of their own recommendations. Again, forensic checking is useful and I would say content should be specifically designed with that in mind. But it is not what should be in a baseline.
That's a bit strong of language. SSG represents a catalog of controls, from which agencies make selections for formal baselines that we turn into profiles. Often (e.g. with the STIG) the agency wishes to include capabilities for static/persistent configuration (e.g. sysctl.conf) *and* ephemeral system state (sysctl -a).
In retrospect, I agree. I am concerned that people not with a strong Linux background don't grok the difference or perhaps learn the wrong thing.
-Steve
On 10/31/14, 10:55 AM, Steve Grubb wrote:
On Friday, October 31, 2014 10:47:37 AM Shawn Wells wrote:
On 10/31/14, 10:31 AM, Steve Grubb wrote:
I think there is a problem in the SSG content. I think that the current content is intended to check the system configuration. This would be done by examining the files on disk to warn about changes or thing that are misconfigured. There is also another category of testing that is forensics which checks the ephemeral / current values being enforced. Both are necessary and useful, but they should not be mixed.
<snip>
I've opened tickets to track mount vs fstab, sysctl, and service vs chkconfig:
Thanks!
As/if you identify additional sections which need better separation, please bring them to our attention!
Well, in a very brief look, the selinux label check in /dev is wrong, it should be:
find /dev -context *:device_t:* ( -type c -o -type b )
https://github.com/OpenSCAP/scap-security-guide/pull/324
I think the guide should get a thorough review.
So... do one :) A solid read through by someone like yourself would be huge in identifying gaps. Patches would be great, or even an EMailed punch list would work well to get things done. Totally realize that a read through of the entire document would be cumbersome -- would you be willing to review perhaps just the audit section?
From time to time many do read the guide top-to-bottom, and I know Jeff
Blank has been working on a read-through for awhile in prep for the NSA RHEL6 SNAC Guide (still waiting, Jeff.....)
This really needs to be addressed before anyone else uses SSG as the basis of their own recommendations. Again, forensic checking is useful and I would say content should be specifically designed with that in mind. But it is not what should be in a baseline.
That's a bit strong of language. SSG represents a catalog of controls, from which agencies make selections for formal baselines that we turn into profiles. Often (e.g. with the STIG) the agency wishes to include capabilities for static/persistent configuration (e.g. sysctl.conf) *and* ephemeral system state (sysctl -a).
In retrospect, I agree. I am concerned that people not with a strong Linux background don't grok the difference or perhaps learn the wrong thing.
That's a shared concern. Many only engage with a single profile.... really the STIG since it's the most matured and widely used. As other profiles mature (e.g. USGCB) we may be able to clearly show users multiple options and perspectives. The C2S (representing a commercial baseline) somewhat levels out from the STIG.
----- Original Message -----
From: "Steve Grubb" sgrubb@redhat.com To: scap-security-guide@lists.fedorahosted.org Sent: Friday, October 31, 2014 3:55:29 PM Subject: Re: Configuration testing vs Forensic testing
On Friday, October 31, 2014 10:47:37 AM Shawn Wells wrote:
On 10/31/14, 10:31 AM, Steve Grubb wrote:
I think there is a problem in the SSG content. I think that the current content is intended to check the system configuration. This would be done by examining the files on disk to warn about changes or thing that are misconfigured. There is also another category of testing that is forensics which checks the ephemeral / current values being enforced. Both are necessary and useful, but they should not be mixed.
<snip>
I've opened tickets to track mount vs fstab, sysctl, and service vs chkconfig:
Thanks!
As/if you identify additional sections which need better separation, please bring them to our attention!
Well, in a very brief look, the selinux label check in /dev is wrong, it should be:
find /dev -context *:device_t:* ( -type c -o -type b )
Just out-of-curiosity this doesn't seem to be working properly (or I am missing something obvious) [*]. E.g. sample output from RHEL-6 system:
[root@localhost ~]# cat /etc/redhat-release Red Hat Enterprise Linux Server release 6.6 (Santiago) [root@localhost ~]# ls -Z /dev/null crw-rw-rw-. root root system_u:object_r:null_device_t:s0 /dev/null [root@localhost ~]# chcon -t samba_share_t /dev/null [root@localhost ~]# ls -Z /dev/null crw-rw-rw-. root root system_u:object_r:samba_share_t:s0 /dev/null [root@localhost ~]# find /dev -context *:device_t:* ( -type c -o -type b ) [root@localhost ~]# find /dev -context *:device_t:* ( -type c -o -type b ) | wc -l 0
Shouldn't it be changed to e.g.:
find /dev ! -context *:*device_t:* ( -type c -o -type b )
to get the list of devices that are not of :*_device_t: target?
Wondering, because while trying the changed form, getting (/dev/zero has been changed before this cut&paste output yet):
[root@localhost ~]# find /dev ! -context *:*device_t:* ( -type c -o -type b ) /dev/mapper/control /dev/btrfs-control /dev/pts/3 /dev/pts/2 /dev/pts/1 /dev/pts/0 /dev/pts/ptmx /dev/ptmx /dev/tty /dev/snapshot /dev/zero /dev/null
[root@localhost ~]# ls -Z /dev/mapper/control crw-rw----. root root system_u:object_r:lvm_control_t:s0 /dev/mapper/control
And related with that (since looks there might be properly labeled devices out of *_device_t target) wondering why not to check for 'unlabeled_t' directly?
E.g. perform something like:?
find /dev -context *:unlabeled_t:* ( -type c -o -type b )
Thank you && Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team
[*] Maybe above command quote has been provided just as an example that it should be replaced with 'find ...' command instead of 'ls -Z | grep' commands couple, but there's pull request quoting it directly: https://github.com/OpenSCAP/scap-security-guide/pull/324/files
I think the guide should get a thorough review.
This really needs to be addressed before anyone else uses SSG as the basis of their own recommendations. Again, forensic checking is useful and I would say content should be specifically designed with that in mind. But it is not what should be in a baseline.
That's a bit strong of language. SSG represents a catalog of controls, from which agencies make selections for formal baselines that we turn into profiles. Often (e.g. with the STIG) the agency wishes to include capabilities for static/persistent configuration (e.g. sysctl.conf) *and* ephemeral system state (sysctl -a).
In retrospect, I agree. I am concerned that people not with a strong Linux background don't grok the difference or perhaps learn the wrong thing.
-Steve
SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
On Friday, October 31, 2014 12:51:04 PM Jan Lieskovsky wrote:
----- Original Message -----
From: "Steve Grubb" sgrubb@redhat.com To: scap-security-guide@lists.fedorahosted.org Sent: Friday, October 31, 2014 3:55:29 PM Subject: Re: Configuration testing vs Forensic testing
On Friday, October 31, 2014 10:47:37 AM Shawn Wells wrote:
On 10/31/14, 10:31 AM, Steve Grubb wrote:
I think there is a problem in the SSG content. I think that the current content is intended to check the system configuration. This would be done by examining the files on disk to warn about changes or thing that are misconfigured. There is also another category of testing that is forensics which checks the ephemeral / current values being enforced. Both are necessary and useful, but they should not be mixed.
<snip>
I've opened tickets to track mount vs fstab, sysctl, and service vs
chkconfig:
Thanks!
As/if you identify additional sections which need better separation, please bring them to our attention!
Well, in a very brief look, the selinux label check in /dev is wrong, it should be:
find /dev -context *:device_t:* ( -type c -o -type b )
Just out-of-curiosity this doesn't seem to be working properly (or I am missing something obvious) [*]. E.g. sample output from RHEL-6 system:
Something got snipped. Should have been:
find /dev -context *:device_t:* ( -type c -o -type b ) -printf "%p %Z\n"
[root@localhost ~]# cat /etc/redhat-release Red Hat Enterprise Linux Server release 6.6 (Santiago) [root@localhost ~]# ls -Z /dev/null crw-rw-rw-. root root system_u:object_r:null_device_t:s0 /dev/null [root@localhost ~]# chcon -t samba_share_t /dev/null [root@localhost ~]# ls -Z /dev/null crw-rw-rw-. root root system_u:object_r:samba_share_t:s0 /dev/null [root@localhost ~]# find /dev -context *:device_t:* ( -type c -o -type b ) [root@localhost ~]# find /dev -context *:device_t:* ( -type c -o -type b ) | wc -l 0
Shouldn't it be changed to e.g.:
find /dev ! -context *:*device_t:* ( -type c -o -type b )
to get the list of devices that are not of :*_device_t: target?
device_t is the default when selinux knows nothing about the device. You want your system to have none of these.
-Steve
----- Original Message -----
From: "Steve Grubb" sgrubb@redhat.com To: scap-security-guide@lists.fedorahosted.org Cc: "Jan Lieskovsky" jlieskov@redhat.com Sent: Friday, October 31, 2014 6:08:00 PM Subject: Re: Configuration testing vs Forensic testing
On Friday, October 31, 2014 12:51:04 PM Jan Lieskovsky wrote:
----- Original Message -----
From: "Steve Grubb" sgrubb@redhat.com To: scap-security-guide@lists.fedorahosted.org Sent: Friday, October 31, 2014 3:55:29 PM Subject: Re: Configuration testing vs Forensic testing
On Friday, October 31, 2014 10:47:37 AM Shawn Wells wrote:
On 10/31/14, 10:31 AM, Steve Grubb wrote:
I think there is a problem in the SSG content. I think that the current content is intended to check the system configuration. This would be done by examining the files on disk to warn about changes or thing that are misconfigured. There is also another category of testing that is forensics which checks the ephemeral / current values being enforced. Both are necessary and useful, but they should not be mixed.
<snip>
I've opened tickets to track mount vs fstab, sysctl, and service vs
chkconfig:
Thanks!
As/if you identify additional sections which need better separation, please bring them to our attention!
Well, in a very brief look, the selinux label check in /dev is wrong, it should be:
find /dev -context *:device_t:* ( -type c -o -type b )
Just out-of-curiosity this doesn't seem to be working properly (or I am missing something obvious) [*]. E.g. sample output from RHEL-6 system:
Something got snipped. Should have been:
find /dev -context *:device_t:* ( -type c -o -type b ) -printf "%p %Z\n"
Thank you. This works fine.
[root@localhost ~]# cat /etc/redhat-release Red Hat Enterprise Linux Server release 6.6 (Santiago) [root@localhost ~]# ls -Z /dev/null crw-rw-rw-. root root system_u:object_r:null_device_t:s0 /dev/null [root@localhost ~]# chcon -t samba_share_t /dev/null [root@localhost ~]# ls -Z /dev/null crw-rw-rw-. root root system_u:object_r:samba_share_t:s0 /dev/null [root@localhost ~]# find /dev -context *:device_t:* ( -type c -o -type b ) [root@localhost ~]# find /dev -context *:device_t:* ( -type c -o -type b ) | wc -l 0
Shouldn't it be changed to e.g.:
find /dev ! -context *:*device_t:* ( -type c -o -type b )
to get the list of devices that are not of :*_device_t: target?
device_t is the default when selinux knows nothing about the device. You want your system to have none of these.
Yes. Confirmed by creating symlink to /dev/null & checking SELinux target of that new link.
Thanks a lot!
Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team
-Steve
On 10/31/14, 1:34 PM, Jan Lieskovsky wrote:
----- Original Message -----
From: "Steve Grubb" sgrubb@redhat.com To: scap-security-guide@lists.fedorahosted.org Cc: "Jan Lieskovsky" jlieskov@redhat.com Sent: Friday, October 31, 2014 6:08:00 PM Subject: Re: Configuration testing vs Forensic testing
On Friday, October 31, 2014 12:51:04 PM Jan Lieskovsky wrote:
----- Original Message -----
> From: "Steve Grubb" sgrubb@redhat.com > To: scap-security-guide@lists.fedorahosted.org > Sent: Friday, October 31, 2014 3:55:29 PM > Subject: Re: Configuration testing vs Forensic testing > > On Friday, October 31, 2014 10:47:37 AM Shawn Wells wrote: > > > On 10/31/14, 10:31 AM, Steve Grubb wrote: > > > > > I think there is a problem in the SSG content. I think that the > > > > > current > > > > > content is intended to check the system configuration. This would be > > > > > done > > > > > by examining the files on disk to warn about changes or thing that > > > > > are > > > > > misconfigured. There is also another category of testing that is > > > > > forensics which checks the ephemeral / current values being enforced. > > > > > Both are necessary and useful, but they should not be mixed. > > <snip> > > > > I've opened tickets to track mount vs fstab, sysctl, and service vs > > > > chkconfig: > Thanks! > > > > As/if you identify additional sections which need better separation, > > > please bring them to our attention! > > Well, in a very brief look, the selinux label check in /dev is wrong, it > should be: > > find /dev -context *:device_t:* ( -type c -o -type b )
Just out-of-curiosity this doesn't seem to be working properly (or I am missing something obvious) [*]. E.g. sample output from RHEL-6 system:
Something got snipped. Should have been:
find /dev -context *:device_t:* ( -type c -o -type b ) -printf "%p %Z\n"
Thank you. This works fine.
[root@localhost ~]# cat /etc/redhat-release Red Hat Enterprise Linux Server release 6.6 (Santiago) [root@localhost ~]# ls -Z /dev/null crw-rw-rw-. root root system_u:object_r:null_device_t:s0 /dev/null [root@localhost ~]# chcon -t samba_share_t /dev/null [root@localhost ~]# ls -Z /dev/null crw-rw-rw-. root root system_u:object_r:samba_share_t:s0 /dev/null [root@localhost ~]# find /dev -context *:device_t:* ( -type c -o -type b ) [root@localhost ~]# find /dev -context *:device_t:* ( -type c -o -type b ) | wc -l 0
Shouldn't it be changed to e.g.:
find /dev ! -context *:*device_t:* ( -type c -o -type b )
to get the list of devices that are not of :*_device_t: target?
device_t is the default when selinux knows nothing about the device. You want your system to have none of these.
Yes. Confirmed by creating symlink to /dev/null & checking SELinux target of that new link.
Updated patch submission on github.
Agreed that things need to be split out a bit more. We check both when able because of various customer requirements. We filled in the gaps with some home grown / COTS tools as part of our continuous monitoring program to check for ³both states² again depending on requirements.
That said I do believe it also comes down to what is required by those using / checking the tools / systems. I have had various DoD C&A teams check only config files during the manual validation, some checked running configurations, others checked a combination depending which STIG checklist they had in front of them. There is very rarely any consistency.
At other agencies like DHS where USGCB is required and their version of ³continuous monitoring² is coming via Continuous Diagnostics & Mitigation (CDM) may force the need to accelerate splitting these apart as "both states" will be relevant per their Configuration Management (CM) requirement. Please keep in mind that in original CDM RFP its not necessarily realtime. There was a 72 hour notification requirement written into the original CDM CMaaS RFP as part of the Sample Order. That was before Task Order 2a & 2B were released. That window may have changed a bit.
Now that I went on a bit of a rant, it is applicable across the board whether in DoD, IC, DHS, etc. I guess I was making the case for the larger applicability of splitting it out.
Chris Kachigian
On 10/31/14, 10:47 AM, "Shawn Wells" shawn@redhat.com wrote:
On 10/31/14, 10:31 AM, Steve Grubb wrote:
Hello,
I think there is a problem in the SSG content. I think that the current content is intended to check the system configuration. This would be done by examining the files on disk to warn about changes or thing that are misconfigured. There is also another category of testing that is forensics which checks the ephemeral / current values being enforced. Both are necessary and useful, but they should not be mixed.
Some examples to illustrate the point:
Forensic Configuration
auditctl -l vs cat /etc/audit/audit.rules mount vs cat /etc/fstab sysctl -a vs cat/etc/sysctl.conf service ip6tables status vs chkconfig ip6tables --list
All these need to be changed in the prose to better express what the SCAP tool is actually checking. IOW, you can get different results by hand than the tool itself would report.
Emphatically agree there needs to be better separation. Thanks for starting the discussion.
The auditctl usage in OCIL vs the regex on audit.rules in OVAL is a perfect example of this (which was patched earlier this week btw).
I've opened tickets to track mount vs fstab, sysctl, and service vs chkconfig:
"persistent vs runtime in OVAL+OCIL for mount checks" https://github.com/OpenSCAP/scap-security-guide/issues/320
"persistent vs runtime in OVAL+OCIL for sysctl checks" https://github.com/OpenSCAP/scap-security-guide/issues/321
"persistent vs runtime in OVAL+OCIL for service/chkconfig" https://github.com/OpenSCAP/scap-security-guide/issues/322
As/if you identify additional sections which need better separation, please bring them to our attention!
This really needs to be addressed before anyone else uses SSG as the basis of their own recommendations. Again, forensic checking is useful and I would say content should be specifically designed with that in mind. But it is not what should be in a baseline.
That's a bit strong of language. SSG represents a catalog of controls, from which agencies make selections for formal baselines that we turn into profiles. Often (e.g. with the STIG) the agency wishes to include capabilities for static/persistent configuration (e.g. sysctl.conf)
*and* ephemeral system state (sysctl -a).
SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
Hello,
On Monday, November 03, 2014 09:15:52 PM Kachigian, Christopher R wrote:
Agreed that things need to be split out a bit more. We check both when able because of various customer requirements. We filled in the gaps with some home grown / COTS tools as part of our continuous monitoring program to check for ³both states² again depending on requirements.
Thanks for your insight. But since I stirred the pot, I probably should elaborate a bit more. Baselines really are about the configuration for next boot. What I noticed was that the recommended *manual* checks were different from what I know the SCAP scanner is looking at. Ideally, manual checks should produce the exact same results as the automated tools. Chances are they produce the same results, but in a particular case the format of a tool's output changed causing people grief that is unfortunate.
That said, I think there is room for the creation of content specifically looking for the fleeting / ephemeral values - just in case. The main issue is that OVAL doesn't always support this. There is no OVAL equivalent to auditctl -l, services iptables status, or sysctl -a.
I've mentioned before to the OVAL editorial board that if I could do it over again, I'd want to be more careful about combining in-memory checks and on- disk checks. An example of this might be the partition check which is an amalgamation of both. I would prefer a pure on-disk and in-memory separation...but its too late.
The only way that forensic scanning can be done is to avoid OVAL in the XCCDF and just use a shell script/app or even better use the SCE interface.
Anyways, hope this clears up my thoughts. Its more a case of manual != automated tests in a few cases. By and large they do match.
Thanks, -Steve
Hello Shawn, Steve, folks,
I am going to reopen this thread since (I think) the previous discussion didn't went to conclusion: [1] https://github.com/OpenSCAP/scap-security-guide/issues/320
(agreement on the design concept how this change should be implemented isn't known yet).
----- Original Message -----
From: "Shawn Wells" shawn@redhat.com To: scap-security-guide@lists.fedorahosted.org Sent: Friday, October 31, 2014 3:47:37 PM Subject: Re: Configuration testing vs Forensic testing
On 10/31/14, 10:31 AM, Steve Grubb wrote:
Hello,
I think there is a problem in the SSG content. I think that the current content is intended to check the system configuration. This would be done by examining the files on disk to warn about changes or thing that are misconfigured. There is also another category of testing that is forensics which checks the ephemeral / current values being enforced. Both are necessary and useful, but they should not be mixed.
Some examples to illustrate the point:
Forensic Configuration
auditctl -l vs cat /etc/audit/audit.rules mount vs cat /etc/fstab sysctl -a vs cat/etc/sysctl.conf service ip6tables status vs chkconfig ip6tables --list
All these need to be changed in the prose to better express what the SCAP tool is actually checking. IOW, you can get different results by hand than the tool itself would report.
Emphatically agree there needs to be better separation. Thanks for starting the discussion.
The auditctl usage in OCIL vs the regex on audit.rules in OVAL is a perfect example of this (which was patched earlier this week btw).
I've opened tickets to track mount vs fstab, sysctl, and service vs chkconfig:
"persistent vs runtime in OVAL+OCIL for mount checks" https://github.com/OpenSCAP/scap-security-guide/issues/320
"persistent vs runtime in OVAL+OCIL for sysctl checks" https://github.com/OpenSCAP/scap-security-guide/issues/321
"persistent vs runtime in OVAL+OCIL for service/chkconfig" https://github.com/OpenSCAP/scap-security-guide/issues/322
As/if you identify additional sections which need better separation, please bring them to our attention!
First let me summary that: * it's great we agreed on the need to separate configuration vs runtime checks, * we identified the areas which needs fixing.
But obvious question being what level of separation is required: * 1) IOW should each existing rule be turned into a new group, consisting of two rules - one for configuration testing, one for runtime testing. Then the description of the group would be more generalized form of the check, where each of the two new rules would be described according to the way they perform the check - IOW the configuration one would mention checking configuration files, while the runtime one would focus on system actions checking runtime state, * 2) or is it sufficient to mention in the (HTML version of the guide) that the current implementation checks just configuration status (AND the runtime state where appropriate) and basically do no changes in current XCCDF / OVAL rules implementation, * 3) another options / possibility (as pointed out by Simon Lukasik - thanks for it!) is the following - modify the current rules implementation in the way to keep the configuration tests the default ones (IOW when they don't pass the check would fail) and simultaneously make the runtime checks the optional ones. The content user would be able via e.g. an OVAL variable to instruct the scanner what kind of testing should be performed.
Example:
"Check system property" rule if ($runtime_check) not set then check just configuration settings else check configuration settings check runtime settings fi
And analogous approach (same global OVAL variable) customizable by the SCAP content user would be used for all rules.
* 4) another option (but maybe just enhancement of case 1)) is to follow the way to have two dedicated profiles for each of the existing ones (e.g. USGCB-configuration and USGCB-runtime) each of them containing rules from particular category.
* 5) another option is to use "runtime / configuration" (or both of them) as suffix in the rule title - so for example: -- existing "Install Aide" rule would become "Install Aide (runtime)"
meaning here just runtime check would be performed, while e.g.
-- existing "Disable the Automounter" would become "Disable the Automounter (configuration, runtime)"
meaning in this case both configuration & runtime checks were performed.
In my opinion we first need to agree on the way how the separation should be performed in order to: * this separation to be sufficiently clear enough for the content consumers * we don't need to change the approach during its implementation (during updating actual state to reflect the expectations)
Should I vote for some of the aforementioned approaches to select one I prefer the global OVAL variable approach. E.g. the following:
* Update existing XCCDF rules description to mention / describe only configuration checks, * Update OVAL checks to perform just configuration testing by default, * Add new global OVAL variable ($runtime_check for example) to instruct the content, that in case this variable is defined, the optional runtime checks should be performed too.
Yet another possibility - taking the variable approach even to yet more / wider extent, there could be two of them: * $configuration * $runtime
and the content would perform checks (and maybe also remediations / corrections) based on the actual user setting / preference. E.g. in case $configuration would be defined, it would perform just system configuration checking & configuration corrections. With $runtime defined it would check & correct (just) runtime state.
The default setting then would be to use (check & correct) the $configuration setting(s).
Comments, opinions, feedback welcome.
Thank you && Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team
This really needs to be addressed before anyone else uses SSG as the basis of their own recommendations. Again, forensic checking is useful and I would say content should be specifically designed with that in mind. But it is not what should be in a baseline.
That's a bit strong of language. SSG represents a catalog of controls, from which agencies make selections for formal baselines that we turn into profiles. Often (e.g. with the STIG) the agency wishes to include capabilities for static/persistent configuration (e.g. sysctl.conf)
*and* ephemeral system state (sysctl -a).
SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
Hello,
TL;DR - OVAL is limited in its capabilities. The prose must match what OVAL can do.
On Tuesday, December 16, 2014 10:18:32 AM Jan Lieskovsky wrote:
First let me summary that:
- it's great we agreed on the need to separate configuration vs runtime checks,
- we identified the areas which needs fixing.
But obvious question being what level of separation is required:
of two rules - one for configuration testing, one for runtime testing. Then the description of the group would be more generalized form of the check, where each of the two new rules would be described according to the way they perform the check - IOW the configuration one would
- IOW should each existing rule be turned into a new group, consisting
mention checking configuration files, while the runtime one would focus on system actions checking runtime state,
Security guides are always about how to set the system up so that it boots into the correct configuration. Checking for deviations in enforcement is sometimes covered, but usually not. There is a little used category of APT that is Tier III and mostly Windows content. This is the category where that kind of content belongs. IOW, its not STIG or USGCB or PCI.
Content like a STIG or USGCB is supposed to be a baseline which is all about how the system boots up. Its content should be pretty slow moving. The APT category on the other hand is for faster moving guidance on new threats.
- or is it sufficient to mention in the (HTML version of the guide) that
the current implementation checks just configuration status (AND the runtime state where appropriate) and basically do no changes in current XCCDF / OVAL rules implementation,
- another options / possibility (as
pointed out by Simon Lukasik - thanks for it!) is the following - modify the current rules implementation in the way to keep the configuration tests the default ones (IOW when they don't pass the check would fail) and simultaneously make the runtime checks the optional ones. The content user would be able via e.g. an OVAL variable to instruct the scanner what kind of testing should be performed.
Example:
"Check system property" rule if ($runtime_check) not set then check just configuration settings else check configuration settings check runtime settings fiAnd analogous approach (same global OVAL variable) customizable by the SCAP content user would be used for all rules.
We should not be mixing the two use cases. STIG and USGCB should be the on- disk configuration.
- another option (but maybe just enhancement of case 1)) is to follow the
way to have two dedicated profiles for each of the existing ones (e.g. USGCB-configuration and USGCB-runtime) each of them containing rules from particular category.
This would be better. But the Forensic case is not an immediate goal or need. Its more in the nice to have category. In my view, the content right now should only be the on-disk configuration. The prose should reflect how to test manually in the same way as the SCAP scanner will. Meaning, if the OVAL check is a filecontent_test, then the prose should use cat + grep or awk.
The fact is that you cannot check the in memory configuration via OVAL for several things. You can by going to XCCDF and using scripting instead of OVAL. But this is already a stretch. The intention is to use regular OVAL mechanisms and then make the prose reflect the same test that the scanners will perform.
- another option is to use "runtime / configuration" (or both of them) as
suffix in the rule title - so for example: -- existing "Install Aide" rule would become "Install Aide (runtime)"
meaning here just runtime check would be performed, while e.g. -- existing "Disable the Automounter" would become "Disable theAutomounter (configuration, runtime)"
meaning in this case both configuration & runtime checks wereperformed.
In my opinion we first need to agree on the way how the separation should be performed in order to:
- this separation to be sufficiently clear enough for the content consumers
- we don't need to change the approach during its implementation (during updating actual state to reflect the expectations)
Should I vote for some of the aforementioned approaches to select one I prefer the global OVAL variable approach. E.g. the following:
- Update existing XCCDF rules description to mention / describe only
configuration checks,
The prose must match exactly how OVAL tests it.Otherwise you will get differences.
- Update OVAL checks to perform just configuration testing by default,
This is what they should be doing. Many of the issues I mentioned in the original email was because the prose did not match the OVAL checks. OVAL has limited capabilities. It cannot run auditctl or mount or any other external command. So, the prose need to reflect this limitation and be accurate so that people without a scanner can test by hand and get accurate results. That is the main issue I was reporting.
-Steve
----- Original Message -----
From: "Steve Grubb" sgrubb@redhat.com To: "Jan Lieskovsky" jlieskov@redhat.com Cc: "SCAP Security Guide" scap-security-guide@lists.fedorahosted.org Sent: Tuesday, December 16, 2014 5:20:23 PM Subject: Re: Configuration testing vs Forensic testing
Hello,
TL;DR - OVAL is limited in its capabilities. The prose must match what OVAL can do.
On Tuesday, December 16, 2014 10:18:32 AM Jan Lieskovsky wrote:
First let me summary that:
- it's great we agreed on the need to separate configuration vs runtime checks,
- we identified the areas which needs fixing.
But obvious question being what level of separation is required:
of two rules - one for configuration testing, one for runtime testing. Then the description of the group would be more generalized form of the check, where each of the two new rules would be described according to the way they perform the check - IOW the configuration one would
- IOW should each existing rule be turned into a new group, consisting
mention checking configuration files, while the runtime one would focus on system actions checking runtime state,
Security guides are always about how to set the system up so that it boots into the correct configuration. Checking for deviations in enforcement is sometimes covered, but usually not. There is a little used category of APT that is Tier III and mostly Windows content. This is the category where that kind of content belongs. IOW, its not STIG or USGCB or PCI.
Content like a STIG or USGCB is supposed to be a baseline which is all about how the system boots up. Its content should be pretty slow moving. The APT category on the other hand is for faster moving guidance on new threats.
- or is it sufficient to mention in the (HTML version of the guide) that
the current implementation checks just configuration status (AND the runtime state where appropriate) and basically do no changes in current XCCDF / OVAL rules implementation,
- another options / possibility (as
pointed out by Simon Lukasik - thanks for it!) is the following - modify the current rules implementation in the way to keep the configuration tests the default ones (IOW when they don't pass the check would fail) and simultaneously make the runtime checks the optional ones. The content user would be able via e.g. an OVAL variable to instruct the scanner what kind of testing should be performed.
Example:
"Check system property" rule if ($runtime_check) not set then check just configuration settings else check configuration settings check runtime settings fiAnd analogous approach (same global OVAL variable) customizable by the SCAP content user would be used for all rules.
We should not be mixing the two use cases. STIG and USGCB should be the on- disk configuration.
- another option (but maybe just enhancement of case 1)) is to follow
the way to have two dedicated profiles for each of the existing ones (e.g. USGCB-configuration and USGCB-runtime) each of them containing rules from particular category.
This would be better. But the Forensic case is not an immediate goal or need. Its more in the nice to have category. In my view, the content right now should only be the on-disk configuration. The prose should reflect how to test manually in the same way as the SCAP scanner will. Meaning, if the OVAL check is a filecontent_test, then the prose should use cat + grep or awk.
The fact is that you cannot check the in memory configuration via OVAL for several things. You can by going to XCCDF and using scripting instead of OVAL. But this is already a stretch. The intention is to use regular OVAL mechanisms and then make the prose reflect the same test that the scanners will perform.
- another option is to use "runtime / configuration" (or both of them)
as suffix in the rule title - so for example: -- existing "Install Aide" rule would become "Install Aide (runtime)"
meaning here just runtime check would be performed, while e.g. -- existing "Disable the Automounter" would become "Disable theAutomounter (configuration, runtime)"
meaning in this case both configuration & runtime checks wereperformed.
In my opinion we first need to agree on the way how the separation should be performed in order to:
- this separation to be sufficiently clear enough for the content consumers
- we don't need to change the approach during its implementation (during updating actual state to reflect the expectations)
Should I vote for some of the aforementioned approaches to select one I prefer the global OVAL variable approach. E.g. the following:
- Update existing XCCDF rules description to mention / describe only
configuration checks,
The prose must match exactly how OVAL tests it.Otherwise you will get differences.
- Update OVAL checks to perform just configuration testing by default,
This is what they should be doing. Many of the issues I mentioned in the original email was because the prose did not match the OVAL checks. OVAL has limited capabilities. It cannot run auditctl or mount or any other external command. So, the prose need to reflect this limitation and be accurate so that people without a scanner can test by hand and get accurate results. That is the main issue I was reporting.
Thank you for the clarification, Steve. It's clear now.
Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team
-Steve
On 12/17/14, 8:24 AM, Jan Lieskovsky wrote:
----- Original Message -----
From: "Steve Grubb" sgrubb@redhat.com To: "Jan Lieskovsky" jlieskov@redhat.com Cc: "SCAP Security Guide" scap-security-guide@lists.fedorahosted.org Sent: Tuesday, December 16, 2014 5:20:23 PM Subject: Re: Configuration testing vs Forensic testing
Hello,
TL;DR - OVAL is limited in its capabilities. The prose must match what OVAL can do.
On Tuesday, December 16, 2014 10:18:32 AM Jan Lieskovsky wrote:
First let me summary that:
- it's great we agreed on the need to separate configuration vs runtime checks,
- we identified the areas which needs fixing.
But obvious question being what level of separation is required:
of two rules - one for configuration testing, one for runtime testing. Then the description of the group would be more generalized form of the check, where each of the two new rules would be described according to the way they perform the check - IOW the configuration one would
- IOW should each existing rule be turned into a new group, consisting
mention checking configuration files, while the runtime one would focus on system actions checking runtime state,
Security guides are always about how to set the system up so that it boots into the correct configuration. Checking for deviations in enforcement is sometimes covered, but usually not. There is a little used category of APT that is Tier III and mostly Windows content. This is the category where that kind of content belongs. IOW, its not STIG or USGCB or PCI.
Content like a STIG or USGCB is supposed to be a baseline which is all about how the system boots up. Its content should be pretty slow moving. The APT category on the other hand is for faster moving guidance on new threats.
- or is it sufficient to mention in the (HTML version of the guide) that
the current implementation checks just configuration status (AND the runtime state where appropriate) and basically do no changes in current XCCDF / OVAL rules implementation,
- another options / possibility (as
pointed out by Simon Lukasik - thanks for it!) is the following - modify the current rules implementation in the way to keep the configuration tests the default ones (IOW when they don't pass the check would fail) and simultaneously make the runtime checks the optional ones. The content user would be able via e.g. an OVAL variable to instruct the scanner what kind of testing should be performed.
Example:
"Check system property" rule if ($runtime_check) not set then check just configuration settings else check configuration settings check runtime settings fiAnd analogous approach (same global OVAL variable) customizable by the SCAP content user would be used for all rules.
We should not be mixing the two use cases. STIG and USGCB should be the on- disk configuration.
- another option (but maybe just enhancement of case 1)) is to follow
the way to have two dedicated profiles for each of the existing ones (e.g. USGCB-configuration and USGCB-runtime) each of them containing rules from particular category.
This would be better. But the Forensic case is not an immediate goal or need. Its more in the nice to have category. In my view, the content right now should only be the on-disk configuration. The prose should reflect how to test manually in the same way as the SCAP scanner will. Meaning, if the OVAL check is a filecontent_test, then the prose should use cat + grep or awk.
The fact is that you cannot check the in memory configuration via OVAL for several things. You can by going to XCCDF and using scripting instead of OVAL. But this is already a stretch. The intention is to use regular OVAL mechanisms and then make the prose reflect the same test that the scanners will perform.
- another option is to use "runtime / configuration" (or both of them)
as suffix in the rule title - so for example: -- existing "Install Aide" rule would become "Install Aide (runtime)"
meaning here just runtime check would be performed, while e.g. -- existing "Disable the Automounter" would become "Disable theAutomounter (configuration, runtime)"
meaning in this case both configuration & runtime checks wereperformed.
In my opinion we first need to agree on the way how the separation should be performed in order to:
- this separation to be sufficiently clear enough for the content consumers
- we don't need to change the approach during its implementation (during updating actual state to reflect the expectations)
Should I vote for some of the aforementioned approaches to select one I prefer the global OVAL variable approach. E.g. the following:
- Update existing XCCDF rules description to mention / describe only
configuration checks,
The prose must match exactly how OVAL tests it.Otherwise you will get differences.
- Update OVAL checks to perform just configuration testing by default,
This is what they should be doing. Many of the issues I mentioned in the original email was because the prose did not match the OVAL checks. OVAL has limited capabilities. It cannot run auditctl or mount or any other external command. So, the prose need to reflect this limitation and be accurate so that people without a scanner can test by hand and get accurate results. That is the main issue I was reporting.
Thank you for the clarification, Steve. It's clear now.
To meet the US Gov's requirements, profiles like the STIG should check for *both* on-disk and runtime settings, though through different XCCDF/OVAL rules.
On Wednesday, January 07, 2015 11:03:44 AM Shawn Wells wrote:
- Update OVAL checks to perform just configuration testing by
default,
This is what they should be doing. Many of the issues I mentioned in the original email was because the prose did not match the OVAL checks. OVAL has limited capabilities. It cannot run auditctl or mount or any other external command. So, the prose need to reflect this limitation and be accurate so that people without a scanner can test by hand and get accurate results. That is the main issue I was reporting.
Thank you for the clarification, Steve. It's clear now.
To meet the US Gov's requirements, profiles like the STIG should check for *both* on-disk and runtime settings, though through different XCCDF/OVAL rules.
From the 800-70:
2.1 Security Configuration Checklists
"A security configuration checklist (also referred to as a lockdown guide, hardening guide, security guide,security technical implementation guide [STIG], or benchmark) 3 is essentially a document that contains instructions or procedures for configuring an IT product to an operational environment."
This is clearly about on disk configuration. Section 2.2 goes into more details. There is a need for Forensic checks and it has been talked about occassionally at SCAP Developer Days. But the OVAL support needed has never gotten past having some discussions. So, OVAL simply doesn't have the means to do much forensics.
Historically, the guides have also never discussed how to do one kind of check vs the other. So, this would be entirely new.
-Steve
On Wed, Jan 7, 2015 at 11:03 AM, Shawn Wells shawn@redhat.com wrote:
TL;DR - OVAL is limited in its capabilities. The prose must match what OVAL can do.
To meet the US Gov's requirements, profiles like the STIG should check for *both* on-disk and runtime settings, though through different XCCDF/OVAL rules.
I'm not convinced that XCCDF/OVAL is the right choice for general work. So far the skills to use it don't seem to be common in the people who need to get work done. However, I do agree that on-disk and run time settings should be checked. It is too easy to modify something outside an expected init file. Since we can't expect the STIG writers to know everything I'm happy with looking for the intent and following through on that.
Leam
scap-security-guide@lists.fedorahosted.org
-
Jan Lieskovsky -
Kachigian, Christopher R -
leam hall -
Shawn Wells -
Steve Grubb