That is all amazingly useful information to have! We really need to make a FOSS mind map of this stuff somewhere.
On Thu, Jan 10, 2019 at 2:09 PM Steve Grubb <[email protected]> wrote: > 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-> > > 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 > > _______________________________________________ > scap-security-guide mailing list -- > [email protected] > To unsubscribe send an email to > [email protected] > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedorahosted.org/archives/list/[email protected] > -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 x788 -- This account not approved for unencrypted proprietary information --
_______________________________________________ scap-security-guide mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/[email protected]
