Security in SDLC

The software development life cycle

The software development life cycle, or SDLC, encompasses all of the steps that an organization follows when it develops software tools or applications. Organizations that incorporate security in the SDLC benefit from products and applications that are secure by design. Those that fail to involve information security in the life cycle pay the price in the form of costly and disruptive events.

In an organization that's been around for several years or more, the SDLC is well-documented and usually includes the steps that are followed and in what order, the business functions and/or individuals responsible for carrying out the steps and information about where records are kept.

A typical SDLC model contains the following main functions:

• Conceptual definition. This is a basic description of the new product or program being developed, so that anyone reading it can understand the proposed project.
• Functional requirements and specifications. This is a list of requirements and specifications from a business function perspective.
• Technical requirements and specifications. This is a detailed description of technical requirements and specifications in technical terms.
• Design. This is where the formal detailed design of the product or program is developed.
• Coding. The actual development of software.
• Test. This is the formal testing phase.
• Implementation. This is where the software or product is installed in production.

Each major function consists of several tasks, perhaps documented in flowchart notation with inputs, outputs, reports, decisions and approvals. Some companies build workflow applications to support all of this.

Getting the right security information to the right people

Many people in the entire development process need all kinds of information, including security information, in a form that is useful to them. Here is the type of information that is required during each phase of the SDLC.

• Conceptual -- Organization information security principles and strategies
• Functional requirements and specifications -- Information security requirements
• Technical requirements and specifications -- Information security requirements
• Design -- Enterprise security architecture and security product standards
• Coding -- Development standards, practices, libraries and coding examples
• Testing -- Test plans that show how to verify each security requirement
• Implementation -- Procedures for integrating existing authentication, access controls, encryption, backup, etc.

If you are wondering why maintenance is omitted from the life cycle example here, it is because maintenance is just an iteration of the life cycle: when a change is needed, the entire process starts all over again. All of the validations that are present the first time through the life cycle are needed every time thereafter.

Finally, one may say that these changes represent a lot of extra work in a development project. This is not the case – these additions do not present that much extra time. These are but small additions that reap large benefits later on.

Approval: Moving to the next step

Organizations that use a software development life cycle process usually have approval steps at each major function. This takes the form of some kind of an approval meeting with the right stakeholders present: generally you find managers, directors, occasionally a VP – the people who control budgets, resources and business priorities.

Someone who represents information security should be present and have the authority to vote at most, if not all, major steps in the life cycle. If someone representing infosec is not present at a life cycle approval meeting, then there is a risk that a project lacking some key security component will be approved, only to become a problem in the future.

Fix it now or pay the price later

Organizations that fail to involve information security in the life cycle will pay the price in the form of costly and disruptive events. Many bad things can happen to information systems that lack the required security interfaces and characteristics. Some examples include:

• Orphan user accounts (still-active accounts that belong to employees or contractors who have left the organization) that exist because the information system does not integrate with an organization's identity management or single sign-on solution.
• Defaced Web sites as a result of systems that were not built to security standards and, therefore, include easily exploited weaknesses.
• Fraudulent transactions that occur because an application lacked adequate audit trails and/or the processes required to ensure they are examined and issues dealt with.

You should figure that problems like these are all costly to solve – in most cases far more costly than the little bit of extra effort required to build the products or applications correctly in the first place.