Software Application Control and SDLC

(1)

©Albert J. Marcella, Jr., Ph.D., CISA, CISM 1

Software Application Control and SDLC

The most effective way to achieve secure software is for its development life cycle processes to rigorously conform to secure development, deployment, and sustainment principles and practices.

Organizations that have adopted a secure software development life cycle (SDLC) process have found almost immediately upon doing so that they have begun finding many more vulnerabilities and weaknesses in their software early enough in the SDLC that they are able to eradicate those problems at an acceptable cost. Moreover, as such secure practices become second nature over time, these same developers start to notice that they seldom

(2)

A proactive quality management strategy is to have multiple defect removal points in the software development life cycle.

The more defect removal points there are, the more likely one is to find problems right after they are introduced, enabling problems to be more easily fixed and the root cause to be more easily determined and addressed.

Each defect removal activity can be thought of as a filter that removes some percentage of defects that can lead to vulnerabilities from the software product.

The more defect removal filters there are in the software development life cycle, the fewer defects that can lead to vulnerabilities will remain in the software product when it is released.

More importantly, early measurement of defects enables the organization to take corrective action early in the software development life cycle.

(3)

Each time defects are removed, they are measured. Every defect removal point becomes a measurement point.

Defect measurement leads to something even more important than defect removal and prevention: it tells teams where they stand against their goals, helps them decide whether to move to the next step or to stop and take corrective action, and indicates where to fix their

(4)

The development team should consider the following questions when managing defects:

1. What type of defects lead to security vulnerabilities? 2. Where in the software development life cycle should

defects be measured?

3. What work products should be examined for defects? 4. What tools and methods should be used to measure

the defects?

5. How many defects can be removed at each step? 6. How many estimated defects remain after each

removal step?

End users, designers and developers are expected to maintain standards for the development of the application/software source code.

Their purpose is to increase application/software quality, by proper commenting, limiting module

complexity, systematic naming conventions, and other techniques.

Such standards are often dependent on the choice of programming language.

(5)

Coding Standards are NOT merely a way of enforcing naming conventions on your code.

Coding Standards enforcement IS static analysis of source code for:

1. Certain rules and patterns to detect problems automatically.

2. Based on the knowledge collected over many years by industry experts.

3. Virtual code review or peer review by industry respected language experts.

System Development Tools

What is Gantt Chart?

– Popular tool used to plan and schedule time

(6)

PERT

The Program Evaluation and Review

Technique (PERT) is a network model that

allows for randomness in activity

completion times.

An activity is a task that must be

performed and an event is a milestone

marking the completion of one or more

activities.

Before an activity can begin, all of its

(7)

PERT Diagram

Metrics are only useful if

you know what to do with

the answers you get.

(8)

A software metric is like a thermometer.

The fact that you measure something at 98.6° F

doesn't mean anything until you know what the

normal temperature is.

A temperature of 98.6 ° is good for body

temperature but really bad for ice cream.

13

Examples of Application Security Metrics2

Process Metrics

Is a SDL Process used? Are

security gates enforced?

Secure application

development standards and testing criteria?

Security status of a new

application at delivery (e.g., % compliance with

organizational security standards and application system requirements).

Existence of developer

