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.

[an error occurred while processing this directive]

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.
Builder.com, created by developers for developers, brings you fresh, real-world perspective on programming, architecture, and management.
Join the most insightful software development site on the Web!

Previous page |   1 2

[an error occurred while processing this directive]

[an error occurred while processing this directive]