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 [2]
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 can see here:
https://github.com/linux-audit/audit-userspace/blob/master/rules/30-ospp-%3E > v42.rules
Those look like a good starting point! Prior to shipping, to meet OSPP, those rules will need to also audit successful events (not just unsuccessful).
Ref "Audit File and Object Events" from OSPP Config Annex: https://www.niap-ccevs.org/MMO/PP/424.CANX/
Right. Look at the section for File events, first column:
Audit File and Object Events (Unsuccessful) AU-2a.
Specifically, unsuccessful.
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 would 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:
https://fas.org/sgp/library/nispom/isl0101.htm
-------- 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 deletion.
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 operation.
-Steve