On 4/07/11 11:12 AM, Dean Pemberton wrote:
I'll get some time over the next few days to comment in more details.
Phew - finally got a few spare secs. It really looks a lot better. Here are a few sections where I think we could still improve this a bit. 4.1. Site Controls I'm really happy with the level of detail which has been added to this section. I think it outlines what physical security measures NZRS are proposing. The content is almost there in my opinion as well. The only outstanding issue is around access by non trusted personnel. At the Auckland and Wellington locations, the NZRS rack seems to be located in an area shared with other Co-Location clients. As such there is an increased risk that someone who is allowed access to the co-lo but not allowed access to NZRS equipment under this DPS might be able to gain access. It would seem that the only tier of security under *SOLE* NZRS control here is the lock on the front of the rack. Could I suggest the following additions. . State that the keys for the racks are custom cut and not the default for the rack provider. . State that the keys are under active control and signed out from an NZRS controlled when required . Consider adding a rack based alarm system under sole NZRS control. While it would be good, I don't believe this needs to be centrally monitored. A starting point would be one which would alert co-lo security that someone had opened the rack without authorisation. 4.3.1. Trusted roles Good addition to the roles here. How many of these roles are appointed at any one time? eg There are two SAs, 6 KSOs, 6 DSOs and 1IWs at any one time. Of these the following numbers must be present...blah "None of the operations previously described may be carried out in the presence of unauthorized people." I believe that you might want to have a capability to have moderated domain owners present at a key ceremony. In an observation capacity for eg. 4.4.2. Background check procedures "The NZRS security policy requires all new employees to be subject to pre-employment vetting includes reviewing of:" Thats a much better list than previous. It details what checks you will perform, but not what the outcome has to be. Is a conviction for unauthorised access to a computer system ok as long as it was over 5 years ago? Or are no convictions ok at all? How about the addition of something like (I've pulled these from places like other DPS statements or licensing requirements for security guards etc): NZRS will not consider persons for a position as a trusted individual if they have been: * convicted of a crime involving dishonesty or breach of trust. * convicted of a crime involving unauthorised access to a computer system. * disqualified from driving in the last 5 years. * identified to have a of a lack of financial responsibility * declared bankrupt. * identified to have a gambling or substance addiction. "Outsourced partners, contractors and sub-contractors are required to: Undertake pre-employment checks for new employees" This worries me a bit if NZRS is outsourcing the decision making around its personnel security to an outsourced partner. I'd be much happier here if NZRS didn't outsource any of the SA, KSO, DSO posisions outside of its direct employees. If they have to, then there should be a contracted responsibility for NZRS to perform the same background checks they would if they were employing the person. These should not be subcontracted to the outsourced partner. 4.4.4. Contracting personnel requirements "No person outside the Trusted Roles specified in Section 4.3.1 http://nzrs.net.nz/dns/dnssec/dps#DNSSECPracticeStatement-trustedroles can get access to the signer or signing material such as backups." Something that Michael Newbery picked up on earler. What ensure that this is the case? How about... "NZRS takes all care to ensure that no person outside the Trusted Roles specified in Section 4.3.1 http://nzrs.net.nz/dns/dnssec/dps#DNSSECPracticeStatement-trustedroles can get access to the signer or signing material such as backups. This is ensured through the following measures: * blah * blah * blah" So rather than just stating that it will never happen, show us how you'll ensure that it doesn't. 5.1.2. Public key distribution There are some uses of "SO" here. These should probably be changed to KSO. 5.2.2. Private key (m-of-n) multi-person control "During the HSM activation, all Keystore Security Officers and Device Security Officers needs to be present to be enrolled as such and activate the HSM. One System Administrator is required to get physical access. Multi-person control will be applied during the creation of a key backup and restoration." Three questions here: How many KSO and DSO officers are there? And once we know the N, whats the M? Are you using some form of hardware tokens to initialise or control access to the HSM? Or is it passcode only?