FIPS 140-2 only applies to FIPS certified modules, the algorithms in use are irrelevant from a policy point of view (within scope of course).

The general statement is that all sensitive or protected data must be protected by NSA or NIST approved cryptography, otherwise the data is considered unprotected (by policy).

So, the C&A stance is "would you be comfortable passing the same data in the clear in side a VPC"? If the answer is yes, then you're good, and non-approved TLS is just a 'best practice' measure and good to go.

If the answer is 'no', it's time to look for another solution (and/or file a feature request with the vendor).

Trevor

On Wed, Jun 7, 2017 at 11:54 AM, Fen Labalme <fen@civicactions.com> wrote:
Hi Trevor,

Not sure the issue you're referring to?
If the filebeat client and logstash server both have FIPS 140-2 certs, TLS communications should be compliant, no?

As I'm running them all on private networks inside a VPC with local logins disallowed, I'm not even sure why the encryption is necessary - if an attacker manages to get access to one of the servers, watching the traffic seems more difficult than simply reading the files...

=Fen


On Wed, Jun 7, 2017 at 11:17 AM, Trevor Vaughan <tvaughan@onyxpoint.com> wrote:
Hi Fen,

How did you solve the FIPS 140-2 issue with FileBeat?

I was wrestling with this one but I wasn't sure how it would hold up behind stunnel.

Thanks,

Trevor

On Tue, Jun 6, 2017 at 11:05 PM, Fen Labalme <fen@civicactions.com> wrote:
While rsyslog is an option, we use filebeat with SSL/TLS. Many ways to manage as you say. Testing and validation methods need to support tailoring.

=Fen


On Tue, Jun 6, 2017 at 10:01 PM, Trevor Vaughan <tvaughan@onyxpoint.com> wrote:
So, I was digging through and found the following:

RHEL-07-030300

The operating system must off-load audit records onto a different system or media from the system being audited.

and

RHEL-07-030310

The operating system must encrypt the transfer of audit records off-loaded onto a different system or media from the system being audited.

This poses a real problem since there are pretty much limitless methods to meet this requirement and, given that actual proof is multi-node, this is going to be *really* difficult to evaluate properly.

As much as I like auditd, I don't care for the thought of the network blocking all of my operations, so I've opted to pass it along to syslog. My syslog is then TLS encrypted to the various shipping points. This obviously meets the requirement, and I can automatically test that configuration in my code but I feel like this is yet another place where we're going to have difficulty with the SSG.

I also noticed that this one hasn't been implemented in the SSG and I'm guessing that this is why.

What are the plans for things like this moving forward?

Thanks,

Trevor

--
Trevor Vaughan
Vice President, Onyx Point, Inc

-- This account not approved for unencrypted proprietary information --

_______________________________________________
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org



_______________________________________________
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org




--
Trevor Vaughan
Vice President, Onyx Point, Inc

-- This account not approved for unencrypted proprietary information --

_______________________________________________
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org



_______________________________________________
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org




--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699 x788

-- This account not approved for unencrypted proprietary information --