Day 5: Software Development Security

Presented by
Engr. Md. Mushfiqur Rahman
CISA, CISSP, OSCP, LPT (Master), PMP, CCISO, CISM, CRISC, CGEIT, CDPSE, CEH, ECSA, CHFI,
CLPTP, ISO 27001 LA, CND, COBIT5, MCP, MCSA, MCSE,MCTS, MCITP, OCP, CCNA, CCNP, OCP,
SCSA, Prince2, CTIA, CSA, ITIL, MCT, PCT, ECI, APMGCIT
Typical Phases of the System Lifecycle (SLC)

2
Software Development Lifecycle (SDLC)

3
SDLC vs. SLC
Project initiation Functional
and planning System design
(+ Management requirements specifications
buy-in) definition

Development
and Documentation Testing
implementation

Transition to Maintenance Decommissionin

production and use g and disposal

4
Project Initiation and Planning Security Activities

Required Security Activities

5
Functional Requirements Specifications Security
Activities

6
Detailed Design Specifications Security Activities

7
Development and Documentation Security Activities

8
Testing and Evaluation Controls
Test data should include the following:
• Data at the ends of the acceptable data ranges
• Various points in between
• Data beyond expected/allowable data points

Test with:
• Known good data
• Never live production data
• Sanitized data

9
Certification and Accreditation

Certification Accreditation

10
Testing , Acceptance, and Transition into

Production Security Activities

11
Decommissioning/Disposal
When an asset is being taken out of production and is
decommissioned or retired, the owner is accountable
for ensuring the following:

Media
Recovery
sanitization / Asset disposal
requirements
destruction

12
Revisions and System Replacement
• Periodic evaluations and audits
• Changes must follow SDLC and be recorded

13
Operation and Maintenance

• Monitor the performance of the system

• Ensure continuity of operations
• Detect defects or weaknesses
• Manage and prevent system problems
• Recover from system problems
• Implement system changes

14
Software Development Methods – Primary Models

Structured
Waterfall Programming Agile
Development

Spiral Method Cleanroom

15
Iterative Development

Rapid
Modified
Application
Prototyping Prototype
Development
Model (MPM)
(RAD)

Joint Analysis
Exploratory
Development Model
(JAD)

16
Other Methods and Models

Computer-Aided Software Component-Based

Engineering (CASE) Development

Reuse Model Extreme Programming

17
Software Development Methods

• Waterfall – each phase at a time

o Easy updates but does not scale to large, complex projects
• Spiral – combination of waterfall and prototype
o Risk assessment at each phase, with Go/No Go decision
• Iterative Development – multiple waterfall approach
o Successive refinements in requirements and design
• Joint Analysis Development – users and developers
o Focus on team of experts; used for mainframe systems
development

18
Software Development Methods (continued)
• Prototyping – build simple version first, then refine
o 4 steps: concept, design/build, refine, complete and release
• Rapid Application Development (RAD) – rapid prototype
o Strict time limits imposed to allow quick development
• Modified Prototype Model (MPM) – dynamic model that changes
over time as organization needs change
• Exploratory Model – research used to enhance existing model
• Reuse Model – object-oriented

19
Software Development Methods (continued)
• Cleanroom – zero defect approach
• Computer Aided Software Engineering (CASE) – for large,
complex projects
• Component-Based Development – standardized building block
approach
• Structured Programming Development – modular development,
high quality
• Extreme Programming – 80% function in 20% of the time
allotted, using small teams to keep it simple

20
Model Choice Considerations and Combinations
• Organizations are combining models.
• Security must be included in methodologies.

21
Capability Maturity Model (CMM) for Software or Software

Capability Maturity Model (SW-CMM)

• Focuses on quality management processes
• Five maturity levels

22
Software Capability Maturity Model (SW-

CMM) Levels

23
Operation and Maintenance

• Monitor the performance of the system

• Ensure continuity of operations
• Detect defects or weaknesses
• Manage and prevent system problems
• Recover from system problems
• Implement system changes

