Charpiat, Robinson - Security in the Software Development Life Cycle

7/29/2019 Charpiat, Robinson - Security in the Software Development Life Cycle

http://slidepdf.com/reader/full/charpiat-robinson-security-in-the-software-development-life-cycle 1/4 THE ISSA JOURNAL ◆ January 2006

Software vulnerabilities could pose serious risks to business. Typical

risks include loss of confidentiality, integrity, and availability where

information or information systems are concerned. In many cases, strict

business requirements dictate access to an application from anywhere and

at any time. Hence, associated threats typically include hackers outside the

network perimeter and internal users too. Bottom line, protecting applica-

tions can be a challenge. The recommended approach towards safeguard-

ing applications is to include security as a key practice throughout allaspects of the software development life cycle.

A software development life cycle (SDLC) provides a structured

approach towards the development of information systems and software.

Although actual phases may vary across organizations, a typical SDLC

includes the following phases, which are the focus of this article:

▼▼ Requirements

▼▼ Design

▼▼ Development

▼▼ Quality Assurance

▼▼ Deployment

▼▼

Disposal

Integrating security with the application development process can be an easy

process, which could reap many benefits. Here are a few potential benefits:

▼▼ Cost and time savings, including proactive security measures

throughout the SDLC, could reduce time and effort spent on

reactive measures following production implementation.

▼▼ Outside-in perspective, including security practices, could provide

application areas with additional insight and considerations when

developing applications.

▼▼ Synergy and learning; depending on the organizational structure,

security professionals and application areas will usually need to

collaborate, which may bridge awareness and learning gaps, while

accomplishing a common goal.

Requirements Phase

Every application should stem from a set of business requirements.

Business requirements dictate a specific objective or process that must be

accomplished. Technical requirements expand on the concept by describ-

ing, at a high-level, the technology needed to achieve business require-

ments. No matter what, the success of the project often depends on

whether or not the business requirements were met. As a result, business

requirements should be very specific.

Consider the following recommendations as part of the Requirements

phase:

1.1. Determine the project sponsor and associated stakeholders. Having

such information should help to set a chain of authority for critical

aspects of the project.

2.2. Determine roles and responsibilities

a.a. Determine key tasks pertinent to integrating security in theSDLC. Next, determine which areas or human resources would

need to perform each task. You may use all the

recommendations in this article, to help identify key tasks. The

recommended approach to documenting roles and

responsibilities is to develop a RACI chart. The acronym “RACI,”

identifies the following:

1.1. R—indicates who is responsible for executing a given task

2.2. A—indicates who is accountable for a given task

3.3. C—indicates who must be consulted with for a given task

4.4. I—indicates who must be informed for a given task

3.3. Obtain business requirements; establish a clear understanding of

the business need or problem. Having a set of businessrequirements should help to set direction for all parties involved.

a.a. Business requirements should be clear, so all parties involved

know when the project was successfully accomplished.

b.b. Business requirements should have a scope. Consider the

following questions:

1.1. Who is the consumer; who will use it?

2.2. What level of accessibility is required; from where and at

what time?

3.3. What are the constraints facing the delivery of the

project? Every project faces constraints, which may

include time, money, and resources.

4.4. Based on the business requirement, determine the assets involved.

Identifying all assets is critical, because security revolves around

understanding what requires protection.

a.a. Assets may include data, up-time, system resources, human

resources, or reputation. However, where possible, focus on

tangible assets.

5.5. Determine the high-level security requirements.

a.a. Analyze the business requirements and assets provided.

b.b. Outline security requirements. In most cases, you will need to

assist the business client or other stakeholders with driving

security requirements. Be exact, tying each security

requirement to a specific use case or stage in the business

process. For each case, multiple security requirements may

Security in the Software

Development Life CycleBy Janeine Charpiat and Jarvis Robinson

[email protected]; [email protected]

©2006 Technical Enterprises, Inc. Reproduction of this document without permission is prohibited.


http://slidepdf.com/reader/full/charpiat-robinson-security-in-the-software-development-life-cycle 2/4©2006 Technical Enterprises, Inc. Reproduction of this document without permission is prohibited.

apply. Use one or more of the following pillars to describe the

security requirements:

1.1. Confidentiality

2.2. Integrity

3.3. Availability

4.4. Accountability

c.c. Check existing policies, standards, and legal regulations for

details that may help to mold security requirements and

minimize re-work.

Design Phase

During the design phase, technical architects and developers will define

the architecture that will support the aforementioned requirements. As a

result, consider requirements as a pre-requisite. Regarding security, the

design phase provides an early opportunity to identify threats and coun-

termeasures. Conversely, failure to address security in the design phase