support website (FAQ's, Code Fixes, lessons learned, etc.)?

% of developers trained,

using organizational security best practice technology, architecture and processes

Management Metrics

% of applications rated

“business-critical” that have been tested.

% of applications which

business partners, clients, regulators require be “certified”.

Average time to correct

vulnerabilities (trending).

% of flaws by lifecycle phase. % of applications using

centralized security services.

Business impact of critical

(9)

Examples of Application Security Metrics

2

Vulnerability Metrics • Number and criticality of vulnerabilities found. • Most commonly found vulnerabilities.

• Reported defect rates based on security testing (per

developer/team, per application)

• Root cause of “Vulnerability Recidivism”.

• % of code that is re-used from other products/projects • % of code that is third party (e.g., libraries)

• Results of source code analysis:

– Vulnerability severity by project, by organization – Vulnerabilities by category by project, by organization – Vulnerability +/- over time by project

– % of flaws by lifecycle phase (based on when testing

occurs)

(10)

This model was developed to aid organizations in formulating and implementing a strategy for software security.

It is maintained through the OpenSAMM Project as part of the Open Web Application Security Project (OWASP). This model is designed to be tailored to the specific risk environment each organization faces.

Software Assurance Maturity Model (SAMM)

The model focuses on four core business functions that are involved in software development:

1. Governance: processes and activities related to the way in which an organization manages its software development. 2. Construction: processes and activities related to the way an

organization defines the goals for and the creation of software within development projects.

3. Verification: processes and activities related to the way an organization validates and tests artifacts created throughout software development.

4. Deployment: processes and activities related to the way an organization manages the operational release of software it creates to a runtime environment.

(11)

Software Assurance Maturity Model (SAMM)

(12)

1. Governance: practices that help organize, manage, and measure a software security initiative

2. Intelligence: practices for collecting corporate knowledge used in carrying out software security activities throughout the organization

3. SDL Touchpoints: practices associated with analysis and assurance of particular software development artifacts and processes

4. Deployment: practices linked to network security and software maintenance organizations

Software Security Framework (SSF)

Integrating Security into

the Software Life Cycle

(13)

©Albert J. Marcella, Jr., Ph.D., CISA, CISM

Systems Development Life Cycle

• Project Initiation

• Classify the data that the system will process

• Determine if sensitive data absolutely must be collected and/or stored • Perform risk analysis based on known requirements & classification of data • Develop an initial IT System Security Plan

• Project Definition

• Identify, document & incorporate security control requirements into IT System design

specifications

• Develop evaluation procedures to validate that security controls • Update the IT System Security Plan to include controls

• Implementation

• Execute the evaluation procedures

• Conduct a risk assessment to evaluate overall system risk • Update the IT System Security Plan to include controls

• Disposition

• Require that data retention schedules are adhered to • Require that electronic media is sanitized prior to disposal

www.vita.virginia.gov

New Development

• Push security involvement to the front end of development:

– Security Design (for sensitive systems)

• Encrypted communication channels

• Sensitive information shall not be stored in hidden fields

– Application Development

• Application-based authentication shall be performed for access to data that is not considered publicly accessible • Support inactivity timeouts on user sessions

• Data storage must be separated from the application interface • Validate all input irrespective of source, focus on server-side • Implement a default deny policy for access control • Use the least set of privileges required for processing

• Internal testing must include one of: penetration testing, fuzz testing or source code auditing • Clear cached and temporary data upon exit

(14)

©Albert J. Marcella, Jr., Ph.D., CISA, CISM

Applications Procurement

• Work to incorporate language into contracts that includes:

– General

• Personnel, Security Training, Background Checks

• Vulnerabilities, Risks and Threats

• Application Development

– Development Environment

• Secure coding, Configuration management, Distribution, Disclosure, Evaluation

– Testing

• General, Source Code, Vulnerability and Penetration Test

• Patches and Updates

• Tracking Security Issues

– Delivery Of The Secure Application

• Self Certification

• No Malicious Code

– Security Acceptance And Maintenance

• Acceptance

• Investigating Security Issues

www.vita.virginia.gov Source: http://www.sans.org/appseccontract/

Legacy Applications

• Periodic application vulnerability scanning • Strong configuration management

• If vulnerabilities are identified:

– Each application may have specific challenges – Case by case analysis may reveal options:

• Easy fix • Virtualization

• Host based intrusion prevention • Application firewall technology • Third party integration

(15)

“Security enhancement” of the SDLC process

mainly involves the adaptation or

augmentation of existing SDLC activities,

practices, and checkpoints, and in a few

instances, it may also entail the addition of

new activities, practices, or checkpoints.

The key elements of a secure software life cycle process are:

1. Security criteria in all software life cycle checkpoints (both at the entry of a life cycle phase and at its exit)

2. Adherence to secure software principles and practices 3. Adequate requirements, architecture, and design 4. Secure coding practices

5. Secure software integration/assembly practices

6. Security testing practices that focus on verifying the dependability, trustworthiness, and sustainability of the software being tested 7. Secure distribution and deployment practices and mechanisms 8. Secure sustainment practices

9. Supportive tools

10. Secure software configuration management systems and processes 11. Security-knowledgeable software professionals

(16)

General Principles (Control Considerations) for

Secure Software Development

The following principles should guide the development of secure software, including all decisions made in producing the deliverables at every phase of the software life cycle.

1. Minimize the number of high-consequence targets

The software should contain as few high-consequence targets (critical and trusted components) as possible.

High-consequence targets are those that represent the greatest potential loss if the software is compromised and therefore require the most protection from attack.

Critical and trusted components are high-consequence

because of the magnitude of impact if they are compromised. This principle contributes to trustworthiness and, by its implied contribution to smallness and simplicity, also to dependability.

(17)

2. Don’t expose vulnerable and high-consequence components

The critical and trusted components the software contains should not be exposed to attack.

In addition, known vulnerable components should also be protected from exposure because they can be compromised with little attacker expertise or

expenditure of effort and resources.

This principle contributes to trustworthiness.

3. Deny attackers the means to compromise

The software should not provide the attacker with the means by which to compromise it.

Such “means” include exploitable weaknesses and vulnerabilities, dormant code, backdoors, etc.

Also, provide the ability to minimize damage, recover, and reconstitute the software as quickly as possible following a compromising (or potentially

(18)

In practical terms, this will require building in the means to monitor, record, and react to how the software behaves and what inputs it receives. This principle contributes to dependability, trustworthiness, and resilience.

3. Deny attackers the means to compromise

4. Always assume “the impossible” will happen

Events that seem to be impossible rarely are. They are often based on an expectation that something in a particular environment is highly unlikely to exist or to happen.

If the environment changes or the software is installed in a new environment, those events may become quite likely.

The software should be designed to guard against both likely and unlikely events.

(19)

5. Never make blind assumptions

Validate every assumption made by the software or about the software before acting on that

assumption.

6. Security software is not the same as secure software Just because software performs information security-related functions does not mean the software itself is secure. Software that performs security functions is just as likely to contain flaws and bugs as other software.

(20)

The main objective of software assurance is to ensure that the processes, procedures, and products used to produce and sustain the software conform to all

requirements and standards specified to govern those processes, procedures, and products.

Software security and secure software are often discussed in the context of software assurance. Software assurance in its broader sense refers to the assurance of any required property of software.

An increasingly agreed-upon approach for assuring the security of software is the software security assurance case, which is

intended to provide justifiable confidence that the software under consideration:

1. Is free of vulnerabilities;

2. Functions in the “intended manner,” and this “intended manner” does not compromise the security or any other required properties of the software, its environment, or the information it handles; and

3. Can be trusted to continue operating dependably under all anticipated circumstances, including anomalous and hostile environmental and utilization circumstances—which means that those who build the software need to anticipate such circumstances and design and implement the software to be able to handle them gracefully.