RE: D-AR006.11 discussion points

Darran,

What are the security primitives you use for Auditing?

Also, are you making the argument for 1) making Auditing 
as a req per se; or 2) making Auditing a req and elevating
it to a "Security Aspect/Facet" in the process?

Regards,

Joe Hui
Exodus, a Cable & Wireless service
==============================================

> -----Original Message-----
> From: Darran Rolls [mailto:Darran.Rolls@waveset.com]
> Sent: Wednesday, May 08, 2002 12:32 PM
> To: Christopher Ferris; www-ws-arch@w3.org
> Subject: RE: D-AR006.11 discussion points
> 
> 
> I can say that as a vendor of security products, security 
> relevant audit
> is considered by most as an integral part of a unified security
> infrastructure. I would second including this. 
> 
> As you are all no doubt aware, the AuthN and AuthZ are very often
> included with Audit and Administration to form the "Four A's" of
> security. I would like to propose we also include the fourth 'A' for
> Administration.  
> 
> The last two 'A's are often ignored as they are focused on the onward
> operation of a deployed service.  Ignoring the last two A's will
> doubtlessly restrict rollout, adoption and general success of a WS
> initiative.  I therefore propose adding "Administration" to the 6.
> 
> For the spaghetti western fans out there may I now say "and then there
> were 8" doo, doodle, doodle oo ;-)  - Magnificent Seven - 1960
> 
> --------------------------------------------------------
> Darran Rolls                      http://www.waveset.com
> Waveset Technologies Inc          drolls@waveset.com 
> (512) 657 8360                    PGP  0x8AC67C6F   
> --------------------------------------------------------
> 
> 
> -----Original Message-----
> From: Christopher Ferris [mailto:chris.ferris@sun.com] 
> Sent: Wednesday, May 08, 2002 2:00 PM
> To: www-ws-arch@w3.org
> Subject: Re: D-AR006.11 discussion points
> 
> Joe/Ayse,
> 
> 1) Please keep this, and all technical discussion, on the public
> mailing list.
> 
> 2) It seems to me that Joe is suggesting that the bulleted
> item under D-AR006.11 that says:
> 
> "There are six aspects in the security framework for Web Services
> architecture: Accessibility, 
> Authentication, Authorization, Confidentiality, Integrity, and
> Non-repudiation. Together they form 
> the foundation for secure Web Services."
> 
> is actually a separate requirement from D-AR006.11 and should 
> have been
> labeled D-AR006.12 in the document. Am I reading this 
> correctly? If so,
> then this needs to be fed to the editors as a comment so that it is
> certain to be tracked (and fixed in the next editor's draft).
> 
> The question I have then is whether or not Joe is accepting
> Ayse's request to add Auditing to this list of 6 aspects
> or whether he is suggesting that yet another requirement
> (D-AR006.13) be created to accomodate Auditing... do any others
> have an opinion on this?
> 
> Thanks,
> 
> Chris
> 
> Joseph Hui wrote:
> 
> >>From: Dilber, Ayse, ALASO [mailto:adilber@att.com]
> >>
> > [snip]
> > 
> > 
> >>D-AR006.11 the six aspects need to be replaced with the 
> >>following seven aspects of the security framework: 
> >>
> > 
> > Ayse, the D-AR006.11 number was taken.
> > You may want to re-number your proposal as D-AR006.12 instead
> > if you're serious about it (to be voted on or debated).
> > 
> > 
> >>Auditing; 
> >>
> > 
> > Auditing* as a security aspect?
> > Can you explain why?  E.g. for starter, how would you
> > characterize the threat (model) that's unique to Auditing?
> > Note that the impetus for requiring each of the original
> > six begins with a unique threat, or in some cases, threats.
> > 
> > 
> >>Authentication (includes identification and authorization);
> >>
> > 
> > Authc & Authz are separate sec aspects. 
> > 
> > Example 1: The security policy of the very system that you're
> > using probably includes only Authz but not Authc.  To login,
> > you simply enter user name and password, the system checks
> > the password file and lets you in.  You are not asked to
> > authenticate yourself as Ayse.  BTW, password file is known
> > to be one form of Access Control List (ACL).
> > 
> > Example 2: Alice's security policy includes Authc & Authz.
> > To join Alice's party, Bob must present a certificate to
> > Alice to authenticate himself as Bob -- Authc, AND, after
> > successful authc (sometimes aka positive identification),
> > Alice checks whether Bob is on her guest list (i.e. ACL)
> > before allowing him into her party.  
> >  
> > 
> >>Access Control (file permission, etc.);
> >>
> > 
> > Access Control is just a Authz means.  (See example 2 above.)
> > 
> > Cheers,
> > 
> > Joe Hui
> > Exodus, a Cable & Wireless service
> > ========================================================
> > 
> > 
> >>Confidentiality; 
> >>Availability; Integrity; Non-repudiation.
> >>Thanks,
> >>Ayse
> >>
> >>-----Original Message-----
> >>From: Christopher Ferris [mailto:chris.ferris@sun.com]
> >>Sent: Saturday, May 04, 2002 10:00 AM
> >>To: wsawg public
> >>Subject: D-AR006.11 discussion points
> >>
> >>
> >>SUNW: This requirement goes "inside" a web service and places 
> >>requirements
> >>on how it is designed.  We should be focusing on externally 
> observable
> >>(through the web service interfaces) behaviour
> >>
> >>SYBS: Implementation details. Don't seem to fit in Web 
> >>Services Architecture
> >>group..
> >>
> >>W3C: See 
> >>http://lists.w3.org/Archives/Public/www-ws-arch/2002May/0015.html
> >>
> >>ORCL: I don't quite see how "an architecture" can actually 
> provide an
> >>interface. And in this case the goal may be too ambitious given the
> >>number of different possible "infrastructures".
> >>
> >>PF: I just don't see the need for this.
> >>
> >>TIB: not clear to me that individual Web services would ever want to
> >>know whether they were under DOS at some lower layer
> >>
> >>CrossWeave: Don't understand this
> >>
> >>CMPQ: The interface is for negotiating services that an 
> >>infrastructure may
> >>provide to, or perform on behalf of, a requesting Web Services.
> >>Such value-added services may include: security, content delivery,
> >>QoS, etc. For instance, a Web service may instruct (via the 
> >>interface) the security
> >>agents of its infrastructure to defend against DOS/DDOS 
> >>attacks on its behalf.
> >>
> >>This seems to say that the requirement is
> >>"The security framework must provide for negotiations pertaining to
> >>security considerations."
> >>
> >>That is, the requirement is for negotiation support;  within 
> >>security context,
> >>it is security negotiation, within QoS context, it is QoS 
> >>negotiation, etc.
> >>
> >>
> >>
> > 
> > 
> 
> 
>

Received on Wednesday, 8 May 2002 18:06:36 UTC