From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: New draft standards Date: Tue, 08 Dec 2015 15:25:22 -0500 Message-ID: <10524337.222XSUgHvY@x2> References: <3616972.XJnAnOOqWb@x2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Paul Moore Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com On Tuesday, December 08, 2015 02:58:18 PM Paul Moore wrote: > On Tue, Dec 8, 2015 at 2:22 PM, Steve Grubb wrote: > > Hello, > > > > I would like to point out 2 new standards that have been posted to the > > linux audit web page. The first establishes the events around system > > start up and shutdown. This is important because it sets the session > > boundaries for when a system is up or down or crashed. > > > > http://people.redhat.com/sgrubb/audit/system-lifecycle.txt > > > > The second standard is more of a forward looking standard. It explains how > > the audit daemon and utilities will perform event enrichment before being > > stored long term in an aggregator. The target for implementation is the > > 2.5 release of the audit daemon. > > > > http://people.redhat.com/sgrubb/audit/event-enrichment > > > > Let me know if anyone has feedback on these standards, especially the > > second one. > > Were these two specification documents created based on published > standards from an established standards body, e.g. NIST, IETF, etc? No. All of the standards published to date is documenting what exists and why. The needs are typically driven by common criteria and the need to detect certain kinds of events for intrusion detection or anomalous conditions. > If so, I think it would be helpful for you to reference the published > standard in your documents. If these specifications are an early > draft standard intended to be submitted to a standards body then I > would recommend mentioning the intended group in the document. No intention of that at this point. The main issue is that we have put a lot of patches into various utilities. We need other "like" utilities to follow the same rules. But when you say "follow the same rules", you need some rules published for them to follow. The side effect is that third parties can better write analysis programs without having to reverse engineer what the see in the event stream. They can go straight to the source and write a program to look for certain things. -Steve