2015 Red Hat Summit: Discounted passes for SSG & OpenSCAP community members
by Shawn Wells
Hey Guys,
The 2015 Red Hat Summit (http://www.redhat.com/summit) will take
place June 23-26 in Boston. The event may seem far away, but we all know
how long it takes for integrators and govies to allocate training and
travel budgets... :)
This year we've ensured that _*any*_ member of the SSG & broader
OpenSCAP community is eligible for discounted Summit passes at $950/pass
(or $895/pass for groups of 4+). Doesn't matter if you're a code
contributor, occasional voice on the mailing lists, or silent partner.
For reference, the full conference pass is generally $1,975 (ref
http://www.redhat.com/summit/rates/).
In 2012 the SCAP session was standing room only, and in 2013 it was
rated the #3 session (out of 196 sessions) by attendees. We hope to see
you there this year!
In full transparency: I don't get any RHT kickback or commissions
off this. I received a special registration code that allows me to
empirically show various managers/event staff how much interest there is
in SCAP and Security Automation. For every 10 registrants that use the
code, I get to send a RHT engineer to Red Hat Summit.
Contact me _*off-list*_ if interested!
-sdw
9 years
securetty and hypervisor virtual consoles (hvc)
by Albrecht, Thomas C
All,
I'm having trouble determining whether to send these questions to this list or the gov-sec list. If anyone has advice, please share it with me.
That said, I'm working on updating my lockdown scripts for RHEL7 to meet the spirit of the law manifested in the RHEL6 STIG. One of the requirements in the RHEL6 STIG is that "The system must prevent the root account from logging in from virtual consoles." (Rule ID: SV-50293r1_rule)
Their solution is to remove all lines that start with "vc" from /etc/securetty. RHEL7 has introduced their hypervisor virtual consoles as "hvc". Not being as familiar with the hypervisor technology as I probably should be, is there a consensus for whether the requirement necessitates removing those lines from securetty as well?
Thanks!
Tom Albrecht
--
Tom Albrecht III, CISSP-ISSEP, GPEN
Information Assurance Engineer Staff
Cyber & Security Solutions Team (CaS2T)
Lockheed Martin Corporation, IS&GS
thomas.c.albrecht(a)lmco.com<mailto:thomas.c.albrecht@lmco.com>
(m) 484-798-0109
(w) 610-354-7424
9 years, 1 month
UX testing feedback
by Martin Preisler
Hi,
we've done a couple of test days of the SCAP tools, mainly openscap and
SCAP Workbench.
Some of the feedback we gathered is related to the SSG content and can't
be fixed in the tools. I think it could be valuable to the project to discuss
them and perhaps figure out a way to solve some of them.
I would like to thank Matt Reid and Martin Zember for providing most of the
feedback below.
1) Discoverability: It is easy to find some info about RHEL5 USGCB, the
assumption was that RHEL6 should be similar which is sadly not the case.
usgcb.nist.gov provides content for RHEL5, doesn't even mention anything
about RHEL6.
It is entirely ungooglable
- user expected to find it with: "automate usgcb linux",
"usgcb linux tool", "check linux against usgcb",
"linux security compliance", "usgcb audit linux".
- the only way to find it is to find openscap page first
and then look at related projects, unfortunately openscap
doesn't mention that scap-security-guide has USGCB...
2) Changing profile IDs: stig-rhel6-server was renamed to
stig-rhel6-server-upstream, documentation mentions stig-rhel6-server.
Why would an ID like this change?
3) Do most of the checks need to point back to "A conditional clause for
check statements"? Isn't that just a placeholder that doesn't do anything?
“A conditional clause for check statements”
Do we need to have that placeholder dropdown? Can it be customized to be
useful in some way? All the other dropdowns offer reasonable options to
select from, as well as a default option. When it says it only takes
effect when the profile is used for evaluation, does that mean when
the profile is used for scanning? What do we consider evaluating?
(very commonly asked)
4) (about Rule descriptions) This is more a content issue, but while the
information is useful that we show after expanding, I'd more expect to
see why we're running the test, and why it's important that my system
pass that test.
5) "The success of automatic remediation greatly depends on content quality
and could result in broken machines if not used carefully!" What kind of
content might break stuff? Is there any way to know beforehand that your
content might cause issues? How are machines broken?
(Talking about a disclaimer in SCAP Workbench user manual.)
My reply:
Content can do virtually anything. There is no way to tell. This disclaimer
hints that users should really trust the content before running remediation.
All bets are off, I can write SCAP content that will wipe all data upon
remediation.
Second testing round, same issue:
It also doesn't convey the potential danger that the doc mentions about
this setting, where it could break your system. How reliable is the output?
Are the times when it breaks things edge cases or somewhat common? If it
isn't very reliable, I'm not sure we should be offering the option. I'd
suggest rewording the tooltip to be "Checking this attempts to automatically
remediate failed checks when scanning. Warning: in some situations, this
could result in misconfigured values."
My reply:
Generally I refrain from making statements about the content in workbench.
This really is a question for whoever ships the content. scap-workbench
cannot make sure remediation is reliable, only content authors can.
(about remediation, this is an issue all the SCAP projects share)
6) Why does a default profile contain many service folders that are enabled,
but without any checks enabled? Shouldn't the whole thing be disabled if it
isn't going to do anything with that section and clutter up the report when
run?
My reply:
This is a content issue again. Workbench just shows what the content does.
Both approaches are valid. Disabling the group is enough but SSG opts to
disable all the rules inside and leave the group enabled.
7) Is the purpose of the Introduction folder with General Principles and How
to Use This Guide simply to have a click target that can educate users? I'm
not sure why those can be enabled/disabled, when they don't seem to affect
the scan results at all.
My reply:
Yup. In the past we did a poor job at displaying front matter, notices and
related elements. That's why content authors started to abuse Group
descriptions for this purpose. Now that we do a good job and displaying the
notices these practices still remain.
See: https://github.com/OpenSCAP/scap-security-guide/issues/357
8) It might be good to start off what I'm going to call the remediation section
(underneath Identifiers and References) to have a one sentence summary
explaining why something failed. While you can usually figure it out pretty
easily, the naming of the checks themselves and the status, without any
interpretation can be initially confusing. My Shared Library Files Have
Restrictive Permissions test failed, does that mean my library files are too
restrictive? not restrictive enough? A clear action item for how to address
the failure would be nice because the remediation section seems to always
say the same thing, regardless of a pass or fail.
(Not fixable in a generic way but maybe we can change the texts to help.)
9) Could be reworded to be more concise and clearer - On Password Minimum
Length modal details: "Nowadays recommended values, considered as secure by
various organizations focused on topic of computer security, range from 12
(FISMA) up to 14 (DoD) characters for password length requirements. If
a program consults /etc/login.defs and also another PAM module (such as
pam_cracklib) during a password change operation, then the most restrictive
must be satisfied. See PAM section for more information about enforcing
password quality requirements."
(The description is probably from an official source, not sure if we can
fix that.)
10) If there are certain rules that check for specific, subjective numbers,
it would be good if we reported what the current value was within the report,
so they don't have to go track it down and see how far off they are. For
example, the password minimum age says that "A value greater than 1 day is
considered sufficient for many environments". The check failed on my system.
Is that because it isn't set or it's set too low? What if I've determined
that the suggested default isn't sufficient for my environment, and I'm
happy with what I have it set to? Do I even know from this modal that it was
looking for a value of 1? Couldn't there be a mismatch between what the
description says it's looking for and what the parameter checked for?
Without reporting both here, I'm not sure there's any way to know if that
were the case.
11) In Password Warning Age modal details: "A value of 7 days would be nowadays
considered to be a standard." Do we need to qualify with nowadays? Say
"A value of 7 days is considered to be standard.".
12) In SSH Root Login Disabled modal details: "The root user should never be
allowed to login to a system directly over a network." should be
"...allowed to log in to..."
(Again, not sure if we can change this.)
Keep in mind that this was all gathered as a side effect without focusing on
the content at all. If we had done content specific testing we might have
gathered more.
Anybody else doing any UX testing of the SCAP tools?
--
Martin Preisler
9 years, 2 months
Handling various sysctl locations, runtime vs persistent checks
by Shawn Wells
Our current sysctl checks simultaneously check the runtime of the system
(via unix:sysctl_test) and the persistent configuration (regex on
sysctl.conf). We know these need to be broken out, and that's being
tracked in Issue #321 [1].
So then, to actually take action, it seems like we need to:
(1) Breakout the *runtime* checks into unique XCCDF and OVAL elements.
The OVAL will utilize unix:sysctl_test;
(2) Breakout the *persistent* checks.
On the persistent/static configuration side, from the sysctl manpage [2]
there are now 6 locations to bury persistent sysctl settings:
/etc/sysctl/*.conf
/usr/local/lib/sysctl.d/*.conf
/usr/lib/sysctl.d/*.conf
/lib/sysctl.d/*.conf
/etc/sysctl.conf
I can't find documentation on the "order of operations" on how sysctl
directories are scanned (aka, if a setting is placed in
/usr/lib/sysctl.d/, will /etc/sysctl/*.conf overwrite it?). Has anyone
seen any order of operations documentation on sysctl? My google-fu is
failing today =/
From the upstream source, I get the idea that /etc/sysctl.conf
overwrites everything [3], but unsure of the other paths. The closest
indication I could find was where PreLoadSystem() defines their dir[]
array [4], which shows:
- /run/sysctl.d (ignored, will be checked by runtime OVAL check)
- /etc/sysctl.d/
- /usr/local/lib/sysctl.d/
- /usr/lib/sysctl.d/
- /lib/sysctl.d/
As a side note, it looks like the code only checks *.conf files in those
directories, so we can ignore everything else [5].
[1] https://github.com/OpenSCAP/scap-security-guide/issues/321
[2] http://man7.org/linux/man-pages/man5/sysctl.conf.5.html
[3]
https://gitorious.org/procps/procps/source/fc7cb8dd4cd91da3d2df35b8863247...
[4]
https://gitorious.org/procps/procps/source/fc7cb8dd4cd91da3d2df35b8863247...
[5]
https://gitorious.org/procps/procps/source/fc7cb8dd4cd91da3d2df35b8863247...
9 years, 2 months