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.