Designing for Security
1 Introduction
The objective of this technique is to ensure that a design satisfies security requirements. The technique
is used during the production, validation and refinement of an Operational Model. It describes issues to
be considered, and how to approach the design and validation of security characteristics. It is applicable
to all systems.
As the Operational Model evolves throughout a project, it is common for different parts of it to be at
different levels of abstraction (and detail). The technique should be applied flexibly to reflect this (e.g.,
step 4 may be used in one part of the system before step 3 is used in another).
Prior to using this technique, overall security requirements for the system should have been captured in
non-functional requirements. As the Operational Model has been developed, some more specific or local
security requirements may already have been identified.
The sequencing of security analysis and design in relation to other work on the operational model varies
according to project circumstances. There are often tradeoffs with other objectives and requirements, for
example, delivering high security may compromise a need for high performance.
NOTE: Since this Technique Paper was written, significant additional security related material has been
added to the Method. Readers are urged to read the ‘Security and Privacy Requirements’ Work Product
Description in the method catalog to better understand the depiction of a more complete specification of
the requirements most applicable to a client’s business environment.
2 Refine Conceptual-Level Operational Model for Security
Security Implications?
Are there any SECURITY implications that must be obeyed?

Access to system?

Access to data?

Encryption?

Could a virus disable this system?

Physical security?

Mobile users?
Identify the security aspects of each conceptual node and point-to-point connection. Be aware that
security issues are easy to ignore but are a major factor in good system design. There must be a
balanced approach.

Too much security can make a system unusable.

Too little security can cause auditors (or others) to declare that a system should not be used.

Security does not come without costs. It consumes resources at the system level and at the
operational level.
You will often find that security facilities within a system structure require a repository of certain key
pieces of data. For example:

A set of passwords

A set of encryption keys

A list of authorized users or physical devices
The positioning of such repositories within the system structure may be a key design issue that you have
to decide now and refine later in the Operational Model. Some of the design considerations that you
should keep in mind when placing and defining these sorts of repositories are:

The actual security and ‘safeness’ of the repository. For instance, a LAN may not be a safe
environment.

The access patterns (sharing) and rates.

How the repository is updated.

The effect of losing the repository? Will the system work without it and if so, is it safe?

Recovery of the repository and any externally held data needed for this recovery.
Try to design your security facilities based upon service-oriented relationships if this is possible. Define a
security service; say on a LAN, which has clean interfaces that can be accessed by its clients.
3 Refine Specification-Level Operational Model for Security
Specified Node Security Requirements
Identify the SECURITY structure and techniques:

What security functions will be administered locally, what centrally?

Who will be responsible for security administration?

What physical methods should be used:





Secure rooms
Keylocks
Badge readers, signature recognition devices, etc.
Separation of components and/or data to different specified nodes or, if necessary, locations.
What logical techniques should be used:









Access control
User identification
User authentication processes - one-time logon or a separate logon to each application. (A single
logon implies that the communications function is aware of logon requirements and status and
automatically generates additional logons when required.)
Execution: how granular does control need to be?
Data: how granular does control need to be?
Other resources - terminals, tapes, etc.
Encryption - stored data and transmitted information
Audit tools and procedures
Virus prevention and detection tools and techniques
For each category of user identify the scope of access to be permitted and the system functions needed
to control this.

If special hardware is to be used, what additional recovery considerations apply to the node?
Connection Segment Security Requirements
What additional security measures are needed in the connection segments between the specified nodes?

Do the characteristics you identify indicate that you might need more than one connection segment
between the two specified nodes?

How sensitive is the data on each type of connection?

What threats is it exposed to?

What types of protection are needed:


Physical shielding
Encryption

Is sharing of physical connections acceptable (that is, does specific traffic require a physically secure,
separate network)?

Are there any special security considerations for mobile users who may be using public
communications?

If connection recovery is performed, will the security facilities continue to operate across the alternate
connection?

Can the security facilities be managed within the system management framework, or are other
facilities needed.
Anything else?
4 Refine Physical Operational Model for Security
General Guidance
It is possible that, so far, the selection process has not considered in fine detail the ability of the nodes
(now made up of products rather than specifications) to deliver the solution’s non-functional requirements,
and that you have documented the product selection directly into the various specified node box
diagrams. (In particular, this means that, for hardware specifically, you may have selected product
families rather than fully specified models.)
Therefore, you will need to conduct this step for all specified nodes.
It is quite possible that, in order to achieve the node’s non-functional requirements, you will want to
consider merging or splitting the specified nodes as you now transform them into physical nodes.
Security Methods and Products
What are the major objectives of security for this specific business system design?

Confidentiality (for example no unauthorized viewing)

Integrity (no change)

Safety (protection against willful destruction)
Each of these may require different or additional protection means, with confidentiality being the most
stringent. Do the requirements for security mean that part of the workload must be run on a separate
physical node? Which parts must be separated? For the network, various physical media (optical fiber,
microwave, wire) and physical access mechanisms (for example leased or dial-up connections) provide
divergent capabilities with respect to the above requirements.
Define how much of the required function is provided by the products and how much will have to be
provided by tailoring the products or by custom-built code for exits. If you are going to use any custombuilt code, what testing procedures will be needed to demonstrate that the system is secure?
Encryption and MAC coding may be required. With cryptographic components, ensure that the chosen
technology is permitted under export regulations for use in this geography for this application and by this
organization. For advice refer to your national export department even if only local usage is envisaged.