could result in a host of security vulnerabilities that may go unaccounted

for until it is too late.

During the application design phase, you should review your corporate

security policies and procedures together with the infrastructure your

application is to be deployed on. Security policy determines what yourapplications are allowed to do and what the users of the application are

permitted to do. More importantly, they restrict what applications and

users are not allowed to do. Identify and work within the framework

defined by your corporate security policy while designing your applications.

Make sure you do not breach a policy that might prevent the application

from being deployed.

Consider the following recommendations as part of the Design phase:

1.1. Describe the application.

a.a. Review the proposed, or existing, architecture. For example,

assess the architecture diagram or design documentation;

create one if it does not exist.1.1. Identify logical and physical trust boundaries, drawing a clear

distinction between trusted and non-trusted components.

•• To avoid complexity, start with a broad base. For

example, the trust boundary for most web

applications is the DMZ (i.e. firewall). Moving

inward, the next trust boundary could be another

network within the DMZ (i.e. VLAN). Next, consider

the operating system, on the web server itself, then

web server, followed by the application server and

database, and so on.

2.2. Assess the proposed access points; access points are

places where data or control is passed. Attackers often

look for vulnerabilities in access points, in order to launch

an attack.

3.3. For each access point, determine the level of control

required for operation and management (i.e. permissions

assignment).

b.b. Given the business requirement, review the proposed use

cases. For each use case, at least determine:

1.1. Description

2.2. Pre-condition(s)

3.3. Actor(s)

4.4. Events

5.5. Post-condition(s)

2.2. Use the proposed design and use case(s) to identify threats and

vulnerabilities.

a.a. Examine the use case(s), along with the access points

identified; derive misuse cases based on each. Alternatively,

you may include an “Alternate Path” for each use case. The

misuse case, or alternate path, should illustrate what would

happen if the system was misused by an authorized or

unauthorized actor. Include a reference to the most impacted

asset, as determined in the requirements phase.

1.1. For each misuse case, identify the worst threat that could

arise. Consider the underlying asset, as mentioned in the

requirements phase. Here are a few examples:

2.2. Considering the asset and the worst threat involved,

assign a weight to each misuse case.

b.b. Maintain an account of the misuse cases; they can be reused

in latter phases.

3.3. Based on the weight assigned each misuse case, prioritize each case.

4.4. Given the priority assigned each misuse case, design countermeasures.

a.a. Although it is best to design preventative countermeasures,

reactive measures could be an option too (i.e. detection and

alerting). Either way, it is best to include some security, rather

than no security.b.b. The countermeasures should address the security

requirements stated earlier.

1.1. Don’t just rely on technology to address a need. Consider

that countermeasures may be achieved through people

and processes too.

c.c. Strive to design countermeasures that can be quantified for

effectiveness. Specifically, ensure there is a way to determine

whether the security requirement was met.

Development

During the development phase, developers will build, or reuse, codeaccording to the design specifications. Besides design flaws, coding flaws

could lead to security vulnerabilities. As a result, special emphasis should be

placed on security during the development phase. In addition, adequate time

should be invested in planning security testing, to ensure countermeasures

work as expected.

The cost of fixing application flaws grows exponentially as you progress

through the Software Development Life Cycle. Flaws not caught until the

deployment phase can cost nearly 100 times more to fix than earlier

phases in the SDLC (IBM).

Consider the following recommendations as part of the Development

phase:

1.1. Develop secure coding practices. Several publications exist, which

can be helpful. Here is a list of common areas to consider, when

developing secure coding practices:

a.a. Authentication

b.b. Authorization & Session Management

c.c. Input & Output Validation

d.d. Error Handling

e.e. Flow Control

f f .. Resource Allocation/Availability

g.g. Protecting Stored and Transmitted Data

h.h. Configuration Management

2.2. Include each countermeasure as part of the quality assurance

THE ISSA JOURNAL ◆ January 2006



planning;

a.a. Rely on the artifacts derived earlier,

such as the misuse cases. Don’t

leave it to an attacker to test for you.

b.b. The success criteria for each test

case should determine whether the

misuse was prevented or detected.

3.3. Include procedures for security controls in

supporting documentation. Poor or

insufficient information could lead to

human error. Human error could result in

security vulnerabilities.

a.a. Ensure that technical staff and end-

users have a solid understanding of

the security capabilities inherent in

the application.

b.b. Let them know what they should do

or who they should contact should

an unexpected event occur.

c.c. Avoid placing technical staff and

end-users in a position where it is

likely they will reach a poor decision.

Quality Assurance

The Quality Assurance phase is when devel-

opers, testers and users use systematic and

repeatable process disciplines which provide the

