Any rumors on next draft for RHEL 8 STIG from DISA?

2020-12-02 Thread Hayden,Robert
Curious on if anyone has any information on the next draft release from DISA on 
RHEL 8 STIG benchmarks?  The one in May was pretty rough and did not really 
match where the current upstream was moving towards.

Thanks in advance
Robert

Robert Hayden | Lead Technology Architect | Cerner Corporation



CONFIDENTIALITY NOTICE This message and any included attachments are from 
Cerner Corporation and are intended only for the addressee. The information 
contained in this message is confidential and may constitute inside or 
non-public information under international, federal, or state securities laws. 
Unauthorized forwarding, printing, copying, distribution, or use of such 
information is strictly prohibited and may be unlawful. If you are not the 
addressee, please promptly delete this message and notify the sender of the 
delivery error by e-mail or you may call Cerner's corporate offices in Kansas 
City, Missouri, U.S.A at (+1) (816)221-1024.
___
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-le...@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.fedorahosted.org


RE: Excessive FIPS checks

2019-10-11 Thread Hayden,Robert
I had the same thoughts on these checks, but the wording in the DISA STIGs are 
very subtle.

V-72073 (AIDE implements FIPS..) has a note in the Check Text that reads:

Note: If RHEL-07-021350 is a finding, this is automatically a finding too as 
the system cannot implement FIPS 140-2 approved cryptographic algorithms and 
hashes.

RHEL-07-021350 is related to the system running in FIPS mode (V-72067).

V-72067 states :

The Red Hat Enterprise Linux operating system must implement NIST 
FIPS-validated cryptography for the following: to provision digital signatures, 
to generate cryptographic hashes, and to protect data requiring data-at-rest 
protections in accordance with applicable federal laws, Executive Orders, 
directives, policies, regulations, and standards.

Notice the phrase “NIST FIPS-validated cryptography”….that implies that the 
FIPS implementation must be certified by NIST.   Centos and others 
implementation of FIPS are not officially certified by NIST, so they can never 
pass V-72067 and thus never pass V-72073.

At least that is how I am reading the logic.

Robert

From: Chuck Atkins 
Sent: Friday, October 11, 2019 12:11 PM
To: SCAP Security Guide 
Subject: Excessive FIPS checks

So, I tied doing this via github but it seems the issue and PR were just 
abruptly closed within 20m without any meaningful conversation so I'm hoping 
that there can be a more fruitful discussion on list here.

https://github.com/ComplianceAsCode/content/issues/4917
https://github.com/ComplianceAsCode/content/pull/4920

The issue in question is that any FIPS related check includes a test for 
whether or not the OS is FIPS certified.  That seems to make sense as a stand 
alone rule but shouldn't that be orthogonal to whether or not SSH is configured 
to use FIPS approved crypto algorithms or if AIDE is configured to exclusively 
use FIPS approved hashes?  The rule isn't whether or not ssh is FIPS approved 
but just whether or not it's configuration is such that only approved ciphers 
are used.

--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.
(518) 881-1183


CONFIDENTIALITY NOTICE This message and any included attachments are from 
Cerner Corporation and are intended only for the addressee. The information 
contained in this message is confidential and may constitute inside or 
non-public information under international, federal, or state securities laws. 
Unauthorized forwarding, printing, copying, distribution, or use of such 
information is strictly prohibited and may be unlawful. If you are not the 
addressee, please promptly delete this message and notify the sender of the 
delivery error by e-mail or you may call Cerner's corporate offices in Kansas 
City, Missouri, U.S.A at (+1) (816)221-1024.
___
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-le...@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.fedorahosted.org


RE: Disabling specific bash remediations

2018-03-02 Thread Hayden,Robert
Look into SCAP Workbench to help build a custom security profile for your 
application.
https://www.open-scap.org/tools/scap-workbench/


Robert

From: Fen Labalme [mailto:fen.laba...@civicactions.com]
Sent: Thursday, March 1, 2018 10:00 PM
To: SCAP Security Guide 
Subject: Disabling specific bash remediations

