RE: AG004 Closure Sought

First of all, I try to consistently use the term "Audit Trail" or "generate
audit trail" to distinguish this meaning of Audit from the other. I believe
that this is a clearer terminology than passive vs. active, which could be
construed in a number of ways. Note that the meanings are related. A good
Audit Trail (noun) is a very useful thing to have when performing an Audit
(verb).

Second, WRT respect to the wording below, is the distinction between
activities, incidents and events important? Aren't they all just
security-related events?

Finally, although analyzing audit trails to discover intrusions sounds good,
but it is extremely rare in practice. (In the sense that the intrusion will
usially have been detected initially in some other way.) It may be very
useful for investigating an intrusion.

IMHO, the major benefit of a secure audit trail is deterrence against abuse
of authority. For example, in any system, somebody has to be empowered to
create user accounts, alter access rights and so on. However, if it is known
for a certainty that when the effects of unauthorized actions by authorized
users is discovered, it will be possible to determine who is responsible,
this will tend to deter insiders from abuse. Its like the cameras in the
ceiling in gambling casinos. The other side of the coin is that it can clear
the innocent from suspicion.

Hal

> -----Original Message-----
> From: Joseph Hui [mailto:Joseph.Hui@exodus.net]
> Sent: Monday, July 22, 2002 11:08 PM
> To: Steven A. Monetti; www-ws-arch@w3.org
> Subject: RE: AG004 Closure Sought
> 
> 
> 
> >From:	Steven A. Monetti [mailto:smonetti@att.com]
> >Sent:	Mon 7/22/2002 12:55 PM
> >To:	Joseph Hui; www-ws-arch@w3.org
> >Cc:	
> >Subject:	RE: AG004 Closure Sought
> >
> >Joe,
> >As per item 3 below, I would suggest auditing in the glossary
> >to be represented as:
> >  Auditing provides passive tracking and logging of 
> >  security-related activities, incidents, and events 
> >  (such as authentication events, unproven claims, or bad 
> >  signature occurrences). Administrator can securely managed 
> >  and analyze these audit records to take appropriate action 
> >  against antagonists.
> 
> Steve,
> 
> This is IMV a good one.
> 
> Now, looks to me your second sentence is mainly to justfy
> by examplication what auditing can do for administrators;
> so something like "The analysis of audit records is
> often an effective method of intrusion detection"
> may strike a common core to a wider audience.
> 
> Joe Hui
> Exodus, a Cable & Wireless service
> =========================================
> 
> 
> >Steve
> 
> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Joseph Hui
> Sent: Monday, July 15, 2002 2:40 AM
> To: www-ws-arch@w3.org
> Subject: AG004 Closure Sought
> 
> 
> 
> Hi all,
>  
> Recall that AG004 comprises AC006 (for security)
> and AC020 (for privacy).
>  
> In fulfilment of my action item assigned during the
> last concall to drive to closure AG004, I've organized
> the remaining sec/privacy issues as follows, in
> "easiest-first" order, for the WG's *final* deliberation.
>  
> 1) Passage of the following proposal sought:
>    In the interest of projecting a consitent tone in the sec req's,
>    use RFC2119 "MUST's" and "SHOULD's in all security requirements.
>    This entails the editors of the WSA Req doc -- Daniel Austin,
>    et al -- replacing the current "must's" and "should's"
>    in all AR006.* requirements.
>  
> 2  D-AR006.7: retain or remove: 
>    D-AR006.7 (pertaining to key management and key distribution)
>    is auxiliary to AR006.3 (Authentication), AR006.4
>    (Confidentiality), AR006.6 (Non-repudiation, ala digital
>    signature), etc.  So the ramification of dropping A-AR006.7,
>    in similar vein of our previously doing away with D-AR006.8
>    and D-AR006.8, is inconsequential wrt achieving AR006.1
>    through AR006.6.  
>    Please understand that at this juncture the call for
>    action is: fish or cut bait.  I.e., we either drop the
>    'D' from D-AR006.7, or drop D-AR006.7 entirely.
>    I'd be happy to clafify, if situation warrants, in the
>    interest of helping WG members to render an informed
>    decision.  However, it'd be very dispointing if we squander
>    our time noodling the definitions of "key management"
>    and "key distribution," much less fashioning new
>    or unorthodox interpretation to their general accepted
>    meanings.  [Ref: Public Key Infrastructure (PKI),
>    PKIX, X509, Kerberos, ...]
>  
> 3) D-AR006.12: retain or remove.
>    D-AR006.12 pertains to Auditing.
>    The term "Auditing" can have different meanings in
>    different contexts in computing.  The SFT will take
>    action to nail down the term in the glossary as what
>    it means in D-AR006.12, in the interest of the
>    WG's arriving at an informed decision.
>  
> 4) D-AR006.13: retain or remove. 
>    D-AR006.13 pertains to the adminstrative/management
>    aspect of security.  There has been a recent discourse
>    on whether this requirement should be migrated out.
>    The conclusion was: it should stay.
>    Though the requiment's wording is still negotiable,
>    it was considered adequate in capturing the spirit
>    during the last F2F in Paris.
>  
> 5) Privacy requirements to be solidified.
>    During the last F2F we did not get around to finalize
>    the verbiage for the Privacy req's.  So there seems
>    to be still considerable req-related work to be done.
>  
>    (Personally I have no expertise in Privacy.  
>    So the WG would be better served if Hugo would be
>    so gracious as to continue championing for Privacy,
>    ala Privacy discussions.  Hugo, pardon my punting
>    Privacy back to you; and THANKS! :-)
>  
> Comments are welcome.
>  
> Thanks,
>  
> Joe Hui
> Exodus, a Cable & Wireless service
>  
> 
> 
> 
> 
> 
>