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
On 6/6/17 10:01 PM, Trevor Vaughan 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?
DoD, NSA, NIST, and Red Hat contested this with DISA. DISA decided to go forward anyway. The broader consensus was to have things redirected through syslog (or rsyslog). That's where auditd_audispd_syslog_plugin_activated comes in:
https://github.com/OpenSCAP/scap-security-guide/blob/master/shared/templates...
And it's selected in the OSPP profile: https://github.com/OpenSCAP/scap-security-guide/blob/master/RHEL/7/input/pro...
Which is now part of the official USGCB draft: https://nvd.nist.gov/ncp/checklist/769
DISA has started working behind the scenes with Red Hat to triage their content with the draft USGCB and DoD consensus content (aka the OSPP profile). Hopefully things will shake out appropriately.
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 (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
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?
If you are using Graylog (ELK Stack) you want to use Filebeat. Using rsyslog also to simply satisfy a test seems overkill.
We have many cases of this; for example (maybe not the best one) we run AIDE from a cron.daily/aide file that mails results.
And yes, while we fail the SCAP tests, we have defined alternate tests in our configuration that confirm proper operation.
As we build out component level verification for OpenControl, we are finding additional tests are needed, too.
I can see that this diverges from a clean "Red Hat Way" but sometimes systems are different - and perhaps more secure?
Sometimes compliance can be the enemy of security.
=Fen
On Tue, Jun 6, 2017 at 11:23 PM, Shawn Wells shawn@redhat.com wrote:
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
I agree wholeheartedly which is why I found this to be a snag.
Rsyslog requires no additional infrastructure while auditd (direct) requires a working Kerberos infrastructure.
The former is (sort of) easy to test, the latter is easy to test in theory but there are a LOT of assumptions hanging around there.
Interesting to hear about the split, I'm definitely falling on the rsyslog camp.
Thanks,
Trevor
On Tue, Jun 6, 2017 at 11:23 PM, Shawn Wells shawn@redhat.com wrote:
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
On Wednesday, June 7, 2017 11:22:19 AM EDT Trevor Vaughan wrote:
Rsyslog requires no additional infrastructure while auditd (direct) requires a working Kerberos infrastructure.
TLS support is on the near term audit roadmap. It also is tricky because it introduces PKI and/or preshared keys. Which I am hoping is a lighter burden. In the meantime there is ssh tunnels and vpn.
-Steve
The former is (sort of) easy to test, the latter is easy to test in theory but there are a LOT of assumptions hanging around there.
Interesting to hear about the split, I'm definitely falling on the rsyslog
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 (410) 541-6699 x788 <(410)%20541-6699>
-- This account not approved for unencrypted proprietary information --
scap-security-guide mailing list -- scap-security-guide@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@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 (410) 541-6699 x788 <(410)%20541-6699>
-- This account not approved for unencrypted proprietary information --
scap-security-guide mailing list -- scap-security-guide@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.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@lists. fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@ lists.fedorahosted.org
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 (410) 541-6699 x788 <(410)%20541-6699>
-- This account not approved for unencrypted proprietary information --
scap-security-guide mailing list -- scap-security-guide@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.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@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
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.
From: Trevor Vaughan [mailto:tvaughan@onyxpoint.com] Sent: Tuesday, June 6, 2017 10:02 PM To: SCAP Security Guide scap-security-guide@lists.fedorahosted.org Subject: Audit Offloading in the EL7 STIG
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
-- This account not approved for unencrypted proprietary information -- THIS MESSAGE IS FOR THE USE OF THE INTENDED RECIPIENT(S) ONLY AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, PROPRIETARY, CONFIDENTIAL, AND/OR EXEMPT FROM DISCLOSURE UNDER ANY RELEVANT PRIVACY LEGISLATION. No rights to any privilege have been waived. If you are not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying, conversion to hard copy, taking of action in reliance on or other use of this communication is strictly prohibited. If you are not the intended recipient and have received this message in error, please notify me by return e-mail and delete or destroy all copies of this message.
On Jun 7, 2017, at 9:00 AM, Brent Kimberley Brent.Kimberley@Durham.ca 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....
I have no idea what that means, can you explain?
joe
I have no idea what that means, can you explain?
Use a distributed ledger.
broken telephone P(msg):=P(hop)^hops
Distributed ledger - at least P(msg):=MODE(P(hop)^2)
-----Original Message----- From: Joe Nall [mailto:joenall@gmail.com] On Behalf Of Joe Nall Sent: Wednesday, June 7, 2017 11:31 AM To: SCAP Security Guide scap-security-guide@lists.fedorahosted.org Subject: Re: Audit Offloading in the EL7 STIG
On Jun 7, 2017, at 9:00 AM, Brent Kimberley Brent.Kimberley@Durham.ca 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....
I have no idea what that means, can you explain?
joe _______________________________________________ scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org THIS MESSAGE IS FOR THE USE OF THE INTENDED RECIPIENT(S) ONLY AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, PROPRIETARY, CONFIDENTIAL, AND/OR EXEMPT FROM DISCLOSURE UNDER ANY RELEVANT PRIVACY LEGISLATION. No rights to any privilege have been waived. If you are not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying, conversion to hard copy, taking of action in reliance on or other use of this communication is strictly prohibited. If you are not the intended recipient and have received this message in error, please notify me by return e-mail and delete or destroy all copies of this message.
scap-security-guide@lists.fedorahosted.org