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(a)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(a)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(a)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(a)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
>>> (410) 541-6699 x788 <(410)%20541-6699>
>>>
>>> -- This account not approved for unencrypted proprietary information --
>>>
>>> _______________________________________________
>>> scap-security-guide mailing list -- scap-security-guide(a)lists.fedo
>>>
rahosted.org
>>> To unsubscribe send an email to scap-security-guide-leave@list
>>>
s.fedorahosted.org
>>>
>>>
>>
>> _______________________________________________
>> scap-security-guide mailing list -- scap-security-guide(a)lists.fedo
>>
rahosted.org
>> To unsubscribe send an email to scap-security-guide-leave@list
>>
s.fedorahosted.org
>>
>>
>
>
> --
> Trevor Vaughan
> Vice President, Onyx Point, Inc
> (410) 541-6699 x788 <(410)%20541-6699>
>
> -- This account not approved for unencrypted proprietary information --
>
> _______________________________________________
> scap-security-guide mailing list -- scap-security-guide(a)lists.fedo
>
rahosted.org
> To unsubscribe send an email to scap-security-guide-leave@list
>
s.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 --