The goal is to create a hardened EC2 server on AWS from scratch. After 
provisioning a new RHEL/7 instance on AWS, we run `yum -y update` followed by 
the bash remediations from SSG using:

  command: 'oscap xccdf eval --profile {{ scapprofile }} --remediate \
--results-arf /tmp/results-arf.xml --report /tmp/report.html \
/usr/share/xml/scap/ssg/content/ssg-rhel7-ds.xml'

But there are some remediations I don't want to run for an EC2 server such as 
install_smartcard_packages.sh and dracut-fips. Is there a way to prevent 
certain remediations from running?

Thanks,
=Fen



CONFIDENTIALITY NOTICE This message and any included attachments are from 
Cerner Corporation and are intended only for the addressee. The information 
contained in this message is confidential and may constitute inside or 
non-public information under international, federal, or state securities laws. 
Unauthorized forwarding, printing, copying, distribution, or use of such 
information is strictly prohibited and may be unlawful. If you are not the 
addressee, please promptly delete this message and notify the sender of the 
delivery error by e-mail or you may call Cerner's corporate offices in Kansas 
City, Missouri, U.S.A at (+1) (816)221-1024.
___
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-le...@lists.fedorahosted.org


RE: Use /etc/passwd directly instead of sources in NSS

2016-06-08 Thread Hayden,Robert
If it helps, you can use the following type of command to pull lines from 
/etc/passwd.

awk -v UID=500 -F: '($3>=UID)' /etc/passwd

Robert Hayden | Sr. Technology Architect | Cerner Corporation | 816.201.4068 | 
rhay...@cerner.com | www.cerner.com

From: Rodolfo Martínez [mailto:rmt...@gmail.com]
Sent: Wednesday, June 08, 2016 12:10 PM
To: SCAP Security Guide 
Subject: Re: Use /etc/passwd directly instead of sources in NSS

Hi Andrew,
I took a look at nsscache, it looks good. In fact, a combination of nsscache 
and nss_db might be a good solution, but not feasible at the moment.
If I would be able to get a list of users from /etc/passwd with UID greater or 
equal to 500 without using password_object (this is the one that pulls all 
information from LDAP) it would be the best solution now. I will continue 
trying to do it. I would appreciate any hint or someone that confirm that it is 
not possible.
Thanks

--
Rodolfo Martínez

On Tue, Jun 7, 2016 at 3:50 PM, Andrew Shewmaker 
> wrote:
A totally different approach to addressing your issue would be to use nss_db or 
http://code.google.com/p/nsscache/
 to cache LDAP.

On Tue, May 31, 2016 at 4:43 PM, Rodolfo Martínez 
> wrote:
Hi List,

After many hours playing with SSG and OpenSCAP and not able to do what
I want I need some help.

Forgive me if I use SCAP or OpenSCAP terms incorrectly, I am new to
SSG and I am still getting familiar.

The following OVAL test searches for system accounts (UID < 500) in
/etc/at.allow (I am showing just the relevant parts of
RHEL/5/input/oval/at_system_accounts.xml to explain my problem):


  



  



  
  state_at_system_accounts_at_allow_uid



  



  /etc/at.allow
  ^(.*)$
  0



  500



The test above gets the users information from the sources specified
in NSS (/etc/nsswitch.conf) which is correct, however I want to create
a version that uses /etc/passwd directly. Why? We have many
(thousands?) of RHEL 5 based servers with LDAP integration, and many
(thousands?) of accounts in the LDAP servers.

Simple tests like RHEL/5/input/oval/at_system_accounts.xml and
RHEL/5/input/oval/cron_system_accounts.xml can take hours to run
because they retrieve *all* users information from the LDAP servers
and they do it *for each entry* in /etc/at.allow and /etc/cron.allow.
Also, if we run OpenSCAP (oscap) at the same time in a few servers
they hit the LDAP servers really bad.

I have been trying to replace password_test and password_object by
textfilecontent54_test and textfilecontent54_object without any luck.
If you want, I can share my at_system_accounts.xml file that I thought
it was going to work.

I would really appreciate any help or hint?


Regards
--
Rodolfo Martínez
--
SCAP Security Guide mailing list
scap-security-guide@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/scap-security-guide@lists.fedorahosted.org
https://github.com/OpenSCAP/scap-security-guide/



--
Andrew Shewmaker

--
SCAP Security Guide mailing list
scap-security-guide@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/scap-security-guide@lists.fedorahosted.org
https://github.com/OpenSCAP/scap-security-guide/


CONFIDENTIALITY NOTICE This message and any included attachments are from 
Cerner Corporation and are intended only 

Any projects similar to OpenSCAP/SSG but for the Oracle RDBMS tier?

2014-06-24 Thread Hayden,Robert
I am looking to determine if there is a community project similar to 
OpenSCAP/SSG that applies to Oracle RDBMS STIG compliance?  I have done some 
RD on SSG for the Linux OS and have presented it internally at our Developer's 
conference with some positive feedback.  Outside of the Linux OS, the next big 
tier is Oracle RDBMS.

Thanks
Robert

Robert Hayden | Sr. Technology Architect | Cerner Corporation | 816.201.4068 | 
rhay...@cerner.commailto:rhay...@cerner.com | www.cerner.com



CONFIDENTIALITY NOTICE This message and any included attachments are from 
Cerner Corporation and are intended only for the addressee. The information 
contained in this message is confidential and may constitute inside or 
non-public information under international, federal, or state securities laws. 
Unauthorized forwarding, printing, copying, distribution, or use of such 
information is strictly prohibited and may be unlawful. If you are not the 
addressee, please promptly delete this message and notify the sender of the 
delivery error by e-mail or you may call Cerner's corporate offices in Kansas 
City, Missouri, U.S.A at (+1) (816)221-1024.
___
scap-security-guide mailing list
scap-security-guide@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide


RE: [PATCH 2/2] Bugfix - fixing typo ('Red Hat' instead of 'Red Had')

2014-06-09 Thread Hayden,Robert
If not too late, can you also correct the typo in the phrase partition 
definition will ca installer to pause?


Robert Hayden


-Original Message-
From: scap-security-guide-boun...@lists.fedorahosted.org 
[mailto:scap-security-guide-boun...@lists.fedorahosted.org] On Behalf Of David 
Smith
Sent: Monday, June 09, 2014 12:10 PM
To: scap-security-guide@lists.fedorahosted.org
Subject: [PATCH 2/2] Bugfix - fixing typo ('Red Hat' instead of 'Red Had')

---
 RHEL/6/input/system/software/disk_partitioning.xml |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/RHEL/6/input/system/software/disk_partitioning.xml 
b/RHEL/6/input/system/software/disk_partitioning.xml
index 54b45ae..a2c5914 100644
--- a/RHEL/6/input/system/software/disk_partitioning.xml
+++ b/RHEL/6/input/system/software/disk_partitioning.xml
@@ -147,7 +147,7 @@ Omitting the tt--passphrase=/tt option from the 
partition definition will ca  installer to pause and interactively ask for the 
passphrase during installation.
 br /br /
 Detailed information on encrypting partitions using LUKS can be found on -the 
Red Had Documentation web site:br /
+the Red Hat Documentation web site:br /
 
https://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Security_Guide/sect-Security_Guide-LUKS_Disk_Encryption.html
 /description
 ocil clause=encryption must be used and is not employed
--
1.7.1

___
scap-security-guide mailing list
scap-security-guide@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide

CONFIDENTIALITY NOTICE This message and any included attachments are from 
Cerner Corporation and are intended only for the addressee. The information 
contained in this message is confidential and may constitute inside or 
non-public information under international, federal, or state securities laws. 
Unauthorized forwarding, printing, copying, distribution, or use of such 
information is strictly prohibited and may be unlawful. If you are not the 
addressee, please promptly delete this message and notify the sender of the 
delivery error by e-mail or you may call Cerner's corporate offices in Kansas 
City, Missouri, U.S.A at (+1) (816)221-1024.
___
scap-security-guide mailing list
scap-security-guide@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide


Does aide_periodic_cron_checking have an incorrect fix documented?

2013-08-09 Thread Hayden,Robert
I was reviewing the Rule: aide_periodic_cron_checking and noticed the following 
recommended fix:

  start quote
  To implement a daily execution of AIDE at 4:05am using cron, add the 
following line to /etc/crontab:
  05 4 * * * root /usr/sbin/aide --check

  AIDE can be executed periodically through other means; this is merely one 
example.

   end quote--

This fix is also documented in the RHEL STIG version 1 release 2.

I believe that is an incorrect line for crontab as the 6th element is to be the 
executed command.  On my RHEL 6.4 machine, root is not a valid command and  I 
receive the following in local mail box

  # mail
  Heirloom Mail version 12.4 7/29/08.  Type ? for help.
  /var/spool/mail/root: 1 message 1 new
  N  1 Cron Daemon   Fri Aug  9 04:05  23/1036  Cron 
root@techval15 root /usr/sbin/aide --check
   1
  Message  1:
  From r...@techval15.northamerica.cerner.net  Fri Aug  9 04:05:01 2013
  Return-Path: r...@techval15.northamerica.cerner.net
  Date: Fri, 9 Aug 2013 04:05:01 -0500
  From: r...@techval15.northamerica.cerner.net (Cron Daemon)
  To: r...@techval15.northamerica.cerner.net
  Subject: Cron root@techval15 root /usr/sbin/aide --check
  Content-Type: text/plain; charset=ISO-8859-1
  Auto-Submitted: auto-generated
  X-Cron-Env: SHELL=/bin/sh
  X-Cron-Env: HOME=/root
  X-Cron-Env: PATH=/usr/bin:/bin
  X-Cron-Env: LOGNAME=root
  X-Cron-Env: USER=root
  Status: R

  /bin/sh: root: command not found


Am I missing something?

Thanks
Robert


Robert Hayden | Sr. Technology Architect | Cerner Corporation | 816.201.4068 | 
rhay...@cerner.commailto:rhay...@cerner.com | www.cerner.com



CONFIDENTIALITY NOTICE This message and any included attachments are from 
Cerner Corporation and are intended only for the addressee. The information 
contained in this message is confidential and may constitute inside or 
non-public information under international, federal, or state securities laws. 
Unauthorized forwarding, printing, copying, distribution, or use of such 
information is strictly prohibited and may be unlawful. If you are not the 
addressee, please promptly delete this message and notify the sender of the 
delivery error by e-mail or you may call Cerner's corporate offices in Kansas 
City, Missouri, U.S.A at (+1) (816)221-1024.
___
scap-security-guide mailing list
scap-security-guide@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide


RE: Does aide_periodic_cron_checking have an incorrect fix documented?

2013-08-09 Thread Hayden,Robert
The /etc/crontab file is what I was missing.  I simply did the user specific 
crontab -e command out of habit.  Old dog, new tricks.

Thanks
Robert

Robert Hayden | Sr. Technology Architect | Cerner Corporation | 816.201.4068 | 
rhay...@cerner.commailto:rhay...@cerner.com | www.cerner.com

From: scap-security-guide-boun...@lists.fedorahosted.org 
[mailto:scap-security-guide-boun...@lists.fedorahosted.org] On Behalf Of Bryan 
Harris
Sent: Friday, August 09, 2013 11:57 AM
To: scap-security-guide@lists.fedorahosted.org
Cc: scap-security-guide@lists.fedorahosted.org
Subject: Re: Does aide_periodic_cron_checking have an incorrect fix documented?

The sixth element is the user to run the command. The /etc/crontab file can run 
the command as any user. Same goes for files placed in /etc/cron.d folder IIRC.

On my RHEL 6.4 server there is a pretty obvious comment explaining the fields 
at the top of /etc/crontab unless I'm mistaken. Do you have a comment block on 
your servers in that file?

