Introduction to Secure SDLC
Johannes Sianipar
20 Januari 2025
The most important thing is to find out what is the
most important thing.
—Shunryu Suzuki
Secure SDLC
Chart 2
Software Security
■ Idea of engineering software so that it continues to function correctly
under malicious attack
■ The idea is not new but it has received renewed interest
□ Network-based security approaches such as firewalls have proven to
be ineffective
□ Design flaws and implementation bugs
– resulting in unacceptable security risk
Secure SDLC
Chart 3
Software Security (Cont.)
■ Software security is about understanding software-induced security risks
and how to manage them.
□ involves thinking about security early in the software lifecycle,
knowing and understanding common problems (including
language-based flaws and pitfalls), designing for security, and
subjecting all software artifacts to thorough objective risk analyses
and testing.
■ Software security is a knowledge-intensive field.
■ Software is everywhere.
□ It runs your car. It controls your cell phone. It keeps your dishwasher
going. It is the lifeblood of your bank and the nation's power grid.
Secure SDLC
□ As businesses and society come to depend more heavily on software,
we have to make it better.
□ Now that software is networked by default, software security is
Chart 4
no longer a luxury—it's a necessity.
Security Problem
■ A central and critical aspect of the computer security problem is a
software problem
□ Software defects with security ramifications
– including implementation bugs such as buffer overflows and
design flaws such as inconsistent error handling
– security holes in software are common, and the problem is growing.
■ Security researchers and academics estimate that more than half of all
vulnerabilities are due to buffer overruns, an embarrassingly
elementary class of bugs
□ more complex problems, such as race conditions and design errors,
wait in the wings for the demise of the buffer overflow.
Secure SDLC
Chart 5
Security Problem (cont.)
■ The number of security-related software vulnerabilities reported to the
CERT Coordination Center (CERT/CC) from 1995 through 2004
Secure SDLC
Chart 6
60 Seconds in Internet
Internet-enabled software, especially
custom applications that use the
Web, are a sadly common target for
attack.
Secure SDLC
Chart 7
Data Breach
■ eBay: In 2014, records of 145 millions user were compromised.
□ Employee credentials
■ Google play hack: Google play was down twice, preventing any
downloads or uploads.
□ Malformed APK
■ The Home Depot: 56 millions debit and credit card numbers were stolen.
□ Custom-built malware – BlackPOS malware
■ JP Morgan Chase: Contact information of 76 million households and 7
million small business were compromised.
□ Attack on web applications
Secure SDLC
Chart 8
Data Breach (Cont.)
Secure SDLC
Chart 9
The Trinity of Trouble: Why the Problem Is
Growing
■ Connectivity
□ Connectivity of computers through the Internet
– Things that used to happen offline now happen online.
– supervisory control and data acquisition (SCADA) systems that run the
power grid
□ Internet is everywhere, the attackers are now at your virtual doorstep.
□ SOA
– Legacy applications that were never intended to be inter-networked
are becoming inter-networked and published as services
■ Extensibility
Secure SDLC
□ updates or extension, plug-in
□ the very nature of extensible systems makes it hard to prevent software
vulnerabilities from slipping in as unwanted extensions.
Chart 10
The Trinity of Trouble: Why the Problem Is
Growing
■ Complexity
□ In practice, the defect rate tends to go up as the square of code size.
– When systems become large, bugs cannot be avoided.
□ Other factors that significantly affect complexity include
– whether the code is tightly integrated
– patches and other post-deployment fixes
– critical architectural issues
□ exacerbated by the use of unsafe programming languages (e.g., C and
C++) that do not protect against simple kinds of attacks, such as buffer
overflows
Secure SDLC
□ more lines, more bugs" is the rule of thumb that tends to be borne
out in practice
Chart 11
The Trinity of Trouble: Why the Problem Is
Growing
□ Example:
Secure SDLC
Chart 12
Bugs and Flaws and Defects
■ Defect:
□ Both implementation vulnerabilities and design vulnerabilities
are defects.
□ a problem that may lie dormant in software for years only to surface in a
fielded system with major consequences.
■ Bug:
□ A bug is an implementation-level software problem.
□ Bugs may exist in code but never be executed.
□ Bugs are implementation-level problems that can be easily discovered
and remedied.
□ Example: Buffer Overflow Secure SDLC
Chart 13
Bugs and Flaws and Defects
■ Flaw:
□ A flaw is a problem at a deeper level.
□ Flaws are often much more subtle than simply an off-by-one error in an
array reference or use of an incorrect system call.
□ A flaw is certainly instantiated in software code, but it is also present
(or absent!) at the design level.
□ For example, a number of classic flaws exist in error-handling and
recovery systems that fail in an insecure or inefficient fashion.
Secure SDLC
Chart 14
Bugs and Flaws and Defects
Secure SDLC
Chart 15
Bugs and Flaws and Defects
■ Risk:
□ Flaws and bugs lead to risk.
□ Risks are not failures.
□ Risks capture the probability that a flaw or a bug will impact the
purpose of the software (that is, risk = probability x impact).
□ Risk measures must also take into account the potential damage that
can occur.
Secure SDLC
Chart 16
The Range of Defects
■ Security defects in software systems range
□ from local implementation errors (e.g., use of the gets() function call in
C/C++)
□ to interprocedural interface errors (e.g., a race condition between an
access control check and a file operation)
□ to much higher design-level mistakes (e.g., error-handling and recovery
systems that fail in an insecure fashion or object-sharing systems that
mistakenly include transitive trust issues).
Secure SDLC
Chart 17
The Problem with Application Security
■ One problem is that the term application security means different things
to different people.
□ the protection of software after it's already built.
□ Although the notion of protecting software is an important one, it's just
plain easier to protect something that is defect-free than something
riddled with vulnerabilities.
■ What is the most effective way to protect software?
□ software security is about building secure software: designing
software to be secure; making sure that software is secure; and educating
software developers, architects, and users about how to build security in
□ application security is about protecting software and the systems that
software runs in a post facto way, only after development is complete Secure SDLC
– Sandboxing code , protecting against malicious code, obfuscating code,
locking down executables, monitoring programs as they run (especially
their input), etc. Chart 18
The Three Pillars of Software Security
■ Software security is an ongoing activity that requires a cultural shift.
Secure SDLC
Chart 19
Pillar I: Applied Risk Management
■ Risk management should cover all the software development lifecycle
■ Successful risk management, however, is nothing more than a business
level decision-support tool:
□ a way to gather the requisite data to make a good judgment call, based
on knowledge of vulnerabilities, threats, impacts, and probabilities.
■ A good software risk assessment
□ Able to apply classic risk definitions to software designs in order
to generate accurate mitigation requirements
■ Risk Management Framework (RMF)
Secure SDLC
Chart 20
Pillar II: Software Security Touchpoints
■ Software Security is not Security Software
□ Software security is a system-wide issue that takes into account both
security mechanisms (such as access control) and design for security
(such as robust design that makes software attacks difficult).
□ Most modern software includes security features; but adding features
such as SSL to your program (to cryptographically protect
communications) does not present a complete solution to the
security problem
■ There's no such thing as magic crypto fairy dust—we need to focus on
software security from the ground up. We need to build security in.
■ In the fight for better software, treating the disease itself (poorly designed
and implemented software) is better than taking an aspirin to stop the Secure SDLC
symptoms
■ Touchpoints: a set of best practices
Chart 21
Pillar II: Software Security Touchpoints
Secure SDLC
Chart 22
Pillar II: Software Security Touchpoints
■ Software security touchpoints can be applied regardless of the base
software process being followed.
□ Waterfall, Rational Unified Process (RUP), eXtreme Programming (XP),
Agile, spiral development, Capability Maturity Model integration (CMMi)
□ All software development processes involve the creation of a common
set of software artifacts (the most common artifact being code).
– requirements and use cases, architecture, design documents,
test plans, code, test results, and feedback from the field.
■ You can create your own Secure Development Lifecycle (SDL) by
adapting your existing SDLC to include the touchpoints.
Secure SDLC
Chart 23
Pillar III: Knowledge
■ One of the critical challenges facing software security is the dearth of
experienced practitioners.
□ As the field evolves and best practices are established, knowledge
management and training play a central role in encapsulating and
spreading the emerging discipline more efficiently.
■ Pillar III involves gathering, encapsulating, and sharing security knowledge
that can be used to provide a solid foundation for software security
practices
■ Information and knowledge aren't the same thing, and it is important to
understand the difference.
□ Knowledge is information in context—information put to work using
processes and procedures. Secure SDLC
□ A checklist of potential security bugs in C and C++ is information; the
same information built into a static analysis tool is knowledge.
Chart 24
Pillar III: Knowledge
■ Software security knowledge can be organized into seven knowledge
catalogs
□ principles, guidelines, rules, vulnerabilities, exploits, attack
patterns, and historical risks
■ Two of these seven catalogs—vulnerabilities and exploits—are likely to be
familiar to software developers possessing only a passing familiarity with
software security.
■ Similarly, principles and rules are fairly well understood.
□ static analysis tools such as ITS4
■ Knowledge catalogs only more recently identified include guidelines
attack patterns, and historical risks.
Secure SDLC
■ Together, these various knowledge catalogs provide a basic foundation for
a unified knowledge architecture supporting software security
Chart 25
Pillar III: Knowledge
Secure SDLC
Chart 26
Secure SDLC (Gary McGraw)
Secure SDLC
Chart 27
Pillar III: Knowledge
■ One obvious way to spread software security knowledge is to train
software development staff on critical software security issues.
■ Putting the touchpoints into practice requires cultural change, and that
means training.
■ The most effective form of training begins with a description of the
problem and demonstrates its impact and importance.
■ Beyond awareness, more advanced software security training should offer
□ coverage of security engineering
□ design principles and guidelines
□ implementation risks
□ design flaws Secure SDLC
□ analysis techniques
□ security testing.
Chart 28
Software Security Is Everyone's Job
■ Builders must practice security engineering, ensuring that the systems we
build are defensible and not riddled with holes
■ Operations people must continue to architect reasonable networks,
defend them and keep them up.
■ Administrators must understand the distributed nature of modern systems
and begin to practice the principle of least privilege.
■ Users must understand that they are the last bastion of defense in any
security design and that they need to make tradeoffs for better security.
■ Executives must understand how early investment in security design and
security analysis affects the degree to which users will trust their
products.
Secure SDLC
Chart 29
SDL Requirements Phase
■ Define the specific requirements of the project.
■ Ensure the resultant software functions as desired.
■ Items specifically regarding security should be enumerated during this
step.
■ Outcome of this phase is a document guiding security throughout the rest
of the process.
■ Adding security later tends to cost exponentially more than
implementing it from the start.
Secure SDLC
Chart 30
Security Considerations for Requirements
Phase
■ Analysis of security and privacy risk
■ Authentication and password management
■ Audit logging and analysis
■ Authorization and role management
■ Code integrity and validation testing
■ Cryptography and key management
■ Data validation and sanitization
■ Network and data security
■ Ongoing education and awareness
■ Team staffing requirements Secure SDLC
■ Third-party component analysis
Chart 31
Buffer Overflows
■ Nearly half of all exploits of computer programs stem historically from
some form of buffer overflow.
■ The generic classification of buffer overflows includes many variants:
□ Static buffer overruns
□ Indexing errors
□ Format string bugs
□ Unicode and ANSI buffer size mismatches
□ Heap overruns
Secure SDLC
Chart 32
Improper Input Handling
■ Users have the ability to manipulate inputs
□ the programmer needs to appropriately handle the input to prevent
malicious entries from having an effect.
■ Canonicalization
□ a process for converting data that has more than one possible
representation into a "standard", "normal", or canonical form.
□ the process by which application programs manipulate strings to a base
form
■ Canonicalization errors
□ inputs to a web application may be processed by multiple applications,
such as web server, application server, and database server, each with its
own parsers to resolve appropriate canonicalization issues Secure SDLC
□ an issue relates to the form of the input string at the time of error checking
□ If the error checking routine occurs prior to resolution to canonical
Chart 33
form, then issues may be missed
Injections
■ Another issue with unvalidated input is the case of code injection.
■ Rather than the input being appropriate for the function, this code injection
changes the function in an unintended way.
■ A SQL injection attack is a form of code injection aimed at any Structured Query
Language (SQL)–based database, regardless of vendor
■ There are two main steps associated with testing for SQL injection vulnerability.
□ The first step is to confirm that the system is at all vulnerable.
□ The second step is to use the error message information to attempt to
perform an actual exploit against the database.
– ' or 1=1—
– " or 1=1—
– or 1=1— Secure SDLC
– ' or 'a'='a
– " or "a"="a
Chart 34
– ') or ('a'='a
Least Privilege
■ Least privilege requires that the developer understand what privileges are
required specifically for an application to execute and access all its
required resources.
■ Determine what needs to be accessed and what the appropriate level of
permission is, then use that level in design and implementation
Secure SDLC
Chart 35
Reference
■ Software Security: Building Security in by Gary McGraw
■ Keamanan Perangkat Lunak by Budi Raharjo
Secure SDLC
Chart 36
Insert picture by
clicking the icon
Thank you
for your attention!
Johannes Sianipar
