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 <sgrubb@redhat.com> 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 -- scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org
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/scap-security-guide@lists.fedorahosted.org


--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699 x788

-- This account not approved for unencrypted proprietary information --