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 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 can get access to the signer or signing material such as
backups. This is ensured through the following measures:
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?