Design for security up front

Of the five basic phases--initiation, development, implementation, maintenance, and decommissioning/disposal--often the need for security isn't realized until the implementation phase, and security measures not added until the maintenance phase. Even so, fixing many other system vulnerabilities is simply an afterthought, addressed with patches, service packs, or emergency hot fixes.

A well-secured system has security designed during initiation--not during implementation or maintenance--because service packs and patches applied after implementation can introduce other vulnerabilities, leading to a spiral of patching, fixing, and re-patching. The objectives of the initial phase are to define the need for the system, identify its purpose, and craft a system-specific security policy. The security policy is a vital product of this phase because it serves as the underpinning for the system and provides a solid foundation on which to build a trustworthy system.

Ensuring that security measures are included during initiation requires a few extra steps, including defining a security policy, evaluating the type of information to be processed, and identifying the system's sensitivity. For example, architects designing a human resource management system must determine how much of the system's data falls under the constraints of the Privacy Act of 1974. They would also need to ensure compliance is included in the design in addition to applying business rules, such as allowing only upper management to view performance reports. Architects of a banking system would perform the same assessment, but would delineate a completely different set of constraints.

First steps in determining the security requirements
During the initiation phase, the system's purpose is defined; typically, it's expressed with a mission statement or requirements definition statement. You also draft a problem description and eventually build a paper model from the system requirements. System architects also must assess the type of information to be processed, the information's sensitivity, and the system's sensitivity as a whole. It's during this phase that you will need to define the security requirements and express them in the context of a system-specific security policy.

I must emphasize the need for staying focused on the purpose of this preliminary phase. You must exercise caution because there is a tendency to over-define the solutions. The primary purpose of initiation is to nail down the system requirements. The goal of the security engineering effort during this phase is to identify the security requirements and define them in the context of a policy--a system-specific security policy. Sometimes overzealous engineers want to define everything up front, perhaps deciding on a language, database engine, and toolset before fully defining the system's purpose. I often have to fight this tendency in preliminary meetings. For example, a system designer might drill down too deep and determine that you need to create a separate social security table containing a foreign key to the customer table and employ Oracle column permissions so the numbers are well-protected. This level of detail falls well outside the scope of this phase.Define basic security requirements
The National Institute of Standards and Technology's (NIST) publication Engineering Principles for Information Technology Security states that system and security requirements should be derived during the development phase of the life cycle. While I agree that some requirements will be defined in greater detail during the development phase, the basic requirements should be documented during initiation in the security policy.

In the initiation phase, you define the problem at a high level, providing the developer a synoptic view of the system from the customer's perspective. The basic security objectives must be included in this bird's-eye view if security is to be a core part of the system design. The security policy should encompass the need for the system and the system's need to be deemed trustworthy. The primary goal of the security policy is to ensure the integrity, confidentiality, assurance, accountability, and availability of the system. A system that cannot be trusted will not be used.

For example, let's say I'm building a very simple application for measuring customer satisfaction for the purpose of increasing customer loyalty. The system centers on customer responses to satisfaction surveys. Part of the ancillary data is the salesperson information, company information, customer contact information, date of purchase, type of purchase, and amount of purchase. The company needs the system to help identify positive and negative trends in the sales arena, allowing management to curb negative trends and increase positive trends. Each salesperson can look at his or her own customer satisfaction rating and the store's satisfaction rating as a whole, but is not allowed to look at any other salesperson's scores. Neither can competing companies view each other's scores; however, all companies can look at the national averages. No one should be able to modify the scores once the customer has committed the results of the survey; for the data mined from the system to be useable, the results must be trustworthy.

After having the customer define the problem and generate a system-needs statement, I asked the customer to help define the security policy. The policy turned out to be fairly straightforward. Remember that the goal of the security policy is to address confidentiality, integrity, availability, accountability, and assurance.

The confidentiality of the data is addressed in that the sales associates can only view their results and a company average; companies can only view their results and a national average. Integrity is also addressed: No one is allowed to modify the scores. The customer wants the system to be available during normal business hours. Accountability is addressed with all completed surveys being able to be mapped back to a specific customer, along with the time and date they were completed and submitted. Lastly, there must be reasonable assurance that the system's inherent security mechanisms can protect the data entrusted to it. Although this is an abbreviated security policy, it met the objective.

Sensitive data
In addition to building a security policy during initiation, I would define interactions with other systems (external interfaces, for example) and determine whether the interfaces are trusted or not trusted, depending on how they are protected. The example application above is slated for implementation in a closed environment, and has no external interfaces.

The sensitivity of the data must be evaluated as well. For instance, if I store a customer's social security number (which I would avoid doing, in reality), I must consider the constraints dictated by the Privacy Act of 1974. All customer contact and financial information must be protected in accordance with the security policy.

In my example, scores are considered sensitive per the customer's direction--no one can modify scores, and only certain individuals can view them. Mechanisms to preclude unauthorized viewing of scores must be implemented during the next phase. The purpose of this phase is not to design the security solutions, but to determine what is needed.

Although I've oversimplified the security policy for the purposes of this article, realize also that other issues must be included, such as managing output and defining types of users and roles. Regardless, the policy has a clear goal: to describe from a security perspective the five crucial expectations of the system--integrity, confidentiality, accountability, availability, and assurance--and the data it contains.

Having built a foundation for securing the system and completing the objectives of initiation, you can then progress further into the life cycle and begin developing the application.

What security problems could your company have anticipated earlier in the development process? TalkBack below or e-mail us with your thoughts.