24
Change Management
Successful change management requires the following:

Benefits Effective
Effective
management education,
communication
and realization training

Monitoring of
Counter
the
resistance implementation

25
Typical Change Management Process Phases

26
Integrated Product and Process Development (IPPD)

Management technique that simultaneously integrates all essential

acquisition activities through multidisciplinary teams

27
DevOps

28
DevOps

Addresses lack of accountability

Bridges gap between all major
and disconnect in traditional
functions involved
development

Emphasizes collaboration
Cooperation is facilitated to between development, QA,
promote faster and better and Operations to ensure
deployments close alignment with
business objectives

29
Module 2
Secure Coding Guidelines and Standards

30
Module Objectives
1. Understand secure coding standards and guidelines.
2. Explain the evolution of programming languages and how
this relates to security.
3. Explain the benefits of libraries and toolsets.
4. Understand the value of integrated development
environments and runtime systems.
5. Understand security weaknesses and vulnerabilities at the
source-code level.
6. Explain how to secure application programming interfaces
(API) and secure coding practices.

31
Secure Coding Guidelines and Standards

Prevents traditional
Can be used by organizations
development where
to encourage developers to
developers coded based on
follow a standard set of rules
preference or familiarity

Several coding guidelines

Can be used to enforce proper
and standards exist in
security requirements
the industry

32
The Software Environment
This environment begins with the standard model of hardware
resources, with items such as the following:
• Central processing unit (CPU)
• Memory
• Input/output (I/O) requests
• Storage devices

33
Programming Languages

A programming language is a set of rules telling the computer

what operations to perform.

34
Programming Language Generations

Second
First generation Third generation
generation

Fourth
Fifth generation
generation

35
The Programming Procedure

Assembler: Compiler:
translates assembly translates high-level
language into machine language into machine
language language

Interpreter:
translates into machine
language each time

36
Object-Oriented Technology and Programming

Encapsulation Inheritance

Polymorphism

37
Polyinstantiation
• Allows different versions of the
same information to exist at different classification levels
• May be useful in preventing inference

38
Distributed Object-Oriented Systems
Allow applications to be divided into components that can
exist in different locations

39
Libraries and Toolsets

A software library consists of pre-written code, classes, procedures,

scripts, and configuration data.

40
Library Benefits

Increased Reduced Effective use of

dependability process risk specialists

Standards Accelerated
compliance development

41
Standard Libraries
A standard library in computer programming is the library made
available across implementations of a programming language.

42
Common Programming Language Libraries

The Framework
The C standard The C++
Class Library
library standard library
(FCL)

The Java Class The Ruby

Library (JCL) standard library

43
Programming Tools/Toolsets
A program or application that software developers use to create,
debug, maintain, or otherwise support other programs and
applications.

44
Integrated Development Environments (IDEs)
• Combine the features of many tools
• Maximize programmer productivity

45
Runtime
A runtime system is the collection of hardware and software
components of a system that allows a program to run,
regardless of the programming language used.

46
Security Weaknesses at Source Code Level and
Secure Coding Practices

There are a number of vulnerabilities at the source code

level that need to be addressed properly.

47
Activity: Security Weaknesses and Vulnerabilities at the

Source Code Level and Secure Coding Practices

INSTRUCTIONS:
Review each of the security weaknesses/threats on your own and be
able to explain them to someone else in the class. Understand how
security needs to be involved to mitigate the following vulnerabilities.
Memory
Buffer Citizen Covert Malformed
reuse (object
overflow programmers channel input attacks
reuse)

Executable Time of Check Trapdoor/

Between-the-
content/mobil vs Time of Use
lines attack backdoor
e code (TOCTOU)

48
Source Code Analysis Tools
• Designed to analyze source code to help find security flaws
• Used in software development phase so that issues are
addressed before implementation

49
Strengths of Source Code Analysis Tools
• Scale well
• Output is good for developers

50
Weaknesses of Source Code Analysis Tools

Many security Frequently

vulnerabilities are cannot find
False positives
difficult to find configuration
automatically issues

Difficult to prove Difficulty

analyzing code
actual that cannot be
vulnerability compiled

51
Security of Application Programming Interfaces
(APIs)

Application Programming Interfaces (APIs)

• Are the “messengers” that carry information between different
applications and systems so they can talk to each other
• Are the connectors for the Internet of Things (IoT), allowing our
devices to speak to each other
• Are the “unknown, unseen force”
• Must be protected or wrong messages could be carried to
components of architectures

52
Representational State Transfer (REST)
• A means of expressing specific entities in a system by URL
path elements
• Allows interaction with a web-based system via simplified URLs

53
REST-based API Security Recommendations
• Employ the same security mechanisms for your APIs as any web
application your organization deploys.
• Do not create and implement your own security solutions.
• Unless your API is a free, read-only public API, do not use single
key-based authentication.
• Do not pass unencrypted static keys.
• Use HMAC - hash message authentication code .

54
Authentication Options

Basic authentication
OAuth 1.0a
w/TLS

OAuth 2

55
Secure Coding Practices
The following are ways to address vulnerabilities at the source
code level

56
Reference Monitors

Ensures any subject

Protects the object from
attempting to access any
unauthorized access
object has the appropriate
attempts by bad actors
rights to do so

57
Security Controls for Buffer Overflows
A buffer overflow:
• Is caused by improper bounds checking on input to a program
• Must be corrected by the programmer or by directly patching
system memory

58
Controls for Incomplete Parameter Check and

Enforcement
• The lack of parameter checking can lead to buffer overflow
attacks
• Operating systems should offer some type of buffer
management

59
Process Isolation and Memory Protection
Ensure that multiple processes do not attempt to access the
same system resources at the same time

60
Covert Channel Controls
Communication channel allowing two cooperating processes to
transfer information in a way that violates the system’s security policy

61
Covert Channel Controls (continued)

Analyze these channels to

Identify potential
determine whether a channel
covert channels
actually exists

Manual inspection and

Address them properly
appropriate testing techniques
through security control
to verify if the channel creates
implementation
security concerns

62
Cryptography
Cryptographic techniques protect the confidentiality
and integrity of information

63
Password Protection Techniques
Operating system and application software use passwords as a
convenient mechanism to authenticate users

64
Control and Separation of Environments

Development Quality assurance

environment environment

Application
(production)
environment

65
Race Conditions vs. Time of Check vs. Time of Use

(TOCTOU) Attacks
• If there are multiple threads of execution occurring at the same
time, a TOCTOU attack is possible
• Takes advantage of the dependency on the timing of events that
take place in a multitasking operating system
• To avoid TOCTOU attacks, the operating system should use
software locking

66
Mobile Code Controls
Examples of threats to resources include:

Disclosure of Denial of service

information (DoS) attacks

Damaging or
Annoyance attacks
modifying data

67
Sandbox
Provides a protective area for program execution

68
Effectiveness of Software Security
• Evaluating the effectiveness of software security is important to
organizations and having an efficient and secure process for
developing applications needs to be in place
• Testing and assessing methods may include:
o Meaningful metrics
o Use cases
o Auditing and logging
o Certification and accreditation
o Risk management
o Change control
o Testing and verification

69
Certification and Accreditation

Certification:
The comprehensive technical Accreditation:
analysis of something to The management decision to
make sure it meets accept a solution
requirements

70
NIST SP 800-37 R1
The revised process extends certification and accreditation to emphasize:
• Building information security capabilities as part of the development
process
• Maintaining awareness to all stakeholders
• Providing essential information to senior leaders to drive the correct
decision

71
Risk Management Framework (RMF)
The risk management process changes the traditional focus of
C&A as a static, procedural activity to a more dynamic approach
to effectively manage information system-related risks

72
RMF Characteristics
• Encourages the use of automation
• Integrates information security
• Emphasizes selection, implementation, assessment, and
monitoring of security controls
• Links risk management processes at the information system
level to risk management processes at the organization level
• Establishes responsibility and accountability for security
controls
• http://csrc.nist.gov/groups/SMA/fisma/framework.html

73
Certification for Private Organizations
Why private organizations may choose certification:
• Control framework
• Low overhead
• Use of standards
• Includes all aspects of a system’s security

74
Auditing and Logging of Changes
Systems and network device reporting is important to the overall
health and security of systems

75
Logs
• Logs are records of actions and events that have taken place on a
computer system
• They provide a clear view of who owns a process, what action was
initiated, when it was initiated, where the action occurred, and why
the process ran
• They are primary record keepers of system and network activity

76
Auditing
The enterprise should have auditing policies in place that
effectively and efficiently collect information regarding critical
events in the form of logs and to manage them appropriately

77
Change Management
Organizations need to be able to plan for change, manage it
through a well-defined lifecycle, approve changes, document
change, and roll it back if required

78
Information Integrity, Accuracy, and Auditing

Information Information Character

integrity accuracy checks

Relationship Transaction Information

checks limits auditing

79
Risk Analysis and Mitigation
Risk: an event that has a probability of occurring and could have either
a positive or negative impact to a project should that risk occur

80
Risk Management
• An ongoing process that continues through the life of a project
• Includes processes for:
o Risk management planning
o Identification
o Analysis
o Monitoring
o Control

81
Testing and Verification
• When mitigations are implemented, they must be tested
• Development environments are supported with testing teams
and quality assurance

82
Testing and Verification Roles
• Security findings should be addressed the same as any other change
request
• The developer or system owner does not declare the risk mitigated
without concurrence of an independent verification and validation
(IV&V)

83
Code Signing
• Code signing
o A technique that can be used to:
− Ensure code integrity
− Determine who developed a piece of code
− Determine the purposes for which a developer intended a piece of code
to be used
• Certificates
o Digital certificates that will help protect users from downloading
compromised files or applications

84
Code Signature Components

Digital
Seal
signature

Unique
identifier

85
Code Signature Limitations

Cannot guarantee an app

Cannot guarantee a piece of
will not load unsafe or
code is free of security
altered code during
vulnerabilities
execution

Is not a DRM or copy

protection technology

86
Regression and Acceptance Testing
Whenever developers change or modify their software, even a
small tweak can have unexpected consequences

87
Regression Testing
• Tests existing software applications to make sure that a change
or addition has not broken any existing functionality
• Catches bugs that may have been accidentally introduced into a
new build or release candidate
• Ensures that previously eradicated bugs continue to stay dead

88
Acceptance Testing
A formal test conducted to determine whether a system satisfies
its acceptance criteria and to enable the customer to determine
whether to accept the system

89
Assess Security Impact of Acquired Software
Software assurance is the level of confidence that software is
free from vulnerabilities, either intentionally designed into the
software or accidentally inserted at any time during its lifecycle,
and that it functions in the intended manner.

90
Software Assurance in the Phases of Acquiring
Software

Planning Contracting

Monitoring and
Acceptance Follow-on

91
Planning Phase
Needs determination:
• Develop software requirements
• Create an acquisition strategy
• Develop evaluation criteria and an evaluation plan

92
Contracting Phase

Create/issue the Evaluate supplier

solicitation or RFP proposals

Finalize contract
negotiation

93
Monitoring and Acceptance Phase

Establish and consent to Implement change

the contract work schedule control procedures

Review and accept

software deliverables

94
Follow-on

Disposal or
Sustainment decommissioning

95
Software Assurance Policy
Ensure a well-documented software assurance policy and
process is in place in the enterprise

96
Risks Associated with Software Vulnerabilities
• Unintentional errors
• Intentional insertion of malicious code
• Theft of vital information
• Theft of personal information
• Changed product
• Inserted agents
• Corrupted information

97
Acquisition Process
System and software assurance focuses on the management of
risk and assurance of safety, security, and dependability within
the context of system and software lifecycles

98