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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >> 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 -- [email protected] >>> rahosted.org >>> To unsubscribe send an email to scap-security-guide-leave@list >>> s.fedorahosted.org >>> >>> >> >> _______________________________________________ >> scap-security-guide mailing list -- [email protected] >> 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@lists. > fedorahosted.org > To unsubscribe send an email to scap-security-guide-leave@ > lists.fedorahosted.org > >
_______________________________________________ scap-security-guide mailing list -- [email protected] To unsubscribe send an email to [email protected]
