Security in the SDLC!

5 Mar

In todays post I will be focusing on the security aspect of the SDLC:

The following questions should be addressed in determining the security controls that will be required for a system:

How critical is the system in meeting the organization’s mission?
What are the security objectives required by the system, e.g., integrity, confidentiality, and availability?
What regulations and policies are applicable in determining what is to be protected?
What are the threats that are applicable in the environment where the system will be operational?

Reference: http://csrc.nist.gov/groups/SMA/sdlc/index.html

[Therefore] regular testing throughout the development cycle is also critical, as well as independent testing prior to release. Potential customers should seek assurance from vendors that their developers have been trained in good security practice, that they have formal security checks in place throughout the SDLC, and that they engage independent security testers before releasing product to their customers.

Reference: http://www.computerweekly.com/opinion/Build-security-into-the-entire-software-development-life-cycle

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.

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.

Reference: http://searchsecurity.techtarget.com/tip/Security-in-the-software-development-life-cycle

2 Responses to “Security in the SDLC!”

  1. sad112567137 March 7, 2013 at 10:58 pm #

    Great blog!:) I’m just wondering what an infosec is?

    • sad111322576 March 10, 2013 at 1:58 pm #

      Infosec is an abbreviation for Information Security!

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: