Re: EXTERNAL: Re: RHEL7 DISA STIG questions

[Albrecht, Thomas C]

Trevor,

Can you provide details on the compliance introspection? If it’s What I think 
it is, we have the same concerns and I’m looking for ways to tackle it.

Sent from my iPhone

On Mar 6, 2020, at 11:11 AM, Trevor Vaughan  wrote:


No problem. We'll take Ansible ports of the code into the project as well but 
there are some things that Ansible can't do around (that I know of) around 
compliance introspection of the codebase that keeps us with puppet so far.

Thanks,

Trevor

On Fri, Mar 6, 2020 at 10:05 AM James Cassell 
mailto:fedoraproj...@cyberpear.com>> wrote:

On Fri, Mar 6, 2020, at 8:48 AM, Trevor Vaughan wrote:
> Hi James,
>
> From what I've seen of the project (someone please correct me if I'm
> wrong), the Ansible code from the SSG was meant to help you address
> individual items without really being a cohesive infrastructure.
> Cohesive infrastructures take a LOT of time to build and test.
>
> What you're asking for is what we do in the FOSS SIMP project
> https://simp-project.com and we actually run the SSG tests against our
> enforcement components on a regular basis as well as InSpect tests and
> compare the two. By doing this, we've found issues in our code, the SSG
> rules, and the InSpec rules over time.
>
> We'd love more interested people to take a look and help us close the
> feedback loop between the two projects.
>

Looks like a nice project. I'm just not interested in puppet these days.  I'll 
recommend your project to folks who are puppet shops if I come across them. 
(Everyone I work with is using ansible these days.)

V/r,
James Cassell

