Subject: Statement of work

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 16 Jan 2002 08:37:18 -0800

> but it's interesting what can happen when there's no written 
> scope of work.

The problem here is that at the moment there is no commonly
agreed methodology for analysing and presenting a security model
in a form suitable for use in a standards process.

While the one line statement you give is a good start I think
we really need some means of adding structure to the analysis.

The approach that I have been using is currently proprietary
for the far from good reason that I have never had time to
write it up for the public. The case studies done for clients
are of course client confidential.

First off, I would observe that attempts to apply the 'waterfall'
model of requirements analysis fail in most applications and
particularly so in the security field. The main puspose of 
a waterfall model appears to be for use by consultants to allow
them to delay the customers expectation of a deliverable for as
long as possible (measured in billable hours).

So we are not really talking about a sequence of events used to
construct a structured security model, we are talking about 
a means of presentation. What I use is a combination of the
European Space Agency requirements analysis methodology and
the SAS 70 audit methodology.

The basic idea is that the report (I emphasize report, in fact
I often begin with controls or attacks) starts off analysing 
the assets under consideration:

Assets:
	[A-NAME]	The binding of a domain name to a protocol
			address
	[A-DEL]	The binding of a domain name to a delegation

Next we consider the risks. A risk is something that is
intrinsic to an asset. It may or may not be considered a 
threat depending on the circumstance. Using the standard
threat tree approach we consider the Confidentiality,
Integrity and Availability (CIA) risks of each information 
asset. If we were considering a physical asset we might consider
theft, loss and destruction. The idea of the methodology is
to facilitate the construction of a handbook giving the 
standard risks for specific assets.

Risks:
	[R-NAME-C]	Disclosure of the asset to an unauthorized party
	[R-NAME-I]	Modification of the asset
	[R-NAME-A]	Availability of the asset
	[R-DEL-C] [R-DEL-I] [R-DEL-A] ditto

Immediately we se that there are certain risks that are out 
of scope. We do not consider the confidentiality of the name
binding further because in our particular application it does
not constitute a threat.

We might consider the confidentiality of name lookups however.
to do this we would add in an asset to represent the retreival
process 'data in transit'.

Threats:
	[T-NAME-I]	Modification of the name binding
	[T-DEL-I]	Modification of the delegation binding
	[T-DEL-INS]	Insertion of a spurious delegation point
	[T-DEL-DEL] Deletion of a genuine delegation point
	[T-DEL-MOD]	Modification of a delegation point

Analysis of threats is an area where you frequently discover
additional assets that have to be considered. In this case for 
example I discovered that the NAME asset could only be secured
if the DEL binding was.

Here I would normally go through a lot of cycles to generate
perhaps twenty odd threats that were specific instances of 
the generic threat. This is where the record insertion issue
would appear for example.

Attacks:

Not formally part of the security model, but often a useful
adjunct. Attacks are simply very specific threats. In many
cases they are sumaries of actual attacks.

Controls:
	[C-SIG]	Delegation Record Signature
				Controls [T-DEL-MOD]
	[C-NXT]	NXT Record Signature
				Controls [T-DEL-DEL] [T-DEL-INS]
	[C-NXT-OPT] OPT-IN Record Signature
				Controls [T-DEL-DEL]

Consistency:

The next stage is to establish the consistency of the security
model:

Forward:
	Every Risk must be to an Asset
	Every Threat must realise a risk
	Every Attack must specialise a Threat
	Every control must control one or more threats

Backward:
	Every Threat must be controlled by at least one Control
		or be stated to be out of scope in the environment
	Every Risk must generate at least one Threat or be
		stated to be out of scope in the environment
	Every asset must consider the set of risks associated 
		with its class

In this particular instance it appears that the methodology should be
tewaked to allow separate consideration of specific environments.
This is something that we have done in the past by developing separate
security models for the different applications. However in this case
the degree of similarity between the environments (large zone, 
small zone) is very much greater.

Note that the above analysis is incomplete for DNSSEC as a whole,
I have only been focusing on the DNSSEC issues specific to NXT
and OPT in. This is actually quite usual, there are very few commercial
applications where it is possible to persuade a client to develop
a genuinely comprehensive security model, at least at my consulting
rates. The approach is rather more justifiable when you are writing
a specification and the effort will be reused a lot of times.

		Phill