On Thursday, January 10, 2019 1:12:40 PM EST Shawn Wells wrote:
On 1/10/19 12:56 PM, Steve Grubb wrote:
> On Thursday, January 10, 2019 11:24:20 AM EST Shawn Wells wrote:
>> On 1/9/19 8:54 PM, Trevor Vaughan wrote:
>>> DoD refined as requiring audit of all
>>> success/failed attempts to create/access/delete/modify files 
>>> Ugh... this thing*destroys* systems on a regular basis along with the
>>> chmod/chown rules. I get it but I've seen*so* many systems tanked by
>>> those rules.
>> Way the current Configuration Annex is written is that CNSSI 1253 and
>> DoD systems will need to audit every file I/O.
> It is almost the same as what is called out for by OSPP-4.2. Which you
> see here:
Those look like a good starting point! Prior to shipping, to meet OSPP,
those rules will need to also audit successful events (not just
Ref "Audit File and Object Events" from OSPP Config Annex:
Right. Look at the section for File events, first column:
Audit File and Object Events (Unsuccessful) AU-2a.
And I would go farther and say unsuccessful because of permission and not
because the file is missing or any other (useless) reason.
> AFAICS, CNSSI 1253 also wants accesses of configuration files. I
> say that is ill-advised. You may want failures due to permissions in
> accessing files. But with a lot of subsystems putting configuration
> in/usr/lib/ how do you tell what to monitor and what is applications?
> I'd say treat config files as any other file because they are too spread
> out and accessed constantly, like $HOME/.bashrc
Unfortunately there's no distinguishing between config vs other file
types. Currently *all* file and object events need to be audited for:
File and Objects events:
(1) Create (Success/Failure)
(2) Access (Success/Failure)
(3) Delete (Success/Failure)
(4) Modify (Success/Failure)
(5) Permission Modification (Success/Failure)
(6) Ownership Modification (Success/Failure)
To quote from it:
Together, the combination of a baseline and applicable overlay(s) represents
the initial security control set prior to system-specific tailoring.
IOW, its asking for capabilities that can be refined later. What I would like
to point to is an old Industrial Security Letter for NISPOM that I think
captures something important:
55. Question: Paragraph 8-602a(1)(c) can generate upwards to 100 audit
entries for each successful access to security-relevant objects and/or
directories. From a security standpoint, is this information of enough
importance to generate voluminous amounts of auditing data?
Answer: No. Only unsuccessful accesses need to be audited.
Requirement in question is:
8-602a(1)(c) Successful and unsuccessful accesses to security-relevant
objects and directories, including creation, open, close, modification, and
I think this ISL refinement is still generally correct. And I would also say
that you will should limit it to USER activity and not normal system