In any case all they're doing is giving one example that works. They say at the 
bottom there are other means (root's own crontab, another user via sudo, etc.)

Bryan

On Aug 9, 2013, at 12:52 PM, Paul Whitney 
paul.whit...@mac.commailto:paul.whit...@mac.com wrote:
Pretty sure you are correct.  This is an entry that should be in root's 
crontab, without the word root.

Paul M. Whitney
RHCSA, VCP

Chesapeake IT Consulting, Inc.
2680 Tobacco Rd
Chesapeake Beach, MD

20732


Work: 301.543.3716
Cell:   410.493.9448

paul.whit...@mac.commailto:paul.whit...@mac.com





On Aug 09, 2013, at 12:38 PM, Hayden,Robert 
rhay...@cerner.commailto:rhay...@cerner.com wrote:
I was reviewing the Rule: aide_periodic_cron_checking and noticed the following 
recommended fix:
start quote
To implement a daily execution of AIDE at 4:05am using cron, add the following 
line to /etc/crontab:
05 4 * * * root /usr/sbin/aide --check

AIDE can be executed periodically through other means; this is merely one 
example.

 end quote--

This fix is also documented in the RHEL STIG version 1 release 2.

I believe that is an incorrect line for crontab as the 6th element is to be the 
executed command.  On my RHEL 6.4 machine, root is not a valid command and  I 
receive the following in local mail box

# mail
Heirloom Mail version 12.4 7/29/08.  Type ? for help.
/var/spool/mail/root: 1 message 1 new
N  1 Cron Daemon   Fri Aug  9 04:05  23/1036  Cron root@techval15 
root /usr/sbin/aide --check
 1
Message  1:
From 
r...@techval15.northamerica.cerner.netmailto:r...@techval15.northamerica.cerner.net
  Fri Aug  9 04:05:01 2013
Return-Path: 
r...@techval15.northamerica.cerner.netmailto:r...@techval15.northamerica.cerner.net
Date: Fri, 9 Aug 2013 04:05:01 -0500
From: 
r...@techval15.northamerica.cerner.netmailto:r...@techval15.northamerica.cerner.net
 (Cron Daemon)
To: 
r...@techval15.northamerica.cerner.netmailto:r...@techval15.northamerica.cerner.net
Subject: Cron root@techval15 root /usr/sbin/aide --check
Content-Type: text/plain; charset=ISO-8859-1
Auto-Submitted: auto-generated
X-Cron-Env: SHELL=/bin/sh
X-Cron-Env: HOME=/root
X-Cron-Env: PATH=/usr/bin:/bin
X-Cron-Env: LOGNAME=root
X-Cron-Env: USER=root
Status: R

/bin/sh: root: command not found


Am I missing something?

Thanks
Robert


Robert Hayden | Sr. Technology Architect | Cerner Corporation | 816.201.4068 | 
rhay...@cerner.commailto:rhay...@cerner.com | 
www.cerner.comhttp://www.cerner.com



CONFIDENTIALITY NOTICE This message and any included attachments are from 
Cerner Corporation and are intended only for the addressee. The information 
contained in this message is confidential and may constitute inside or 
non-public information under international, federal, or state securities laws. 
Unauthorized forwarding, printing, copying, distribution, or use of such 
information is strictly prohibited and may be unlawful. If you are not the 
addressee, please promptly delete this message and notify the sender of the 
delivery error by e-mail or you may call Cerner's corporate offices in Kansas 
City, Missouri, U.S.A at (+1) (816)221-1024.
___
scap-security-guide mailing list
scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guidehttps://urldefense.proofpoint.com/v1/url?u=https://lists.fedorahosted.org/mailman/listinfo/scap-security-guidek=PmKqfXspAHNo6iYJ48Q45A%3D%3D%0Ar=MeiC35CFRyFVyqWUnw11jlPbFzJPYPeXmyplv564q7o%3D%0Am=srzESgYPteuGTVhBfVlT35dlOzjHzBkk%2Bg5wEv4LHa0%3D%0As=b0b9e43c84ad7fe237a48cbfca588072f92bb813cf9a2e932c595d4c9f110754
___
scap-security-guide mailing list
scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guidehttps://urldefense.proofpoint.com/v1/url?u=https