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?

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.

On 6/6/17 11:05 PM, Fen Labalme 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. IMHO it's scope creep to support every possible 3rd party solution. OS-level config checks should be scoped to evaluated native OS-level capabilities. With that said, for things that are configured through 3rd party means, how have you been getting by? Addendum to certification test plans? _______________________________________________ scap-security-guide mailing list -- scap-security-guide@lists. fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@ lists.fedorahosted.org

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&gt; 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@lists. fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@ lists.fedorahosted.org

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&gt; 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&gt; > 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&gt; >> 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

On Jun 7, 2017, at 9:00 AM, Brent Kimberley <Brent.Kimberley(a)Durham.ca&gt; wrote: >> I don't care for the thought of the network blocking all of my operations Operations shouldn’t block. I suggest an IGMP + loopback data pump....