> Thanks,
>
> Trevor
>
>
> On Fri, Mar 6, 2020 at 12:14 AM James Cassell
> mailto:fedoraproj...@cyberpear.com>> wrote:
> > On Thu, Mar 5, 2020, at 9:57 PM, Shawn Wells wrote:
> >  >
> >  >
> >  > On 3/5/20 1:00 PM, James Cassell wrote:
> >  > > On Thu, Mar 5, 2020, at 12:57 PM, Jeff Bachtel wrote:
> >  > >> Good day. I am trying to apply current RHEL7 STIG guidance to AWS EC2
> >  > instances and have run into issues. Could someone check my conclusions
> >  > below and let me know if I missed something?
> >  >
> >  > - OpenSCAP doesn't yet support RHEL7 STIG V2R6 in its in-tree code
> >  > (including remediation code)
> >  > - The NIST NCP for RHEL7 from
> >  > >> https://github.com/ComplianceAsCode/content/tree/master/rhel7 doesn't
> >  > yet include STIG V2R4 remediations
> >  > - The actual DISA RHEL7 STIG XCCDF file does not include fixes, such
> >  > that OpenSCAP could use it to generate remediation scripts
> >  > - https://github.com/MindPointGroup/RHEL7-STIG is probably the best
> >  > RHEL7 STIG remediation script that's publicly available
> >  >
> >  > > All correct from my perspective.
> >  >
> >  >
> >  > To the best of our knowledge there haven't been any substantive changes
> >  > to the DISA content. At least we haven't been informed of any (eg rule
> >  > selections/removals, changing variables like password length, etc).
> >  >
> >  > That said, could be interesting to run the Red Hat provided
> >  > remediations and then re-scan with the DISA-provided content. Goal
> >
> >  It's concerning that this hasn't already been done.
> >
> >  > would be to see if anything fails... in theory showing any gaps between
> >  > the content.
> >  >
> >  > Would you be interested/able to help do that? Here's the ansible content:
> >  >
> >  > https://galaxy.ansible.com/RedHatOfficial/rhel7_stig
> >  >
> >
> >  Unfortunately, that "RedHatOfficial" ansible role has some problems:
> >
> >  1. It does not follow ansible best practices such as prefixing each role 
> > variable with a variable namespace unique to the role, such as a 
> > `rhel7_stig_` prefix.
> >
> >  2. It is not idempotent
> >
> >  3. There is no explanation for any of the variables.
> >
> >  4. It's nearly impossible to audit any changes: 
> > https://github.com/RedHatOfficial/ansible-role-rhel7-stig/commit/3cdf26b66cc723d34ba5dd3ed3d39410f48ae89c
> >
> >   "7,176 additions, 8,160 deletions not shown because the diff is too 
> > large. Please use a local Git client to view these changes. "
> >
> >  5. The thing is a monstrosity at 16K lines for its tasks, so even if you 
> > audit it once, good luck auditing half of it again next time an update is 
> > pushed. (The ansible-lockdown ( https://github.com/ansible/ansible-lockdown 
> > ) role currently under the MindPointGroup org is also not tiny at 3.8K 
> > lines for its tasks.)
> >
> >  6. Does not practice DRY (don't repeat yourself), contributing to (4). 
> > RedHatOfficial show 578 tasks when run with `--list-tasks` whereas 
> > MindPointGroup shows 314 tasks. (RH lists "only" 84% more unique tasks, but 
> > has 420% more lines to audit.)
> >
> >  7. It's not really an open source project, but generated code from an open 
> > source project.
> >
> >  8. All PRs to the role are being ignored: 
> > https://github.com/RedHatOfficial/ansible-role-rhel7-stig/pulls
> >
> >  9. It clearly hasn't been audited by anyone who is 

RE: EXTERNAL: SCAP not Matching STIG

[Albrecht, Thomas C]

This isn't the right forum, since it's specifically for RH and other Linux 
based scores.  You're probably going to have to contact DISA directly related 
to problems with the Windows STIGs and benchmarks.

https://public.cyber.mil/knowledge-base/scap-srg-stig-questions/

Tom A.

-Original Message-
From: joes...@mm.st  
Sent: Friday, October 11, 2019 5:26 PM
To: scap-security-guide@lists.fedorahosted.org; open-scap-l...@redhat.com
Subject: EXTERNAL: SCAP not Matching STIG

This may be the wrong place to ask this, but I've been looking at this for 
hours  and was hoping someone could either explain what I'm seeing or point to 
someplace that I can ask.

I am trying to understand why several checks are missing  using the SCAP 
content with the SCAP Compliance Checker 5.2.1.   Using the SCAP content for 
Windows 10 (V1R15) and comparing to the STIG of the same version there are 
several checks for Exploit Protection that is not in the SCAP content, but are 
listed in the STIG.

For example  V-77097 (WN10-EP-40), V-77101 (WN10-EP-50) are missing.  
There are several others as well for Exploit Protection.  Shouldn't the SCAP 
content for V1R15 match what the STIG of the same version states that needs to 
be checked. 

What am I missing?

Thank You
___
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
___
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: EXTERNAL: Excessive FIPS checks

[Albrecht, Thomas C]

Chuck,

This is a very philosophical question, and I tend to lean towards what I see as 
RH’s perspective.  FIPS certification is more than just turning on ciphers, 
which you can do on CentOS, but doing so only does the technical part, but it’s 
not the whole chain.  If you look at the DISA STIG checks for FIPS ciphers, 
they check not only that sshd_config is correct, but also that you’re running 
RH (even if you turn off the OS check).  It doesn’t do this for every check, 
but just the checks related to FIPS.

If I can give an analogy, FIPS is like a signature on a piece of paper.  
Configuring FIPS is like signing a document, but having that signature 
notarized, while not technically doing anything to the signed piece of paper, 
gives the paper much more legal weight.  However, that doesn’t make an 
unnotarized signed document worthless.  So, having a CentOS system with proper 
technical configurations in place is better than not doing so (like having a 
will on a piece of paper in the top drawer of your dresser is better than not 
having a will), calling that configuration “FIPS enabled” is not the case.  
It’s “just” a server with certain ciphers enabled.

So, if I were king for a day, I would propose the idea that having a server 
pass a “FIPS valid” check would requiring passing other checks (ciphers, kernel 
FIPS configuration, supported RHEL OS).  A hardened CentOS system could be 
configured to pass the cipher check and kernel checks, but fail the supported 
OS and the meta FIPS validated check.

--

Tom Albrecht III, CISSP-ISSEP, GPEN, RHCSA
Cyber Architect, Lockheed Martin RMS
thomas.c.albre...@lmco.com – 610-906-4356

Please consider supporting my work in Africa
https://www.gofundme.com/computer-network-for-abi



From: Chuck Atkins 
Sent: Friday, October 11, 2019 1:11 PM
To: SCAP Security Guide 
Subject: EXTERNAL: 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
___
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

Minimum Password Length (15 vs 12)

[Albrecht, Thomas C]

All,

While we’re on the topic of source policies, I’ve been trying to track down the 
reasoning for the 15 character minimum.  I’m sure it’s not conjured from 
nowhere, but the only policy I’ve found that dictates minimum password length 
[IA-5(1)] is CNSSI-1253 (Dated Mar 2014) that says 12 characters minimum.

“A case sensitive 12-character mix of upper case letters, lower case letters, 
numbers and special characters in including at least one of each.”

I checked the classified and intelligence overlays, and didn’t see any 
reference to the control.  So, can anyone point me to a policy that leads to 15 
characters being in the STIG?

Tom A.

Thomas Albrecht III, CISSP-ISSEP, RHCSA
Cyber Architect | Cyber Inside 
|CAS­2­T
Lockheed Martin, Rotary and Mission Systems (RMS)
230 Mall Blvd, | King of Prussia, PA
[m] 610-906-4356
cyber.secur...@lmco.com
[cid:image003.png@01D030AD.9DBE6340]


___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedorahosted.org

SSG List Web Interface Account Reset

[Albrecht, Thomas C]

All,

Sorry for the meta question, but I can't seem to figure this one out.  I've 
been on this a while, and it looks like the hosting has migrated at least once 
since the last time I tried to access the archive web page.  I don't know what 
my password is, and when I try to reset with either of the accounts I'm using 
to subscribe to the list, the server is telling me that the email address 
doesn't exist in the system.  Not sure where to go from here, but I'm hoping 
someone can point me in the right direction.


I did get a bit of a chuckle, as the "reset password" page states "Please 
contact us if you have any trouble resetting your password.", but doesn't have 
any direction as to how to contact "us".

Thanks!

Tom A.

Thomas Albrecht III, CISSP-ISSEP, RHCSA
Cyber Architect | Cyber Inside 
|CAS2T
Lockheed Martin, Rotary and Mission Systems (RMS)
230 Mall Blvd, | King of Prussia, PA
[m] 610-906-4356
cyber.secur...@lmco.com
[cid:image003.png@01D030AD.9DBE6340]

___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedorahosted.org

RE: EXTERNAL: Re: alternatives to STIG Viewer once Oracle JDK 8 / JavaFX 8 is EOL in January 2019?

[Albrecht, Thomas C]

CKL files are a supported input formal for Vulnerator, which is a tool commonly 
used for putting POAMs together in an excel format.

https://github.com/Vulnerator/Vulnerator

Tom A.

-Original Message-
From: Shawn Wells  
Sent: Thursday, November 29, 2018 2:14 PM
To: scap-security-guide@lists.fedorahosted.org
Subject: EXTERNAL: Re: alternatives to STIG Viewer once Oracle JDK 8 / JavaFX 8 
is EOL in January 2019?



On 11/28/18 12:51 PM, Trevor Vaughan wrote:
> Heh, no offense taken. I just needed to turn the little lights green 
> with a .ckl file...and I did :-D

What are the .ckl files imported into? How are they used?

For example if OpenSCAP or Satellite could evaluate a system and output a 
properly formatted .ckl file... would that provide value? What happens with 
.ckl files?
___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedorahosted.org
___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedorahosted.org

RE: alternatives to STIG Viewer once Oracle JDK 8 / JavaFX 8 is EOL in January 2019?

[Albrecht, Thomas C]

They can and have been automated.  One of our engineers at LM has created a 
very bloated python script that goes through each of the items in the DISA 
STIG, and only leaves one unanswered (I think it's the "ask the admin if he's 
doing backups")

Tom A.

From: Meinecke, Lee 
Sent: Thursday, November 29, 2018 2:25 PM
To: scap-security-guide@lists.fedorahosted.org
Subject: EXTERNAL: Re: alternatives to STIG Viewer once Oracle JDK 8 / JavaFX 8 
is EOL in January 2019?


.ckl files are the manual checklists that are used to import the automated 
XCCDF content. For example on RHEL6 you import the XCCDF content from the scan 
and then you have 85 manual controls to review. You use the Java STIG viewer 
(JavaFX required) as the GUI to provide comments and choose from a drop down 
menu (open, not a finding, not applicable) for each manual control. The 
auditors typcially request results from each host in .ckl format I believe 
because it shows you've done the manual review as opposed to providing an SCC 
or openscap HTML report which would only cover the automated checks.



btw, those 85 manual RHEL6 controls could be automated. Most are run this 
command if it produces results its a finding. A few require interpretation but 
most seem like they could be automated.



Lee


From: Shawn Wells mailto:sh...@redhat.com>>
Sent: Thursday, November 29, 2018 1:14 PM
To: 
scap-security-guide@lists.fedorahosted.org
Subject: Re: alternatives to STIG Viewer once Oracle JDK 8 / JavaFX 8 is EOL in 
January 2019?



On 11/28/18 12:51 PM, Trevor Vaughan wrote:
> Heh, no offense taken. I just needed to turn the little lights green
> with a .ckl file...and I did :-D

What are the .ckl files imported into? How are they used?

For example if OpenSCAP or Satellite could evaluate a system and output
a properly formatted .ckl file... would that provide value? What happens
with .ckl files?
___
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://getfedora.org/code-of-conduct.html
[https://getfedora.org/static/images/fedora.png]

Fedora Code of Conduct
getfedora.org
Choose Freedom. Choose Fedora. Pick a flavor of Fedora streamlined for your 
needs, and get to work right away.



List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedorahosted.org
___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedorahosted.org

Re: EXTERNAL: Re: False positive message for sshd key file permission

[Albrecht, Thomas C]

I’d leave it, since something seems to revert the permissions later back to 
0640. (Probably a package update, but I haven’t researched it yet.).

Tom A.

Sent from my iPhone

On Sep 25, 2018, at 2:24 PM, Matus Marhefka 
mailto:mmarh...@redhat.com>> wrote:

Hello,

@Shawn Wells<mailto:swe...@redhat.com> you are right and I fixed our content, 
see https://github.com/ComplianceAsCode/content/pull/3362 for more details. Is 
it okay or should we stay with 0600 until DISA fixes it in their content?

Best Regards,
Matus



On Thu, Sep 20, 2018 at 8:31 PM Dushyant Uge 
mailto:d...@redhat.com>> wrote:
Thank you all for your responses.

@Albrecht, Thomas C

Yes, the customer said --

We are using the profile DISA STIG for Red Hat Enterprise Linux 7 based on  
ssg-rhel7-ds security.xml as found on 
https://github.com/OpenSCAP/scap-security-guide/releases/download/v0.1.40/scap-security-guide-0.1.40-oval-510.zip
  and tried with the default openscap scanner from the RHEL 7.5 ISO as well as 
the latest version available on the redhat site (1.2.16.8.el7_5).


Warm Regards,
Dushyant Uge
Red Hat Global Support

On Thu, Sep 20, 2018 at 8:05 AM, Shawn Wells 
mailto:sh...@redhat.com>> wrote:


On 9/20/18 10:52 AM, Albrecht, Thomas C wrote:
Ok, there’s an inconsistency then.  The DISA STIG says that the private keys 
need to be 0600.  Looks like they set permissions to the DISA version of the 
rule, but are scanning the SSG version of the rule.
Can you provide a “proof of concept” that shows the key generation failing if 
the permissions are set to 0600 so I have something in my back pocket to show 
our customer?

It's a known issue in the DISA content. We let them know about it a few years 
ago now. Have been told a fix is making it's way through their release 
processes.

___
scap-security-guide mailing list -- 
scap-security-guide@lists.fedorahosted.org<mailto:scap-security-guide@lists.fedorahosted.org>
To unsubscribe send an email to 
scap-security-guide-le...@lists.fedorahosted.org<mailto:scap-security-guide-le...@lists.fedorahosted.org>
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedorahosted.org


___
scap-security-guide mailing list -- 
scap-security-guide@lists.fedorahosted.org<mailto:scap-security-guide@lists.fedorahosted.org>
To unsubscribe send an email to 
scap-security-guide-le...@lists.fedorahosted.org<mailto:scap-security-guide-le...@lists.fedorahosted.org>
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedorahosted.org
___
scap-security-guide mailing list -- 
scap-security-guide@lists.fedorahosted.org<mailto:scap-security-guide@lists.fedorahosted.org>
To unsubscribe send an email to 
scap-security-guide-le...@lists.fedorahosted.org<mailto:scap-security-guide-le...@lists.fedorahosted.org>
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedorahosted.org
___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedorahosted.org

RE: EXTERNAL: Re: False positive message for sshd key file permission

[Albrecht, Thomas C]

Ok, there’s an inconsistency then.  The DISA STIG says that the private keys 
need to be 0600.  Looks like they set permissions to the DISA version of the 
rule, but are scanning the SSG version of the rule.



Can you provide a “proof of concept” that shows the key generation failing if 
the permissions are set to 0600 so I have something in my back pocket to show 
our customer?



Tom A.



From: Gabe Alford 
Sent: Thursday, September 20, 2018 10:44 AM
To: SCAP Security Guide 
Subject: EXTERNAL: Re: False positive message for sshd key file permission



The scan fails because permissions should be 0640 for the private key. If they 
are not set to 0640, this prevents sshd from generating keys.



On Thu, Sep 20, 2018 at 8:40 AM, Dushyant Uge 
mailto:d...@redhat.com>> wrote:

   Hello Team,



   One of our customer raised concern  that --

   The rule going wrong are:
   xccdf_org.ssgproject.content_rule_file_permissions_sshd_private_key
   xccdf_org.ssgproject.content_rule_file_permissions_sshd_pub_key



   On the customer's system, the correct permissions seen --

   Red Hat Enterprise Linux Server release 7.5 (Maipo)

   openssh-server-7.4p1-16.el7.x86_64

   openscap-1.2.16-6.el7.x86_64



   -640 for public key files (*.pub)
   -600 for private key files (*_key)

   Output of ls –l /etc/ssh
   -rw-r--r--. 1 root root 581843 Nov 24  2017 moduli
   -rw-r--r--. 1 root root   2276 Nov 24  2017 ssh_config
   -rw---. 1 root root   4026 Sep  4 14:20 sshd_config
   -rw---. 1 root ssh_keys241 Sep  4 14:20 ssh_host_ecdsa_key
   -rw-r--r--. 1 root root162 Sep  4 14:20 ssh_host_ecdsa_key.pub
   -rw---. 1 root ssh_keys   1704 Sep  4 14:20 ssh_host_rsa_key
   -rw-r--r--. 1 root root382 Sep  4 14:20 ssh_host_rsa_key.pub
   -rw-r--r--. 1 root root   2548 Sep  4 14:20 ssh_known_hosts



   Please find attached screenshot and suggest.





   Warm Regards,

   Dushyant Uge

   Red Hat Global Support


   ___
   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://getfedora.org/code-of-conduct.html
   List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
   List Archives: 
https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedorahosted.org



___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedorahosted.org

Re: EXTERNAL: Re: Ansible vs bash fixup scripts

[Albrecht, Thomas C]

I’m sure we’ve had a dozen groups just within my company do it.

Sent from my iPhone

On Dec 14, 2017, at 11:31 PM, Matthew 
> wrote:

Nice to see I'm not the only one who scripted these things.

On Dec 12, 2017 6:15 PM, "Pellitt, Chad CIV CDSA Dam Neck, R21" 
> wrote:
I have bash remediation scripts for most of the rules you listed, which I can 
share if you want them. I wrote or modified scripts for all the rules in the 
RHEL 7 DISA STIG profile when it was still in the early stages. That profile 
went through a lot of changes a while back, so most of those rules are in the 
OSPP profile, but not the STIG profile now. The scripts for rules removed from 
the STIG profile have been neglected since then, so they might not exactly 
match the current rule.

Chad Pellitt
CDSA Dam Neck R21
chad.pell...@navy.mil

From: Chuck Atkins [chuck.atk...@kitware.com]
Sent: Tuesday, December 12, 2017 4:10 PM
To: SCAP Security Guide
Subject: [Non-DoD Source] Re: Ansible vs bash fixup scripts

My "awking" was a little off so a few of those do have bash content but most do 
not.

The audit and dconf rules were the most problematic to deal with.  The audit 
rules because I (and I'm sure I'm not alone here) tend to find them very opaque 
cryptic. so manually fixing them can be rough.  The dconf rules are confusing 
mainly because the description explicitly refers to a particular file to put 
settings in while the bash content for other dconf settings seem to create an 
SCAP Security Guide specific config file (i.e. 
/etc/dconf/db/local.d/10-scap-security-guide for example).  I can see why 
that's certainly valid but it's confusing to have the prose refer to addressing 
the issue in one file while the fix scripts address it in a different file.

--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.


On Tue, Dec 12, 2017 at 4:02 PM, Marek Haicman 
>>
 wrote:
Crossreferencing with my attempt to remediate basically fresh RHEL7 
installation, these are rules from your list that are in my OSPP-hardened 
system marked as failing:

audit_rules_privileged_commands
firewalld_sshd_port_enabled

So using also ansible won't help you much.



On 12/12/2017 09:35 PM, Chuck Atkins wrote:
Some awk-ing in the ssg-rhel7-xccdf.xml  from 1.36 showed the following rules 
with only ansible fixes:

accounts_root_path_dirs_no_write
audit_rules_dac_modification_fchmod
audit_rules_dac_modification_fchown
audit_rules_privileged_commands
audit_rules_privileged_commands_su
audit_rules_privileged_commands_sudo
audit_rules_unsuccessful_file_modification_open
dconf_gnome_banner_enabled
dconf_gnome_disable_automount
dconf_gnome_disable_ctrlaltdel_reboot
dconf_gnome_disable_geolocation
dconf_gnome_disable_restart_shutdown
dconf_gnome_disable_thumbnailers
dconf_gnome_disable_user_admin
dconf_gnome_disable_user_list
dconf_gnome_disable_wifi_create
dconf_gnome_disable_wifi_notification
dconf_gnome_screensaver_lock_delay
dconf_gnome_screensaver_user_info
firewalld_sshd_port_enabled
gnome_gdm_disable_automatic_login
gnome_gdm_disable_guest_login
mount_option_dev_shm_nodev
mount_option_dev_shm_noexec
mount_option_dev_shm_nosuid
mount_option_home_nodev
mount_option_home_nosuid
mount_option_var_tmp_nodev
mount_option_var_tmp_noexec
mount_option_var_tmp_nosuid
rpm_verify_hashes
sebool_httpd_can_network_connect
sebool_secure_mode
set_password_hashing_algorithm_libuserconf
sshd_disable_rhosts
sshd_enable_x11_forwarding
sssd_memcache_timeout
sssd_offline_cred_expiration
sssd_ssh_known_hosts_timeout


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

On Tue, Dec 12, 2017 at 2:17 PM, Marek Haicman 
>
 
 RHEL7 + OSPP since what would easily be a
well-documented single-command process to bring the first into
compliance is not so clear-cut for the second.

 Basically - it's more about resources available, and not
much about
 our agenda. And with Ansible remediations on par with bash, we
 should be able to fix both.


I'm all about having better, more easily maintained content. 
So, given the current state of things, what is the right way to

Re: EXTERNAL: RE: [Non-DoD Source] DISA STIG for Ubuntu Released...

[Albrecht, Thomas C]

Maybe they thought they were writing a fedora STIG? ;-)

Sent from my iPhone

On Sep 22, 2017, at 8:12 AM, Arnold, Paul C CTR USARMY PEO STRI (US) 
> wrote:


It says V1R1, but portions of it are still very draft-like:



"Install the Ubuntu operating system patches or updated packages available from 
Red Hat within 30 days or sooner as local policy dictates."







Help, I can't find the unstable yum repo!





--
Paul Arnold, CISSP
Cole Engineering Services, Inc.



From: Sean [smalde...@gmail.com]
Sent: Thursday, September 21, 2017 02:56 PM
To: SCAP Security Guide
Subject: [Non-DoD Source] DISA STIG for Ubuntu Released...

All active links contained in this email were disabled. Please verify the 
identity of the sender, and confirm the authenticity of all links contained 
within the message prior to copying and pasting the address to a Web browser.




Hi All,

I recall recently someone had asked about SSG for Ubuntu, and there was a long 
thread following about the STIG process.  I was surprised today when someone 
asked me if I could look at the Ubuntu STIG because just last week I had been 
on the STIG website and no such thing had existed.

Anyway, Caution-https://iase.disa.mil/stigs/os/unix-linux/Pages/index.aspx < 
Caution-https://iase.disa.mil/stigs/os/unix-linux/Pages/index.aspx >  has 
Ubuntu 16.04 STIG v1r1 available.  Will there be any work in the SSG project to 
incorporate this?

P.S. I wonder how Canonical got a STIG published with out going through any 
draft releases and less than 18 months after the OS version was published?

--Sean
___
scap-security-guide mailing list -- 
scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to 
scap-security-guide-le...@lists.fedorahosted.org
___
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: [Non-DoD Source] Re: oscap output and STIG Viewer

[Albrecht, Thomas C]

Sadly, this is the response I expected.  DISA is not being asked to support 
OpenSCAP.  They're being asked to comply with SCAP, which, last time I checked, 
is a standard published by NIST.

Embrace and extend.

Tom A.

-Original Message-
From: Paige, David B CTR USARMY ICOE (US) [mailto:david.b.paige@mail.mil] 
Sent: Friday, August 18, 2017 1:36 PM
To: SCAP Security Guide 
Subject: EXTERNAL: RE: [Non-DoD Source] Re: oscap output and STIG Viewer

OpenSCAP will not be supported.  There is a benchmark in development which will 
correspond to the RHEL7 STIG.

-Original Message-
From: Shawn Wells [mailto:sh...@redhat.com]
Sent: Friday, August 18, 2017 9:13 AM
To: scap-security-guide@lists.fedorahosted.org
Subject: [Non-DoD Source] Re: oscap output and STIG Viewer

All active links contained in this email were disabled.  Please verify the 
identity of the sender, and confirm the authenticity of all links contained 
within the message prior to copying and pasting the address to a Web browser.  








On 8/18/17 10:20 AM, Trevor Vaughan wrote:
> Please do ask DISA to support the standard SCAP formats if at all 
> possible.
>
> I haven't been able to find any of their internal formats yet I'm 
> trying to automate the generation of content for them.
>
> This really is not helpful to their user base.

Having end-customers/users make the requests would be ideal:

Caution-https://iase.disa.mil/stigs/Pages/contact.aspx

disa.stig_...@mail.mil
___
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-le...@lists.fedorahosted.org
___
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-le...@lists.fedorahosted.org
___
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: EXTERNAL: Re: Time to drop bash remediations?

[Albrecht, Thomas C]

You can run Ansible playbooks locally without a server. Your describing a 
normal Ansible deployment, but if the Ansible package is installed on a local 
system, you don't need an external system. 

Shawn... is your vision that Ansible would be a dependency for SSG 
remediations? I don't have an issue with that at all, but I'm just trying to 
think through how it would work when applying security policies during 
installation. 

Tom A. 

Sent from my iPhone

> On Aug 1, 2017, at 7:32 PM, Bond Masuda  wrote:
> 
> I'm probably missing the point here, but I don't understand. Ansible is 
> agentless and doesn't require anything to run plays/tasks on a remote system 
> other than an ssh connection/account and the proper privileges for that 
> account. At the end of the day, it may end up running a command line via the 
> "shell" module anyway, so what's the point?
> 
> What does ansible being available have anything to do with remediation of the 
> target system? You only install ansible on the control system, not the target 
> usually unless you're using the pull mechanism? I think it would be nice to 
> have ansible plays that can do the remediation, but you can do that without 
> having ansible installed on the target system...
> 
> ?? confused ??
> 
> 
>> On 08/01/2017 04:20 PM, Shawn Wells wrote:
>> RHEL 7.4 is out! That means we can now be public on how Ansible is
>> shipping as part of the rhel-7-server-extras-rpms channel:
>> https://access.redhat.com/downloads/content/ansible/2.3.1.0-3.el7/noarch/fd431d51/package
>> 
>> Now that we can ensure every RHEL install has access to Ansible, is it
>> time to remove the bash scripts?
>> 
>> The original premise of bash script inclusion was "bash is everywhere
>> RHEL is" . and now Ansible carries the same truth.
>> 
>> Potential downside for discussion:
>> Ansible binaries ship in the extras channel versus the core
>> rhel-7-server (or whatever it's called). Will users mind enabling the
>> extras channel?
>> 
>> ___
>> scap-security-guide mailing list -- 
>> scap-security-guide@lists.fedorahosted.org
>> To unsubscribe send an email to 
>> scap-security-guide-le...@lists.fedorahosted.org
> ___
> scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org
> To unsubscribe send an email to 
> scap-security-guide-le...@lists.fedorahosted.org
___
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: EXTERNAL: Re: GitHub Org Membership --> public

[Albrecht, Thomas C]

Neat... I got the nickname when I lived in Japan.  I used to go by copperhead 
before the move, and once I explained to my Japanese buddies what a copperhead 
was, I found the Japanese version was more distinctive.

Now if only I get the twitter handle.

Tom A.

-Original Message-
From: Shawn Wells [mailto:sh...@redhat.com] 
Sent: Tuesday, July 18, 2017 7:22 PM
To: scap-security-guide@lists.fedorahosted.org
Subject: Re: EXTERNAL: Re: GitHub Org Membership --> public



On 7/18/17 11:26 AM, Albrecht, Thomas C wrote:
> Ditto.  I'm "dokuhebi".
dokuhebi-san ni go-chuui wo ?
___
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-le...@lists.fedorahosted.org
___
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: EXTERNAL: Re: GitHub Org Membership --> public

[Albrecht, Thomas C]

Ditto.  I'm "dokuhebi".

-Original Message-
From: Shawn Wells [mailto:sh...@redhat.com] 
Sent: Tuesday, July 18, 2017 11:24 AM
To: Fen Labalme ; SCAP Security Guide 

Subject: EXTERNAL: Re: GitHub Org Membership --> public



On 7/18/17 7:40 AM, Fen Labalme wrote:
> Hi Shawn,
>
> I would like to be added to the OpenSCAP people list - my github 
> account is "openprivacy".

Done!

___
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-le...@lists.fedorahosted.org
___
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: EXTERNAL: Anyone going to Summit next week?

[Albrecht, Thomas C]

I'll be there.  My first one and I'm pretty excited.

-Original Message-
From: Shawn Wells [mailto:sh...@redhat.com] 
Sent: Friday, April 28, 2017 4:13 PM
To: scap-security-guide 
Subject: EXTERNAL: Anyone going to Summit next week?

Figured there would be more than a few OpenSCAP community members at Summit 
next week. Anyone want to meetup for food/drinks at some point?

I know Martin, Robin and myself will be there all/most of the week.
___
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-le...@lists.fedorahosted.org
___
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-le...@lists.fedorahosted.org

Arch Linux STIG ( was RE: Introduction and Questions)

[Albrecht, Thomas C]

Tim,

Such a simple question has so much complexity behind it. :-)

SCAP is really just a language for verifying and imposing a defined 
configuration baseline on a specific target.  From a Linux standpoint, there 
are two major elements for "getting SCAP up and running".  One is running a 
SCAP engine (OpenSCAP, SCC, etc.) to test a baseline, and the other is 
identifying the baseline you're using to test against.  So, if you're simply 
charged with getting a SCAP engine running on your system, you could do the 
work needed to convert OpenSCAP or SCC to run on Arch.  There is an AUR project 
for this that seems to still be maintained 
(https://aur.archlinux.org/packages/openscap/).  

The more complicated question is about STIGing Arch.  As far as I know, it 
hasn't been done.  There has been work on getting the RHEL6/7 STIGs SSG ported 
over to CentOS6/7, but that's a less complicated endeavor, since the baselines 
are almost identical.  Arch is a different beast entirely, and would involve 
hundreds of hours of work.  The concern, though, is at the end of the day, even 
if you did the work, you'd need to be careful what you're asserting to your 
customer.  Any conversion you did would not be an official STIG, but a 
derivative work to meet the intention of the STIG.

DISA has a process creating a STIG for a new operating system (which is what 
this activity would be), and it would involve starting with the Control 
Correlation Identifiers (CCIs) 
(http://iase.disa.mil/stigs/cci/Pages/index.aspx), and determine whether those 
controls apply to Arch Linux (The SSG project did that activity for RHEL7 here. 
https://github.com/OpenSCAP/scap-security-guide/wiki/RHEL7-STIG-Settings-Review).
 Once that's completed, you would then create a STIG that maps to the OS 
configurations to the CCIs, including how to audit a configuration, and how to 
set a configuration.  DISA does have a process once you've done that work to 
have the STIG submitted for inclusion in their repositories.  (PostgreSQL is an 
open source project that just had a STIG approved by DISA.)

The other (easier) option if your customer already understands the position 
you're in with using Arch Linux is to use the General Purpose Operating System 
STIG instead of going back to the CCIs.  If you start with the General Purpose 
STIG, you can create your own derivative STIG that identifies how to configure 
Arch to meet each of those different items.  It's a bit of work, and you'd 
still have to get some sort of validation from your customer that the STIG you 
author is valid for your systems.

The other complexity is that even if you go through either of those processes 
(CCI --> Arch STIG, or GPOS STIG --> Arch STIG), you still only have a document 
for manual evaluation.  Creating SCAP benchmarks for automated SCAP testing 
would be the next step you're looking for, and involves the hundreds of hours 
of time that I mentioned above.  It's not an easy task to undertake.

Hope this doesn't discourage you too much.  If I were in your shoes, I would do 
the work to create an approve Arch STIG based on either of those options, and 
then create your own means for applying and verifying those configurations on 
your system, using some method of configuration automation, rather than trying 
to tackle the steep learning curve that is SCAP.

Tom A.

--

Tom Albrecht III, CISSP-ISSEP, GPEN, RHCSA
Cyber Architect, Lockheed Martin RMS
thomas.c.albre...@lmco.com

-Original Message-
From: br...@signatureresearchinc.com [mailto:br...@signatureresearchinc.com] 
Sent: Monday, April 17, 2017 1:43 PM
To: scap-security-guide@lists.fedorahosted.org
Subject: EXTERNAL: Introduction and Questions

Hello,

My name is Tim Bradt. I am software developer at Signature Research, Inc. I 
have been charged with getting SCAP up and running on some of our systems.

We are running Arch Linux. I was wondering what the process would be for 
porting the RHEL7 guide to Arch as we need the DISA STIG for system approval.

Thanks for your help,
Tim
___
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-le...@lists.fedorahosted.org
___
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: EXTERNAL: Incorporating final DISA STIG / Release

[Albrecht, Thomas C]

It doesn't look like encrypted partitions were in the final STIG. 

Sent from my iPhone

> On Mar 24, 2017, at 3:57 PM, "goobs...@gmail.com"  wrote:
> 
> DISA has released a STIG for RHEL 7.  redhatrises updated an overlay to 
> account for the final release from DISA of RHEL7 STIG.  What additional work, 
> if any, needs to be done to SSG in order for oscap to be able to scan 
> relative to the final DISA STIG for RHEL 7?
> 
> When I clone the github repository, run cmake and examine 
> build/ssg-rhel7-ds.xml, it shows 
> xccdf_org.ssgproject.content_rule_encrypt_partitions select="true" for 
> profile *STIG for Red Hat Enterprise Linux 7 Server Running GUI*.  When I 
> load up the final RHEL7 STIG, I can't find any vulnerability related to 
> unencrypted partitions.  Am I missing the vulnerability in the STIG, or is 
> the SSG adding security checks to the profile?
> 
> Thanks,
> Chad
> ___
> scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org
> To unsubscribe send an email to 
> scap-security-guide-le...@lists.fedorahosted.org
___
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: EXTERNAL: Re: RFC: chef.io Inspec

[Albrecht, Thomas C]

My two cents on the tooling aspect

Based on this conversation, I started doing my own investigation of Inspec on 
our systems.  One thing that had me nervous was Ruby, since I know there’s a 
dependency hell that goes along with Ruby gems, and I wasn’t sure how much work 
would need to be done to get the right packages installed from the Red Hat 
repos.  However, the installation from the inspec.io website was a single RPM 
that has all the dependencies bundled into it.  This obviously has the benefit 
of being simple to install and maintain, and not needing to worry about which 
version of Ruby is installed on your system, but it doesn’t really mesh with 
the Unix philosophy of “Do one thing and do it well.”

For example, in the /opt/inspec/embedded/bin directory, there are 51 binaries, 
most of which are duplicates of binaries that Red Hat ships in their own 
packages.  I can’t see an easy path to altering the Inspec packaging to rely on 
Red Hat binaries, but I definitely can’t see Red Hat even considering allowing 
an application install its own version of the dependent tools, if only from a 
security perspective, since they’re embedding sensitive libraries like OpenSSL.

So, from an outsiders perspective, I can’t see an easy road to get the tools 
integrated into official RHEL repositories.

Tom Albrecht III, CISSP-ISSEP, GPEN, RHCSA

From: Shawn Wells [mailto:sh...@redhat.com]
Sent: Wednesday, March 22, 2017 10:58 AM
To: scap-security-guide@lists.fedorahosted.org
Subject: EXTERNAL: Re: RFC: chef.io Inspec

Really like the simplicity of Inspect! In my own world view, the only thing 
that really matters is automating the C compliance burden  and doing so with 
tools+content that people can actually use (SCAP or not, don't really care).

There are roadblocks to using Inspec: not natively included in enterprise 
operating systems, the US Gov doesn't recognize it as a configuration or 
vulnerability scanner, and results cannot be ingested by mandatory tooling like 
ACAS and various CDM tools. Same challenges that Ansible and Puppet face, too.

Out of the Ansible/Puppet/Chef grouping, Ansible is the only one with roadmap 
to be natively included in Linux. However Ansible 'check mode' isn't nearly as 
easy/robust as Inspec. Makes me feel a little stuck.

If content was developed for Inspec, how would people be able to consume it? 
Theoretically the @redhat.com'ers could finagle a way to ship the content. We 
certainly could upload it to the NIST National Checklist Program. But how would 
people get the Inspec tooling? I'm not sure if downloading off the internet is 
viable for most system owners.



On 3/22/17 10:05 AM, Trevor Vaughan wrote:
So, in my case, I'm working on the application and validation of different 
compliance profiles as part of the SIMP project.
In each of our configuration modules, I wanted to integrate an SSG scan into 
the final phases of our acceptance testing.
I probably should have said 'development framework' instead of 'demonstration 
framework'. But, the idea is that we can run regular acceptance tests as part 
of our CI process by integrating inspec into that mix.
We started down a path similar to inspec but abandoned it because we wanted to 
use the authoritative SSG materials so that we could show the C authorities 
an apples-to-apples comparison.
Unfortunately, this proved to be simply too complex since we could not extract 
micro data streams out of the SSG in an automated fashion. For example, we have 
an auditd module. For this, we would want to apply our settings against NIST 
800-53 and then test against the 800-53 SSG profile. We would then want to 
switch to STIG and test against the STIG profile, etc... However, we *only* 
want to do it for the auditd portions of the SSG and we just couldn't find an 
easy way to make this happen that didn't require a LOT of upkeep.
Thanks,
Trevor

On Tue, Mar 21, 2017 at 11:37 PM, Jason Newton 
> wrote:
Hi Trevor,

The hope is that any work with SSG, rigor included would be 10x less
cost of any lines of the SSG.  So it is a new cost but relative to
long term maintenance costs, it likely more than wins out - and
hopefully the SSG project would arrive at that point fast - in like a
month or two if someone puts in serious porting effort and starts
getting peer review going.

For running Inspec on production nodes - I went back and forth on my
reply here and my final thoughts are, well this is the double edge
sword of solving all integration and parsing problems by hosting the
DSL in ruby.  If all concerning functionally cannot be hidden (using
ruby-fu) prior to module loading without breaking functionality, then
there's not really much that can be done with this approach
fundamentally - perhaps they could make some validatable Inspec
DSL-based document (that is not ruby) for the InSpec DSL that is
runnable

Was not quite sure what you meant regarding validating demonstration
frameworks and 

RE: Kickstart from floppy wth SCAP and tailoring

[Albrecht, Thomas C]

Have you tried doing a manual install using the SCAP hardening in the install 
menu, and then stealing the code from the resulting anaconda.cfg that is 
generated in /root?

From: Robert Sanders [mailto:rsand...@forcepoint.com]
Sent: Friday, February 10, 2017 2:48 PM
To: scap-security-guide@lists.fedorahosted.org
Subject: EXTERNAL: Kickstart from floppy wth SCAP and tailoring

Hi all,
  Have a quick question - I'm looking at using a kickstart file to automate our 
OS install, but I also want to use the SCAP plugin to handle the initial 
lockdown of our images.  Looking at the 'tailoring-path' option to the anaconda 
plugin looks promising, but the docs indicate that the path for this option is 
relative to the archive being used.  Is there a way to specify the path so that 
it will the path from the 'floppy' image I'm using (currently booting by adding 
"linux ks=hd:fd0:ks.cfg"), or do I need to stand everything up as an 
http/https/ftp server and reference the SCAP contents and my tailoring file 
that way?

-Rob






___
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: EXTERNAL: RE: [Non-DoD Source] Re: RHEL 7 Draft STIG release

[Albrecht, Thomas C]

Roger,

I appreciate you making the choice to join this group, and I hope that being 
exposed to the process the SSG team is using will contribute to your 
organization making informed decisions. 

I need to be honest that your organizations's recent release of the draft Red 
Hat Enterprise Linux 7 STIG has given me a bit of extra stress at my company, 
as many programs that I support have been anticipating the STIG (and have 
identified risks associated with the release and amount of work that could come 
along with it). It's been tricky trying to explain to those programs how the 
draft relates to the output that Red Hat and the SSG group has produced. 

Could you take some time to explain the big picture on your release strategy 
for the RHEL7 STIG, and perhaps explain the big picture of the STIG process, 
the relationship and expectations between DISA and vendors, and what help 
defense contractors like myself who use vendor tools to produce solutions for 
the DoD can better work with your organization. 

As an aside, it would also be nice if you could open the PKI only areas of the 
DISA website available to contractor PKI cards. 

Tom Albrecht, CISSP-ISSEP, GPEN
Cybersecurity Architect Staff
Lockheed Martin MST

Sent from my iPhone

> On Feb 4, 2016, at 9:47 PM, Roger Greenwell  
> wrote:
> 
> Community Participants,
> 
> Earlier this week a post was made to this forum/thread that made disparaging 
> comments regarding DISA’s leadership over the STIG development process and 
> our contractor’s support in this effort.   I want to share with this group 
> that DISA government leadership is fully in charge of our actions/decisions 
> and our contract staff is there to provide support to us.  
> 
> Having just signed into this forum tonight, I noted the following from 
> Fedora’s Rules of Conduct:  “Be respectful. Not all of us will agree all the 
> time, but disagreement is no excuse for poor behavior and poor manners. We 
> might all experience some frustration now and then, but we cannot allow that 
> frustration to turn into a personal attack. It's important to remember that a 
> community where people feel uncomfortable or threatened is not a productive 
> one.”  To the author of this, WELL SAID
> 
> Shawn Wells, in his post, noted that DISA has been a cooperative partner in 
> the STIG process.  DISA greatly values the contributions and recommendations 
> from Red Hat and communities such as this, and it’s welcomed.   I would 
> simply ask that everyone please be respectful.  If there are concerns outside 
> of the technical area associated with this, please drop me a line and we can 
> discuss.  My email address is roger.s.greenwell@mail.mil.  
> 
> Respectfully,
> Roger Greenwell
> Chief, Cybersecurity – DISA
> --
> 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/
--
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/

Re: EXTERNAL: Re: RHEL 7 Draft STIG release

[Albrecht, Thomas C]

I've started doing my own work on this for my program, so I'd love to be 
involved in the work delegation. 

Thanks!

Sent from my iPhone

> On Jan 27, 2016, at 6:55 PM, Shawn Wells  wrote:
> 
> 
> 
>> On 1/27/16 2:40 PM, Crawford, Nicholas P CTR USARMY RDECOM CERDEC (US) wrote:
>> 
>> FYI,
>> 
>> In case any interested parties missed it during the inclement weather event, 
>> DISA has released the Draft STIG for RHEL 7 on 21 Jan.  The comment period 
>> is open until 12 Feb.
>> 
>> http://iase.disa.mil/stigs/os/unix-linux/Pages/index.aspx
> 
> To ease reading, I converted their XML to HTML:
> http://people.redhat.com/swells/U_Red_Hat_Enterprise_Linux_7_V1R0-1_Manual_STIG/html_edition.html
> 
> There's a high chance members of the OpenSCAP community will click that link 
> and have a serious case of "WTF is this?"
> 
> The RHEL7 STIG and USGCB baselines are to be based on the ~20 configuration 
> requirements from "Management of Security Functions Behavior" in the NIAP 
> Operating System Protection Profile:
> https://www.niap-ccevs.org/pp/pp_os_v4.0.htm#fmt
> 
> Those controls are being implemented in the OSPP profile:
> https://github.com/OpenSCAP/scap-security-guide/blob/master/RHEL/7/input/profiles/ospp-rhel7-server.xml
> 
> Prior to the formal recognition/issuance of a STIG or USGCB, a vendor must 
> complete their Common Criteria Certification. RHEL7 began that process in 
> June 2014 [0] and is expected to finish shortly.
> 
> In preparation for completion of Common Criteria, we sent our configuration 
> guide (derived from SSG's OSPP profile) to NIST and DISA FSO. Akin to RHEL6, 
> the arrangement was to use SCAP Security Guide as the upstream for the STIGs.
> 
> You can imagine the surprise when FSO published their draft STIG, which seems 
> to include the 129 configuration checks from our OSPP profile, but also tacks 
> on 279 net-new controls.
> 
> DISA FSO has been a cooperative partner in opening the STIG process, and 
> establishing open source principals for STIG development. We're working with 
> them to see why their draft STIG various so dramatically from the content 
> that was submitted to them.
> 
> In the mean time, it's incredibly important to start reviews of the DISA 
> draft STIG. This is an opportunity for you to express that you want DISA to 
> keep using open source developed content, and also to directly address the 
> random 279 new rules that mysteriously were dropped in. Some are just 
> blatantly wrong, and appear to be copy/pasted from RHEL5 content!
> 
> To facilitate comments, I've shared an edition of the DISA FSO comment matrix:
> http://bit.ly/1QtvF6v
> 
> This will become Red Hat's formal feedback to DISA FSO on their draft. If we 
> all work on a single feedback form, submitted independently through our own 
> companies, our independent voices for change would be greatly amplified.
> 
> There are ~400 controls in DISAs draft. Perhaps we could segment this up, and 
> take ownership of small chunks? This would ensure the OpenSCAP community is 
> able to provide feedback by the 12-FEB deadline. Once we're done with smaller 
> sections, we could review as a whole in a week or two. Would anyone be up for 
> this?
> 
> -Shawn
> 
> 
> [0] 
> https://www.redhat.com/en/about/blog/red-hat-enterprise-linux-7-evaluation-common-criteria-certification
> --
> 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/
--
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/

Re: EXTERNAL: Re: SIMP

[Albrecht, Thomas C]

Stupid phone.

I know Trevor has committed a lot of code.

Sent from my iPhone

On Jul 16, 2015, at 10:13 PM, Tom Albrecht 
talbr...@glamdring.orgmailto:talbr...@glamdring.org wrote:

I'm going to check it out tomorrow. I know Trevor Vaughn who committed a lot of 
coffee.

Sent using CloudMagichttps://cloudmagic.com/k/d/mailapp?ct=picv=6.4.12pv=8.2

On Thu, Jul 16, 2015 at 10:11 PM, SCAP Security Guide 
scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org
 wrote:
Hello, I would like to hear from the members on the list about how various 
projects in the SSG ecosystem relate to the recently disclosed SIMP from the 
NSA.  Obviously, it leverages the scanning tools that are part of the RHEL 
distribution.  Is it viewed as complimentary or redundant?

https://github.com/NationalSecurityAgency/SIMP


Mike Gallagher, CISSP, CEH
--
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-guide
https://github.com/OpenSCAP/scap-security-guide/
-- 
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/

securetty and hypervisor virtual consoles (hvc)

[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, ISGS
thomas.c.albre...@lmco.commailto:thomas.c.albre...@lmco.com
(m) 484-798-0109
(w) 610-354-7424

-- 
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/

RE: EXTERNAL: Frank Caviggia - Reporting for Duty (SCAP-SECURITY-GUIDE)

[Albrecht, Thomas C]

Hey, Frank.  Sorry to see you go, but I hope to interact with you even more
now that you're getting paid to do what I can tell you really enjoy. 

 

Tom Albrecht III, CISSP-ISSEP, GPEN || Information Assurance Engineer ||
Lockheed Martin JAGUAR Security Solutions || 610-354-7424

 

From: scap-security-guide-boun...@lists.fedorahosted.org
[mailto:scap-security-guide-boun...@lists.fedorahosted.org] On Behalf Of
fcavi...@redhat.com
Sent: Friday, September 20, 2013 1:06 PM
To: scap-security-guide@lists.fedorahosted.org
Subject: EXTERNAL: Frank Caviggia - Reporting for Duty (SCAP-SECURITY-GUIDE)

 

Hello,

I recently joined Red Hat as a consultant after eight years with Lockheed
Martin where I supported customers in DoD, DOE, and IC as System
Administrator/Engineer on Linux (particularly Red Hat), Solaris, and AIX. In
the past, sharing code with Red Hat was rather difficult due to the legal
requirements that Lockheed management placed on me (I felt like Indiana
Jones at the end of Raiders of the Lost Ark - where my code was sent away to
be reviewed by Top Experts, after which it was filed away in a envelope
and forgotten.)

I have a ton of scripting experience (particularly in BASH and Python) that
I've used to create and integrate into hardening scripts that I've used at
various customer sites. I'm looking forward to contributing this knowledge
to the scap-security-guide, particularly in some of the remediation scripts
and utilities that will help automate and prepare systems for CA (DIACAP
and ICD503 processes) required by our government customers.

If you have any questions, please feel free to reach out to me - my personal
cell phone is (575) 496-1206 and my email is fcavi...@redhat.com

I'm looking forward to writing some code and actually being able to have it
make an impact on the project.

Regards,

Frank Caviggia
Consultant
Red Hat



smime.p7s
Description: S/MIME cryptographic signature
___
scap-security-guide mailing list
scap-security-guide@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide