CERT Secure Coding Standards Guide

© 2015 Carnegie Mellon University
04-Nov-2015
CERT Secure Coding Standards
(and the Secure Software
Development Lifecycle)
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213
Mark Sherman, PhD
Technical Director, CERT
mssherman@sei.cmu.edu

2
Mark Sherman
Copyright 2015 Carnegie Mellon University
This material is based upon work funded and supported by the Department of Defense under Contract No. FA8721-05-C-0003 with
Carnegie Mellon University for the operation of the Software Engineering Institute, a federally funded research and development
center.
Any opinions, findings and conclusions or recommendations expressed in this material are those of the author(s) and do not
necessarily reflect the views of the United States Department of Defense.
References herein to any specific commercial product, process, or service by trade name, trade mark, manufacturer, or otherwise,
does not necessarily constitute or imply its endorsement, recommendation, or favoring by Carnegie Mellon University or its Software
Engineering Institute.
NO WARRANTY. THIS CARNEGIE MELLON UNIVERSITY AND SOFTWARE ENGINEERING INSTITUTE MATERIAL IS
FURNISHED ON AN “AS-IS” BASIS. CARNEGIE MELLON UNIVERSITY MAKES NO WARRANTIES OF ANY KIND, EITHER
EXPRESSED OR IMPLIED, AS TO ANY MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR
PURPOSE OR MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF THE MATERIAL. CARNEGIE
MELLON UNIVERSITY DOES NOT MAKE ANY WARRANTY OF ANY KIND WITH RESPECT TO FREEDOM FROM PATENT,
TRADEMARK, OR COPYRIGHT INFRINGEMENT.
This material has been approved for public release and unlimited distribution.
This material may be reproduced in its entirety, without modification, and freely distributed in written or electronic form without
requesting formal permission. Permission is required for any other use. Requests for permission should be directed to the Software
Engineering Institute at permission@sei.cmu.edu.
Carnegie Mellon® and CERT® are registered marks of Carnegie Mellon University.
DM-0002969

3
Mark Sherman
• State of software
• Building software: the Secure Software
Development Lifecycle
• Security in Agile
• Available standards
• Rule development methodology
• Example weaknesses
• New developments in secure coding
• Adoption of secure coding
• Review
Agenda

4
Mark Sherman
Software vulnerabilities are ubiquitous

5
Mark Sherman
Software and security failures are expensive
Source: New York Times, Jan 10, 2014
Average cost in a breach:
US$188 per record
Source: Ponemon Institute, “2013 Cost of Data Breach
Study: Global Analysis”, May 2013
Source: Wall Street Journal, Feb 26, 2014

6
Mark Sherman
An ounce of prevention ….
“We wouldn't have to
spend so much time,
money, and effort on
network security if we
didn't have such bad
software security.”
Bruce Schneier in Viega and McGraw,
“Building Secure Software,” 2001
Source: Washington Post, March 19, 2014, http://www.washingtonpost.com/business/economy/toyota-reaches-12-billion-settlement-to-end-criminal-
probe/2014/03/19/5738a3c4-af69-11e3-9627-c65021d6d572_story.html; http://www.greene-broillet.com/Articles/Toyotasuddenacceleration.shtml

7
Mark Sherman
Catching software faults early saves money
Faults accounts for 30‒50% percent of total software project costs
Sources: Critical Code; NIST, NASA, INCOSE, and Aircraft Industry Studies

8
Mark Sherman
• Review
Agenda

9
Mark Sherman
Focus on the need to develop the theory, processes, practices and
technology to support the agile construction and maintenance of
secure software
Security is a lifecycle issue

10
Mark Sherman
Software security is not security software
Not the same as security software
• Firewalls, intrusion detection, encryption
• Protecting the environment within which the software operates
Engineering software so that it continues to function under attack
The ability of software to recognize, resist, tolerate, and recover from
events that threaten it
Goal: Better, defect-free software that can function more robustly in its
operational production environment
In government circles, this is frequently called “Software Assurance”
• Microsoft (and hence the commercial world) has a different interpretation
of “software assurance”

11
Mark Sherman
Room for improvement
Mission thread
(Business process)
19% fail to carry out
security requirement
definition
27% do not practice
secure design
72% do not use code or
binary analysis
47% do not perform
acceptance tests for third-
party code
More than 81% do not coordinate their security practices
in various stages of the development life cycle.
Sources: Forrester Consulting, “State of Application Security,” January 2011; Wendy Nather, Research Director, 451 Research, “Dynamic testing: Why Tools
Alone Aren't Enough, March 25, 2015”

12
Mark Sherman
Most Vulnerabilities Are Caused by
Programming Errors
64% of the vulnerabilities in the National Vulnerability Database were due
to programming errors
• 51% of those were due to classic errors like buffer overflows, cross-site scripting,
injection flaws
Top 25 CWE includes
• Integer overflow
• Buffer overflow
• Missing authentication
• Missing or incorrect authorization
• Reliance on untrusted inputs (aka tainted inputs)
Sources: Heffley/Meunier (2004): Can Source Code Auditing Software Identify Common Vulnerabilities and Be Used to Evaluate Software
Security?; cwe.mitre.org/top25 Jan 6, 2015

13
Mark Sherman
Code security quality reviews generally reveal
problems
Source: http://xkcd.com/1513/

14
Mark Sherman
There is a wide range of application security
quality
0
50
100
150
200
250
1 2 3 4 5 6 7 8 9 10 11
Diagnosticsper
KsLOC
Program
Source: CERT sample of evaluated programs

15
Mark Sherman
• Review
Agenda

16
Mark Sherman
Integrating security into Agile development
1. Code hygiene – introduce secure coding
2. Secure DevOps – include security tools
3. Threat modeling – represent a new role
4. Risk analysis – prioritize in backlog
Persona
non grata
Code hygiene
Secure DevOps
Threat modeling
Risk analysis
(See also: Bellomo and Woody, DoD
Information Assurance and Agile:
Challenges and Recommendations
Gathered Through Interviews with Agile
Program Managers and DoD Accreditation
Reviewers
(http://repository.cmu.edu/cgi/viewcontent.cg
i?article=1674&context=sei)

17
Mark Sherman
• Review
Agenda

18
Mark Sherman
CERT C Secure Coding Standard
• Version 1.0 (C99) published in 2009
• Version 2.0 (C11) published in 2014
• ISO/IEC TS 17961 C Secure Coding Rules Technical
Specification
• Conformance Test Suite
CERT C++ Secure Coding Standard
• Version 1.0 under development
CERT Oracle Secure Coding Standard for Java
• Version 1.0 (Java 7) published in 2011
• Java Secure Coding Guidelines
• Subset applicable to Android development
• Android Annex
The CERT Perl Secure Coding Standard
CERT Python Secure Coding Standard

19
Mark Sherman
Coding rules
• Collected wisdom of programmers and
tools vendors
• Fed by community wiki started in
Spring 2006
• 1,576 registered contributors
• Basis for ISO Standard

20
Mark Sherman
Secure Coding eNewsletter engages community

21
Mark Sherman
• Review
Agenda

22
Mark Sherman
Common methodology for determining rules
and practices
Source: https://www.youtube.com/watch?v=JN99jshaQbY

23
Mark Sherman
Examine language definitions and standards for
undefined and unspecified behavior
Source: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pd (ISO 9899 - Programming Languages – C draft)

24
Mark Sherman
Examine vulnerable code for patterns
Malware repository with millions of unique, tagged artifacts
CERT Secure Coding Team has evaluated over 100M LOC

25
Mark Sherman
Implement candidate rules and run against
sample code
• Focus rule when possible to
• maximize true positive of weakness (tag bad code)
• minimize false negative of weakness (don’t tag good code)
• Write program to evaluate source code for particular rule
• Run program against collection of known bad source code and a
collection of other (suspected good) code to check sensitivity and
specificity of results

26
Mark Sherman
Tapping into expert knowledge for developing
CERT coding standards
Engage
community
Tool vendor
analysis
Consensus
on
vulnerability
and
mitigation

27
Mark Sherman
Risk assessment methodology
Risk assessment is performed using failure mode, effects, and criticality
analysis.
Severity—How serious are the consequences of
the rule being ignored?
Value Meaning Examples of Vulnerability
1 low denial-of-service attack, abnormal
termination
2 medium data integrity violation, uninten-
tional information disclosure
3 high run arbitrary code
Likelihood—How likely is it that a flaw introduced
by ignoring the rule can lead to an exploitable vul-
nerability?
Value Meaning
1 unlikely
2 probable
3 likely
Cost—The cost of mitigating the vulnerability.
Value Meaning Detection Correction
1 high manual manual
2 medium automatic manual
3 low automatic automatic

28
Mark Sherman
• Review
Agenda

29
Mark Sherman
What Is a Buffer Overflow?
A buffer overflow occurs when data is written outside of the boundaries of
the memory allocated to a particular data structure.
Destination
Memory
Source
Memory
Allocated Memory (12 Bytes) Other Memory
16 Bytes of Data
Copy
Operation

30
Mark Sherman
Buffer Overflows
Are caused when buffer boundaries are neglected and unchecked
Can occur in any memory segment
Can be exploited to modify a
• variable
• data pointer
• function pointer
• return address on the stack
Smashing the Stack for Fun and Profit (Aleph One, Phrack
49-14, 1996) provides the classic description of buffer
overflows.

31
Mark Sherman
Buffer overflow: potentially surprising
undefined behavior from integer overflow
Unintended optimization can happen once any undefined behavior occurs in the
program. Consider the following example:
if (x < 0) x = 0;
if (((x + 1) >> 30) /* x is 32-bit signed int >= 0 */) {
A[1] = y;
} else {
A[0] = y;
}
When defined, ((x + 1) >> 30) always produces 0 or 1.
An implementation could condense the entire if statement into
A[((x + 1) >> 30)] = y;
But if x + 1 overflows, some platforms could produce 2 or -2. Since signed
integer overflow is Undefined Behavior, this is permitted by the standard.

32
Mark Sherman
Adding a Pointer and an Integer
From C99 §6.5.6p8:
When an expression that has integer type is added to or subtracted from
a pointer, the result has the type of the pointer operand.
An expression like P[N] is translated into *(P+N).

33
Mark Sherman
Adding a Pointer and an Integer
C99 Section 6.5.6 says
If both the pointer operand and the result point to elements of the same
array object, or one past the last element of the array object, the
evaluation shall not produce an overflow; otherwise, the behavior is
undefined.
If the result points one past the last element of the array object, it shall
not be used as the operand of a unary * operator that is evaluated.

34
Mark Sherman
Buffer overflow: surprising integer overflow
A programmer might code a bounds-check such as
char *ptr; // ptr to start of array
char *max; // ptr to end of array
size_t len; // input unknown to programmer
if (ptr + len > max)
return EINVAL;
If len is very large, it can cause ptr + len to overflow, which creates
undefined behavior.
A result would typically wrap-around—pointing to an address that is
actually lower in memory than ptr.
Since (overflowed) ptr + len is less than max, execution proceeds

35
Mark Sherman
Buffer overflow: surprising code elimination
One might write a check like this:
if (ptr + len < ptr || ptr + len > max)
return EINVAL;
A compiler could assume that
• Programs are defined
• Hence a ptr + len will not overflow
• Hence, since len is unsigned, ptr + len must be
greater than or equal to (not less than) ptr
• Hence ptr + len < ptr is always true and can be
removed as dead code

36
Mark Sherman
Algebraic Simplification
Optimizations may be performed for
• comparisons between P + V1 and P + V2
• where P is the same pointer
• V1 and V2 are variables of some integer type.
As a common term, P might be eliminated thru
simplification.

37
Mark Sherman
Buffer overflow: surprising optimization
In our example:
if (ptr + len < ptr || ptr + len > max)
return EINVAL;
This optimization proceeds as follows:
ptr + len < ptr
ptr + len < ptr + 0
ptr + len < ptr + 0
len < 0 (impossible, len is unsigned)
The rewritten len < 0 is removed.

38
Mark Sherman
Mitigation
This problem is easy to remediate, once it is called to the attention of the
programmer, such as by a diagnostic message when dead code is
eliminated.
For example, if it is known that ptr is less-or-equal-to max, then the
programmer could write:
if (len > max – ptr)
return EINVAL;
This conditional expression eliminates the possibility of undefined
behavior.

39
Mark Sherman
Learning from rules and recommendations
Rules and recommendations in the secure coding standards focus to improve behavior
The “Ah ha” moment:
Noncompliant code
examples or antipatterns
in a pink frame—do not
copy and paste into your
code
Compliant solutions in a
blue frame that conform
with all rules and can be
reused in your code

40
Mark Sherman
• Review
Agenda

41
Mark Sherman
Some recent additions explore threads and
C++ updates
Major language updates for
C++
• 24 new rules in FY15 specifying C++
weaknesses
• 60 existing C++ rules updated in FY15
New and updated rules published on
http://www.cert.org/secure-
coding/publications/secure-coding-
enewsletter.cfm
New computation model:
C threads
• 9 unspecified behaviors representing
programming weaknesses in two broad
categories
• Inter-thread communication
• Thread-specific storage
Example: the tss_create function which creates
thread-specific storage and assigns a destructor
but does not specify when the destructor is called.

42
Mark Sherman
Extending secure coding rules to new models
Secure coding for
concurrent programming
Designing secure
APIs

43
Mark Sherman
C and C++ Thread Safety Analysis
CERT and Google developed thread safety analysis for Clang
• uses annotations to declare and static analysis to enforce thread safety
policies in C and C++ programs
• detects potential race conditions and deadlocks
• Clang is a production-quality C and C++ compiler available on most platforms
• the analysis is using the -Wthread-safety flag
Annotation usage:
• Have not been a liability
• Benefits software
evolution and maintenance Establish rules regarding which roles may execute
particular code segments, e.g. REQUIRES(FlightControl)
DataLogger REQUIRES(DataLogger)
Declare roles threads may perform, e.g. FlightControl

44
Mark Sherman
Android App Sets: Sensitive Dataflow
Problem: Colluding apps, or a combination of a malicious app and
leaky app can use intents (messages sent to Android app components)
to extract sensitive or private information from an Android phone.
Goal: Precisely detect tainted flows from sensitive information sources
to restricted sinks.
• If such flows are discovered:
– User might refuse to install app
– App store might remove app
DidFail analysis currently performs 2-phase static taint flow analysis for
app sets.
Goal is to add context sensitivity, which adds precision, resulting in less
false positives.
sink
src

45
Mark Sherman
Source to source code correction
printf(attacker_string) Automated transformation of
insecure C source code
• Most frequently encountered
mistakes
• No loss of desired function
• Changes made at developer
view of source code
Adoption of program transformers
• Analysis of current systems
• Addition of specialized
requirements
void lcstr(char *str, size_t size) {
for (size_t i = 0; i < size; i++) {
str[i] = tolower(str[i]);
}
}
printf("%s", attacker_string)
void lcstr(char *str, int size) {
for (int i = 0; i < size; i++) {
str[i] = tolower(str[i]);
}
}
(And all callers of “lcstr”)

46
Mark Sherman
• Review
Agenda

47
Mark Sherman
Secure Coding in C/C++ Training
The Secure Coding course is designed for C and C++
developers. It encourages programmers to adopt security
best practices and develop a security mindset that can help
protect software from tomorrow’s attacks, not just today’s.
Topics
• String management
• Dynamic memory management
• Integral security
• Formatted output
• File I/O
Additional information at http://www.sei.cmu.edu/training/p63.cfm

48
Mark Sherman
Secure Coding in Java Workshop
Trust and Security Policies
Validation and Sanitization
The Java Security Model
Declarations
Expressions
Object Orientation
Methods
Vulnerability Analysis Exercise
Numerical Types in Java
Exceptional Behavior
Input/Output
Serialization
The Runtime Environment
Introduction to Concurrency in Java
Advanced Concurrency Issues
The Secure Coding workshop is designed to improve the secure use of
Java. Designed primarily for Java SE 8 developers, the workshop is
useful to developers using older versions of the platform as well as Java
EE and ME developers. Tailored to meet the needs of a development
team, the workshop can cover security aspects of:

49
Mark Sherman
Training delivery options
• Conventional classroom
• Self-study
• Written materials
• On-demand, on-line training: STEPfwd
• Hands-on
• Individual
• Team
• Testing and certificates
• Workshops, mentoring and advising

50
Mark Sherman
Tools encourage application of secure coding
Moving rules into IDE improves
application of secure coding
• Early feedback corrects errors on introduction
• Exceptions are understood in context
• Feedback improves developer skill
Target Clang static analyzer (C based
languages)
• Widely used open source front end for popular
compilers
• Integrated into Apple’s Xcode IDE
Target FindBugs (Java)
• Integrated into Eclipse and JDeveloper
Adoption of secure coding IDEs:
• Help deploy tools
• Training on tools
• Extend tools to meet targeted needs

51
Mark Sherman
Static Testing – Source code analysis tools
Secure Code Analysis Laboratory (SCALe)
• C, C++, Java, PERL, Python, Android
rule conformance checking
• Thread safety analysis
• Information flows across Android
applications
• Operating system call flows
Static testing optimization
• SCALe set up
• SCALe filters and visualizer
• Tool conformance and capability testing
• Multitool integration and statistical
optimizer

52
Mark Sherman
SCALe Multitool evaluation
Improve expert review
productivity by focusing on high
priority violations
Filter select secure coding rule
violations
• Eliminate irrelevant
diagnostics
• Convert to common CERT
Secure Coding rule labeling
Single view into code and all
diagnostics
Maintain record of decisions

53
Mark Sherman
SCALe Web App Demos
Watch demonstration videos of SCALe on YouTube:
http://www.cert.org/secure-coding/products-services/scale.cfm
•Play next
•Play now
Source Code Analysis Laboratory (SCALe)
Demo: Web UI Columns
8:04
•Play next
•Play now
Demo Web UI Heading
4:43
•Play next
•Play now
Demo: Web UI Code
3:01

54
Mark Sherman
Optimizing multitool evaluations - research
Analyzers
Analyzers
Analyzers
Diagnostics
from each
tool
Expert
(Oracle)
Code
Repositories
Prioritized
diagnostics
list
Analyzers
Analyzers
Analyzers
Diagnostics
from each
tool
Test
Code
Active ML with
STEM
Learn Apply
Code
Metadata

55
Mark Sherman
Static Testing – Source code review
Manual review against threat models
• Web services: SOAP, REST, XML-RPC
• Java applets
• Access control matrices
• Custom network or data protocols

56
Mark Sherman
Dynamic testing and evaluation – fuzzing
Fuzz testing of attack surfaces
• Based on techniques used in CERT’s Basic
Fuzzing Framework (BFF)
• mutational fuzzing
• machine learning and evolutionary computing
techniques
• adjusts its configuration parameters based on what
it finds (or does not find) over the course of a
fuzzing campaign

57
Mark Sherman
Dynamic testing – Penetration testing
Examination of business logic and interfaces, from an adversarial
perspective
• Creating attack models
• Searching for holes in attack surfaces
• Environmental alteration
• Reverse engineering
• Replicates the intended deployment environment for the application
• Find ways to gain unauthorized access to data or the underlying systems.
• Documenting program-specific protocols
• Identifying failure states that are handled in an insecure manner.

58
Mark Sherman
• Review
Agenda

59
Mark Sherman
Automation; Acquisition (Supply chain); Building skills (Workforce development); Metrics, Models, and Measurement
Review: Secure Software Development Lifecycle
Mission Ready Diagnostics;
Threat Modeling;
SQUARE;
Security Engineering
Risk Analysis
Architecture Analysis
& Design Language
Team Software Process;
Secure Agile;
Secure Coding;
SCALe
Run time
support;
Vulnerability
Analysis
Forensic
Operations
&
Investigations
Software Assurance Framework

60
Mark Sherman
Contact Information
Mark Sherman
(412) 268-9223
mssherman@sei.cmu.edu
Web Resources (CERT/SEI)
http://www.cert.org/
http://www.sei.cmu.edu/

61
Mark Sherman

CERT Secure Coding Standards Guide

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (6)

Similar to CERT Secure Coding Standards Guide

Similar to CERT Secure Coding Standards Guide (20)

Recently uploaded

Recently uploaded (20)

CERT Secure Coding Standards Guide