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

Received on Monday, 22 July 2002 23:07:03 UTC