"cert secure coding standards" by dr. mark sherman
TRANSCRIPT
-
2015 Carnegie Mellon University
04-Nov-2015
CERT Secure Coding Standards (and the Secure Software Development Lifecycle)Software Engineering InstituteCarnegie Mellon UniversityPittsburgh, PA 15213
Mark Sherman, PhDTechnical Director, [email protected]
-
2
Mark ShermanCERT Secure Coding Standards 2015 Carnegie Mellon University
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 [email protected].
Carnegie Mellon and CERT are registered marks of Carnegie Mellon University.
DM-0002969
-
3
Mark ShermanCERT Secure Coding Standards 2015 Carnegie Mellon University
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 ShermanCERT Secure Coding Standards 2015 Carnegie Mellon University
Software vulnerabilities are ubiquitous
-
5
Mark ShermanCERT Secure Coding Standards 2015 Carnegie Mellon University
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 ShermanCERT Secure Coding Standards 2015 Carnegie Mellon University
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
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
-
7
Mark ShermanCERT Secure Coding Standards 2015 Carnegie Mellon University
Catching software faults early saves moneyFaults accounts for 3050% percent of total software project costs
Sources: Critical Code; NIST, NASA, INCOSE, and Aircraft Industry Studies
-
8
Mark ShermanCERT Secure Coding Standards 2015 Carnegie Mellon University
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
-
9
Mark ShermanCERT Secure Coding Standards 2015 Carnegie Mellon University
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 ShermanCERT Secure Coding Standards 2015 Carnegie Mellon University
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 attackThe ability of software to recognize, resist, tolerate, and recover from events that threaten itGoal: 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 ShermanCERT Secure Coding Standards 2015 Carnegie Mellon University
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 ShermanCERT Secure Coding Standards 2015 Carnegie Mellon University
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 ShermanCERT Secure Coding Standards 2015 Carnegie Mellon University
Code security quality reviews generally reveal problems
Source: http://xkcd.com/1513/
-
14
Mark ShermanCERT Secure Coding Standards 2015 Carnegie Mellon University
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
Dia
gnos
tics
per
KsL
OC
Program
Source: CERT sample of evaluated programs
-
15
Mark ShermanCERT Secure Coding Standards 2015 Carnegie Mellon University
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
-
16
Mark ShermanCERT Secure Coding Standards 2015 Carnegie Mellon University
Integrating security into Agile development1. Code hygiene introduce secure coding2. Secure DevOps include security tools3. Threat modeling represent a new role4. Risk analysis prioritize in backlog
Personanon grata
Code hygieneSecure 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.cgi?article=1674&context=sei)
http://repository.cmu.edu/cgi/viewcontent.cgi?article=1674&context=sei
-
17
Mark ShermanCERT Secure Coding Standards 2015 Carnegie Mellon University
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
-
18
Mark ShermanCERT Secure Coding Standards 2015 Carnegie Mellon University
CERT Secure Coding StandardsCERT 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 Version 1.0 under development
CERT Python Secure Coding Standard Version 1.0 under development
-
19
Mark ShermanCERT Secure Coding Standards 2015 Carnegie Mellon University
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 ShermanCERT Secure Coding Standards 2015 Carnegie Mellon University
Secure Coding eNewsletter engages community
-
21
Mark ShermanCERT Secure Coding Standards 2015 Carnegie Mellon University
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
-
22
Mark ShermanCERT Secure Coding Standards 2015 Carnegie Mellon University
Common methodology for determining rules and practices
Source: https://www.youtube.com/watch?v=JN99jshaQbY
-
23
Mark ShermanCERT Secure Coding Standards 2015 Carnegie Mellon University
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)
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pd
-
24
Mark ShermanCERT Secure Coding Standards 2015 Carnegie Mellon University
Examine vulnerable code for patterns
Malware repository with millions of unique, tagged artifacts
CERT Secure Coding Team has evaluated over 100M LOC
-
25
Mark ShermanCERT Secure Coding Standards 2015 Carnegie Mellon University
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 (dont 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 ShermanCERT Secure Coding Standards 2015 Carnegie Mellon University
Tapping into expert knowledge for developing CERT coding standards
Engage community
Tool vendor analysis
Consensus on
vulnerability and
mitigation
-
27
Mark ShermanCERT Secure Coding Standards 2015 Carnegie Mellon University
Risk assessment methodology
Risk assessment is performed using failure mode, effects, and criticality analysis.
SeverityHow 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
LikelihoodHow 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
CostThe cost of mitigating the vulnerability.
Value Meaning Detection Correction
1 high manual manual 2 medium automatic manual 3 low automatic automatic
-
28
Mark ShermanCERT Secure Coding Standards 2015 Carnegie Mellon University
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
-
29
Mark ShermanCERT Secure Coding Standards 2015 Carnegie Mellon University
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.
DestinationMemory
SourceMemory
Allocated Memory (12 Bytes) Other Memory
16 Bytes of Data
Copy Operation
-
30
Mark ShermanCERT Secure Coding Standards 2015 Carnegie Mellon University
Buffer Overflows
Are caused when buffer boundaries are neglected and uncheckedCan occur in any memory segmentCan be exploited to modify a variable data pointer function pointer return address on the stack
Smashing the Stack for Fun and Profit (Aleph One, Phrack49-14, 1996) provides the classic description of buffer overflows.
-
31
Mark ShermanCERT Secure Coding Standards 2015 Carnegie Mellon University
Buffer overflow: potentially surprising undefined behavior from integer overflowUnintended 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 ShermanCERT Secure Coding Standards 2015 Carnegie Mellon University
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 ShermanCERT Secure Coding Standards 2015 Carnegie Mellon University
Adding a Pointer and an Integer
C99 Section 6.5.6 saysIf 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 ShermanCERT Secure Coding Standards 2015 Carnegie Mellon University
Buffer overflow: surprising integer overflow
A programmer might code a bounds-check such as
char *ptr; // ptr to start of arraychar *max; // ptr to end of arraysize_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-aroundpointing to an address that is actually lower in memory than ptr. Since (overflowed) ptr + len is less than max, execution proceeds
-
35
Mark ShermanCERT Secure Coding Standards 2015 Carnegie Mellon University
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 ShermanCERT Secure Coding Standards 2015 Carnegie Mellon University
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 ShermanCERT Secure Coding Standards 2015 Carnegie Mellon University
Buffer overflow: surprising optimization
In our example: if (ptr + len < ptr || ptr + len > max)return EINVAL;
This optimization proceeds as follows:ptr + len < ptrptr + len < ptr + 0ptr + len < ptr + 0len < 0 (impossible, len is unsigned)
The rewritten len < 0 is removed.
-
38
Mark ShermanCERT Secure Coding Standards 2015 Carnegie Mellon University
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 ShermanCERT Secure Coding Standards 2015 Carnegie Mellon University
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 antipatternsin a pink framedo 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 ShermanCERT Secure Coding Standards 2015 Carnegie Mellon University
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
-
41
Mark ShermanCERT Secure Coding Standards 2015 Carnegie Mellon University
Some recent additions explore threads and C++ updates
Major language updates forC++
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 ShermanCERT Secure Coding Standards 2015 Carnegie Mellon University
Extending secure coding rules to new models
Secure coding forconcurrent programming
Designing secureAPIs
-
43
Mark ShermanCERT Secure Coding Standards 2015 Carnegie Mellon University
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 ShermanCERT Secure Coding Standards 2015 Carnegie Mellon University
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.
sinksrc
-
45
Mark ShermanCERT Secure Coding Standards 2015 Carnegie Mellon University
Source to source code correctionprintf(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 ShermanCERT Secure Coding Standards 2015 Carnegie Mellon University
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
-
47
Mark ShermanCERT Secure Coding Standards 2015 Carnegie Mellon University
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 tomorrows attacks, not just todays.
Topics String management Dynamic memory management Integral security Formatted output File I/O
Additional information at http://www.sei.cmu.edu/training/p63.cfm
http://www.sei.cmu.edu/training/p63.cfm
-
48
Mark ShermanCERT Secure Coding Standards 2015 Carnegie Mellon University
Secure Coding in Java Workshop
Trust and Security PoliciesValidation and SanitizationThe Java Security ModelDeclarationsExpressionsObject OrientationMethodsVulnerability Analysis Exercise
Numerical Types in JavaExceptional BehaviorInput/OutputSerializationThe Runtime EnvironmentIntroduction to Concurrency in JavaAdvanced 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 ShermanCERT Secure Coding Standards 2015 Carnegie Mellon University
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 ShermanCERT Secure Coding Standards 2015 Carnegie Mellon University
Tools encourage application of secure codingMoving 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 Apples 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 ShermanCERT Secure Coding Standards 2015 Carnegie Mellon University
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 flowsStatic testing optimization SCALe set up SCALe filters and visualizer Tool conformance and capability testing Multitool integration and statistical
optimizer
-
52
Mark ShermanCERT Secure Coding Standards 2015 Carnegie Mellon University
SCALe Multitool evaluationImprove 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 diagnosticsMaintain record of decisions
-
53
Mark ShermanCERT Secure Coding Standards 2015 Carnegie Mellon University
SCALe Web App DemosWatch 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
Source Code Analysis Laboratory (SCALe) Demo Web UI Heading 4:43
Play next Play now
Source Code Analysis Laboratory (SCALe) Demo: Web UI Code 3:01
http://www.cert.org/secure-coding/products-services/scale.cfmhttps://www.youtube.com/watch?v=46LdrI7AkUE&index=1&list=PLSNlEg26NNpxMofZSX-72rxjFEUk9myk-https://www.youtube.com/watch?v=HbpEqxc0W3U&index=2&list=PLSNlEg26NNpxMofZSX-72rxjFEUk9myk-https://www.youtube.com/watch?v=Wc-bS_ro2dk&index=3&list=PLSNlEg26NNpxMofZSX-72rxjFEUk9myk-
-
54
Mark ShermanCERT Secure Coding Standards 2015 Carnegie Mellon University
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
TestCode
Active ML with STEM
Learn ApplyCode
Metadata
-
55
Mark ShermanCERT Secure Coding Standards 2015 Carnegie Mellon University
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 ShermanCERT Secure Coding Standards 2015 Carnegie Mellon University
Dynamic testing and evaluation fuzzing
Fuzz testing of attack surfaces Based on techniques used in CERTs 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 ShermanCERT Secure Coding Standards 2015 Carnegie Mellon University
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 ShermanCERT Secure Coding Standards 2015 Carnegie Mellon University
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
-
59
Mark ShermanCERT Secure Coding Standards 2015 Carnegie Mellon University
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 ShermanCERT Secure Coding Standards 2015 Carnegie Mellon University
Contact Information
Mark Sherman(412) 268-9223
Web Resources (CERT/SEI)http://www.cert.org/http://www.sei.cmu.edu/
-
61
Mark ShermanCERT Secure Coding Standards 2015 Carnegie Mellon University
CERT Secure Coding Standards (and the Secure Software Development Lifecycle)Slide Number 2AgendaSoftware vulnerabilities are ubiquitousSoftware and security failures are expensiveAn ounce of prevention .Catching software faults early saves moneyAgendaFocus on the need to develop the theory, processes, practices and technology to support the agile construction and maintenance of secure softwareSoftware security is not security softwareRoom for improvementMost Vulnerabilities Are Caused by Programming ErrorsCode security quality reviews generally reveal problemsThere is a wide range of application security qualityAgendaIntegrating security into Agile developmentAgendaCERT Secure Coding StandardsCoding rulesSecure Coding eNewsletter engages communityAgendaCommon methodology for determining rules and practicesExamine language definitions and standards for undefined and unspecified behaviorExamine vulnerable code for patternsImplement candidate rules and run against sample codeTapping into expert knowledge for developing CERT coding standardsRisk assessment methodologyAgendaWhat Is a Buffer Overflow?Buffer OverflowsBuffer overflow: potentially surprising undefined behavior from integer overflowAdding a Pointer and an IntegerAdding a Pointer and an IntegerBuffer overflow: surprising integer overflow Buffer overflow: surprising code elimination Algebraic SimplificationBuffer overflow: surprising optimizationMitigationLearning from rules and recommendationsAgendaSome recent additions explore threads and C++ updatesExtending secure coding rules to new modelsC and C++ Thread Safety AnalysisAndroid App Sets: Sensitive DataflowSource to source code correctionAgendaSecure Coding in C/C++ TrainingSecure Coding in Java WorkshopTraining delivery optionsTools encourage application of secure codingStatic Testing Source code analysis toolsSCALe Multitool evaluationSCALe Web App DemosOptimizing multitool evaluations - researchStatic Testing Source code reviewDynamic testing and evaluation fuzzingDynamic testing Penetration testingAgendaSlide Number 59Contact InformationSlide Number 61