OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ekmi message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [ekmi] Groups - EKMI Policy Guidelines (DRAFT PDF) v1.0(EKMI-Policy-Guidelines-1.0.pdf) uploaded


Thank you Tomas.  I will review this and incorporate it into
the PG document.  Feel free to send such information to
the TC list; I am sure others will be welcome the opportunity
to review and add their feedback and input.

Arshad

----- Original Message -----
From: Tomas Gustavsson <tomas@primekey.se>
Date: Wednesday, June 27, 2007 6:40 am
Subject: Re: [ekmi] Groups - EKMI Policy Guidelines (DRAFT PDF) v1.0 (EKMI-Policy-Guidelines-1.0.pdf) uploaded

> 
> Hi Arshad,
> 
> The policy guidelines contains some general issues, which are the 
> same 
> for PKI and SKMS. There is one general guideline for SKMS, SKMSG-
> 9, that 
> also should apply to PKI.
> 
> In the PKI guidelines I will now only refrence to the policy 
> guidelines 
> document. Below is some text that I had written there before the 
> policy 
> guidelines were produced. Perhaps there is something interesting 
> in there.
> 
> Cheers,
> Tomas
> 
> 
> -----
> A best practice policy should balance the cost of a certain action 
> against the benefit, and the cost of a breach of security due to a 
> lower 
> level of protection. An example of such balance is requirement for 
> separation of duties for the staff operating the PKI. Strict 
> separation 
> of duties will require lots of staff, only to operate your PKI. If 
> the 
> persons operating the PKI are the same persons operating some of 
> the 
> systems using the PKI for protection, separation of duties for the 
> PKI 
> is unlikely to enhance the security on the organization. In that 
> case it 
> is probably better to allow single, trusted, persons to maintain 
> several 
> roles and spend money on other issues more likely to enhance security.
> 
> The cost of a potential security breach should always be 
> calculated when 
> determining the policy. The cost of the security system should 
> never be 
> higher than the objects actually protected. This is something only 
> the 
> organization itself can calculate.
> 
> A best practice policy for a middle- to large size organization 
> for a 
> PKI used primarily for EKMI could have he following features:
> - Requires a hardware security module. The same level of HSM used 
> both 
> for PKI and EKMI.
> - Logging of all security related events in the PKI should occur 
> to a 
> separate log server with limited access.
> - Trusted staff members are allowed to administer the PKI and 
> register 
> new entities. Other staff members should perform audit.
> - There must be some process of approving trusted personnel, and 
> only 
> trusted personnel are allowed to handle the PKI systems. 
> Contractors can 
> not handle the PKI systems without surveillance by trusted personnel.
> - Dual person control is required for backup and restore of CA 
> signature 
> keys. The PKI servers  must be located in a separate, locked, part 
> of 
> the server room. Only trusted PKI personnel can access this room.
> - Availability is 24/7, 99.9%. Disaster recovery should be on the 
> same 
> level as other critical systems using the EKMI.
> - An approval process by management is required before issuing 
> certificates to new systems.  Enrollment for certificates can be 
> done by 
> trusted personnel, or require at least a shared secret transferred 
> out-of-band to a technician performing the installation and 
> enrollemnt.- Revocation information must be made available to the 
> EKMI not more 
> than 24 hours after revocation occurred.
> - No particular compliance is needed.
> - No warranties.
> -----
> 
> Arshad Noor skrev:
> > Thanks for the comments and suggestion, Mike.  I will make
> > the global change; I agree with you.  For the other changes,
> > I'll wait until all the comments are in before I put out
> > another DRAFT.
> > 
> > Question for the rest of the TC: would June 30 be acceptable
> > as a deadline to get feedback on the policy guidelines?  Or
> > do we need a little more time?  Thanks.
> > 
> > Arshad Noor
> > StrongAuth, inc.
> > 
> > Mike Nelson wrote:
> >> My comments can be found in the attached.
> >>
> >> I didn¹t make this edit, but I¹d suggest a global change from 
> >> ³company² or
> >> ³companies² to ³organization² or ³organizations² (or perhaps
> >> ³organisations²).  That will make it read better to those who 
> don¹t 
> >> work for
> >> a ³company² (i.e., a federal agency).
> >>
> >>
> >>
> >> On 6/14/07 2:57 PM, "arshad.noor@strongauth.com"
> >> <arshad.noor@strongauth.com> wrote:
> >>
> >>
> >>> Hi,
> >>>
> >>> Ken Adler provided a source document with some key-management
> >>> policy
> >>
> >> guidelines distilled from PCI-DSS and some real-world experience.
> >>
> >>> (Thanks
> >>
> >> Ken).  They are meant to be the driver for the EKMI Implementation
> >>
> >>> &
> >>
> >> Operations Guidelines, the prime deliverable of this SC.
> >>
> >>> I have organized the document along PKI and SKMS and listed the
> >>> guidelines
> >>
> >> with a brief explanation under each.  Please review, critique and
> >>
> >>> provide
> >>
> >> your feedback on errors, ommissions, etc.
> >>
> >>> Thanks.
> >>>
> >>> Arshad Noor
> >>> StrongAuth, Inc.
> >>>
> >>> P.S. The next message will include an editable ODT document.
> >>
> >>
> >>  -- Arshad
> >>
> >>> Noor*
> >>
> >>
> >> The document named EKMI Policy Guidelines (DRAFT PDF)
> >>
> >>> v1.0
> >>
> >> (EKMI-Policy-Guidelines-1.0.pdf) has been submitted by Arshad 
> Noor* to
> >>
> >>> the
> >>
> >> EKMI SKMS Implementation and Operations Guidelines SC document
> >>
> >>> repository.
> >>
> >>
> >> Document Description:
> >> A DRAFT (PDF) document that provides some
> >>
> >>> policy guidelines for an EKMI
> >>
> >> (consisting of PKI + SKMS).  These guidelines,
> >>
> >>> once refined and accepted,
> >>
> >> will be used to create the Implementation &
> >>
> >>> Operations Guidelines by this
> >>
> >> SC.
> >>
> >> View Document
> >>
> >>> Details:
> >>
> >> http://www.oasis-open.org/apps/org/workgroup/ekmi-
> implementation/docu>>
> >>> ment.php?document_id=24364
> >>
> >>
> >> Download Document:
> >>
> >> http://www.oasis-open.org/apps/org/workgroup/ekmi-
> implementation/download.php 
> >>
> >>
> >>> /24364/EKMI-Policy-Guidelines-1.0.pdf
> >>
> >>
> >>
> >> PLEASE NOTE:  If the above links do
> >>
> >>> not work for you, your email application
> >>
> >> may be breaking the link into two
> >>
> >>> pieces.  You may be able to copy and paste
> >>
> >> the entire link address into the
> >>
> >>> address field of your web browser.
> >>
> >>
> >> -OASIS Open Administration
> >>
> >>
> >>
> >>
> >> -- 
> >> Mike Nelson, CAP, CISA, CISM, CISSP, ITIL
> >> mnelson@securenet-technologies.com or mrfisma@gmail.com
> >> www.securenet-technologies.com or www.fisma.us
> >> blog: mrfisma.com
> >>
> >>
> >>
>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]