context for continuous and proactive quality

improvements. This phase is most often con-

fused with testing or an assumption is made

that because you have testing, quality assurance

is not necessary; this is not the case.

Consider the following recommendations aspart of the Quality Assurance phase:

1.1. Assure problems and misuse cases are

documented, corrected and used for

process improvement.

2.2. Assure problem reports are assessed for

their validity.

3.3. Assure reported problems and their

associated corrective actions are

implemented in accordance with

customer-approved solutions.

4.4. Provide feedback to the developer and the

user of the problem status.

5.5. Provide data for measuring and predicting

software quality and reliability. The

success criteria for each test case should

account for whether the misuse was

prevented or detected.

Testing the application is still necessary, but it

should follow the Quality Assurance guidelines.

Many popular forms of testing are listed below.

1.1. Use automated application scanners to

test major functional areas of applications.

Automated application scanners should

not be your only effort made to develop

the application securely.

2.2. Use human testing and interaction.

Manually typing in data can sometimes

yield an unexpected result. Many security

flaws require manual steps to accomplish

the security hole.

3.3. Application penetration testing is a step

beyond an application assessment. In a

penetration test, you may try to break

the application or even exploit the

security holes.

Deployment

Application security is dependent upon the

security of the underlying infrastructure on

which the application is deployed. Weak net-

work or host configuration settings result in vul-

nerabilities that can and will be exploited. Useautomated server and application scanners to

verify deployment servers are correctly secured.

A checklist and the respective components

which need security verification are listed below:

1.1. Operating System on Web Server:

a.a. Patches and updates

b.b. Services

c.c. Protocols

d.d. Accounts

e.e. Files and directories

f f .. Sharesg.g. Ports

h.h. Registry

i.i. Auditing and logging

2.2. Web Server:

a.a. Sites and virtual directories

b.b. Server certificates

c.c. Script mappings

d.d. Parent path settings

e.e. IP address and domain name

restrictions

3.3. Application Server:


b.b. Services

c.c. Protocols

d.d. Accounts


f f .. Ports

g.g. Registry

h.h. Auditing and logging

i.i. Application security

j. j. Application logins, users, and roles

4.4. Database Server:


b.b. Services

c.c. Protocols

d.d. Accounts


f f .. Shares

g.g. Ports

h.h. Registry

i.i. Auditing and logging

j. j. Database security

k.k. Database logins, users, and roles5.5. Network Configuration

a.a. Router

b.b. Firewall

c.c. Switch

Disposal

Information may remain on physical media

such as a hard drives, USB drives, CDs and flop-

pies even after deleted. The security policy will

dictate which method is applicable, but usually

it is related to the sensitivity of the data.Consider the following recommendations as

part of the Disposal phase:

1.1. Information Preservation—ensures that

information is retained, as necessary, to

conform to current legal requirements

and to accommodate future technology

changes that may render the retrieval

method obsolete.

2.2. Data Destruction/Media Sanitization–

ensures that data is deleted, erased,


References

1.1. Merely enter the follow search string, when using your favorite search engine: RACI chart

2.2. Threats and Countermeasures: https://threatsandcountermeasures.com

3.3. Microsoft Developer Network:http://msdn.microsoft.com/security/securecode/threatmodeling/default.aspx?pull=/library/en-us/dnpag2/html/tmwa.asp

4.4. Open Web Application Security Project: http://www.owasp.org

5.5. Secure Coding: http://www.securecoding.org

6.6. National Institute of Standards and Technology http://csrc.nist.gov/publications/nistbul/itl12-2003



over written, degaussed, and destroyed

as necessary.

3.3. Hardware and Software Disposal—ensures

that hardware and software is disposed in

accordance with your policy.

4.4. For encrypted data ensure long-term

storage of cryptographic keys.

According to NIST, 92% of reported vulnera-

bilities are in applications, not networks. Fixing

the problem at the right place, the source, is the

most beneficial. Thus, both the security analyst

and the developer must embrace security within

the SDLC process.

The security analyst will need to be engaged

from the beginning. They will need to understand

the information and types of users within the appli-

cation. Developers will need to educate them-

selves on secure coding, not just functionality.

Quality Assurance should track security bugs in the

same manner as functional bugs. Managers should

consider security as added value in an application.With all members of your team on board, a repeat-

able process in place, applications can be devel-

oped quickly, functionally, and securely.

Janeine Charpiat, CISSP, CIFI, is a security profes-

sional with more than eight years experience in the

security industry.

Jarvis Robinson, CISSP, NSA IAM, has over five years of

experience in the security field.

¡


Documents

Charpiat, Robinson - Security in the Software Development Life Cycle