Software Security is the idea of engineering software so that it continues to function correctly under malicious attacks.
The Security Problem, The Trinity of Trouble: Why the Problem is Growing, Connectivity, Extensibility, Complexity, Basic Science
Security Problems in Software, Bugs and Flaws and Defects, Oh My!, Defect, Bug, The (Much Ballyhoo'd) Buffer Overflow: An Implementation Bug, Flaw, Microsoft Bob: A Design Flaw, Risk, The Range of Defects, The Problem with Application Security, Application Security Testing Tools: Good or Bad?, Badness-ometers, Software Security and Operations, Security versus Software, Security Has Come a Long Way, Security Has not Come Very Far
Solving the Problem: The Three Pillars of Software Security, Pillar 1: Applied Risk Management, Pillar 2: Software Security Touchpoints, Microsoft's Trustworthy Computing Initiative, The Gates Memo, Pillar 3: Knowledge
The Rise of Security Engineering, Software Security Is Everyone's Job
IT Security = Risk Management. A continuous risk management process is a necessity. Basic idea of Risk Management Framework (RMF):* identify* rank* track Chapter is about a mature RMF used at Cigital (= a consulting firm).
Putting Risk Management into Practice
How to use This Chapter
The Five Stages of Activity, Stage 1: Understand the Business Context, Stage 2: Identify the Business and Technical Risks, Stage 3: Synthesize and Rank the Risks, Stage 4: Define the Risk Mitigation Strategy, Stage 5: Carry Out Fixes and Validate, Measuring and Reporting on Risk
The RMF Is a Multilevel Loop
Applying the RMF: KillerAppCo's iWare 1.0 Server, Understanding the Business Context, Gathering the Artifacts, Conducting Project Research, Identifying the Business and Technical Risks, Developing Risk Questionaires, Interviewing the Target Project Team, Analyzing the Research and Interview Data, Uncovering Technical Risks, Analyzing Software Artifacts, Synthesizing and Ranking the Risks, Reviewing the Risk Data, Conducting the Business and Technical Peer Review, Defining the Risk Mitigation Strategy, Brainstorming on Risk Mitigation, Authoring the Risk Analysis Report, Producing Final Deliverables, Carrying Out Fixes and Validating
The Importance of Measurement, Measuring Return, Measurement and Metrics in the RMF
The Cigital Workbench
Risk Management Is a Framework for Software Security
Set of software security best practices = touchpoints.Integrating software security best practices into the SDLC is the center of the three pillars of software security. Software security best practices have their basis in good software engineering and continously thinking about security in the SDLC.This includes:* Knowing and understanding common risks* designing for security* subjecting all software artifacts to risk analysis and testing.During these activities, software risk should be tracked according to Chapter 2.This chapter presents a quick introduction to the software security touchpoints and suggests an ordering for their adoption. See figure 3-1, p. 85 for Lightweight software security best practices called touchpoints are applied to various software artifacts. The best practices are numbered according to effectiveness and importance. Note that by referring only to software artifacts, we can avoid battles over any particular process. Touchpoints will be cycled through more than once as the software evolves (iterative approach). Software security touchpoints are process agnostic (see Chapter 1). Touchpoints, in order of effectiveness:1. Code review2. Architectural risk analysis3. Penetration testing4. Risk-based security tests5. Abuse cases6. Security requirements7. Security operations Ordering is not perfect for every organization. Both 1 and 2 are critical touchpoints. Skipping one of the two: Architectural risk analysis or code review solves only half the problem. The first finds flaws, the second bugs. Ordering is based on years of experience of the author.Doing penetration testing before code review is bad, as it is a reactive approach. Big organizations can adopt several touchpoints simultaneously (see Chapter 10).
Flyover: Seven Terrific Touchpoints, 1. Code Review (Tools), 2. Architectural Risk Analysis, 3. Penetration Testing, 4. Risk-Based Security Testing, 5. Abuse Cases, 6. Security Requirements, 7. Security Operations, *. External Analysis, Security Requirments, Why Only Seven?
Black and White: Two Threads Inextricably Interwined
Touchpoints as Best Practices, Coder's Corner
Who Should Do Software Security?, Building a Software Security Group, Don't start with security people, Software Security in the Academy, Start with software people, Software Security Is a Multidisciplinary Effort, Creativity in a New Discipline, Where Today's Security People Come From, Where Tomorrow's Security People Will Come From
Touchpoints to Success
All software projects have one artifact in common: source code.A large number of security problems are caused by simple bug that can be spotted in code. Code review is about finding bugs.This chapter is about automating source code security analysis with static analysis tools. Code review is boring, difficult and tedious, that's why a tool is used.
Catching Implementation Bugs Early (with a Tool), Binary Analysis?!
Aim for Good, Not Perfect
Approaches to Static Analysis, A History of Rule Coverage, Modern Rules
Tools from Researchland, Modern Security Rules Schema, A Complete Modern Rule
Commercial Tool Vendors, Commercial Source Code Analyzers, Key Characteristics of a Tool, Be designed for security, Support multiple tiers, Be extensible, Be useful for security analysts and developers alike, Support existing development processes, Make sense to multiple stakeholders, Three Characteristics to Avoid, Too many false positives, Spotty integration with IDEs, Single-minded support for C, The Fortify Source Code Analysis Suite, The Fortify Knowledge Base, Coder's Corner, Using Fortify
Touchpoint Process: Code Review
Use a Tool to Find Security Bugs
Design flaws are 50% of the security problems.Linking security risks to business risks helps getting the risks mitigated. Security is risk management.
Common Themes among Security Risk Analysis Approaches, Basic substeps, Learn as much as possible about the target of analysis, Discuss security issues surrounding the software, Determine probability of compromise, Perform impact analysis, Rank risks, Develop a mitigation strategy, Report findings, Risk Analysis in Practice, Risk Analysis Fits in the RMF
Traditional Risk Analysis Terminology
The Necessity of a Forest-Level View
A Traditional Example of a Risk Calculation
Limitations of Traditional Approaches
Modern Risk Analysis
Touchpoint Process: Architectural Risk Analysis
Getting Started with Risk Analysis
Architectural Risk Analysis Is a necessity
Quality assurance and testing organizations have to ensure that a software fulfills its functional business requirements.This involves running dynamic functional tests late in the lifecycle to ensure proper implementation. Focus is on features and function. Security is not a feature. It does not fit into this paradigm. Security issues involve often unexpected misuses of an application. If functional testing is "testing for positives" then penetration testing is "testing for negatives".Security tester should use abuse cases and architecural risks to determine how the system behaves under attack. Security testing needs both, black hat and white hat approaches: Ensuring that the security features work as advertised (white hat) and that attacks can't easily compromise the system (black hat). Penetration testing is almost always black hat. It's easier to verify a positive with a set of tests, than to test some attacks and declare a system as secure. How many attacks until it is secure enough? If negative tests don't uncover any faults, this only proofs that these tests did not work. Does not prove that no faults exist.Passing a penetration test says nothing. Problem is that after finding one or two security issues everybody feels good and testing stops.
Software Penetration Testing
Penetration Testing Today
Software Penetration Testing a Better Approach
Incorporating Findings Back into Development
Using Penetration Tests to Assess the Application Landscape
Proper Penetration Testing Is Good
Security testing is not only black box probing. By using test for at-risk-areas a software security tester can focus on areas of code where an attack is likely to succeed. Penetration testing is used after the product is complete. Security testing before that, even with stubs possible. Both approaches work best if risk analysis results, abuse cases, and functional security requirements are taken into account. Security testing should start at the feature or component/unit level prior to system integration.Tests should test: * unauthorized misuse and access* violations of assumptions Security unit testing breaks system security down into discrete parts. Security testing should continue at the system level to focus on intracomponent failures and assessing security risk inherent at the design level. Already developed abuse cases should be used to enhance a test plan with plausible scenarios.
From Outside → In to Inside → Out
What's So Different about Security?
Risk Management and Security Testing
How to Approach Security Testing, Who, How, An Example: Java Card Security Testing, Automating Security Testing, Results: Nonfunctional Security Testing Is Essential, Coder's Corner
Thinking about (Malicious) Input, eXtreme Programming and Security Testing
Getting Over Input
Leapfrogging the Penetration Test
Software development focuses on what the software should do. Most system for designing software describe features and functions. No focus on preventing abuse of the software. Sometimes SLAs are set up to guarantee security of a developed system. What "secure" is, is up to the developer most of the time. Problem: Security and other -ilities are complicated. You have to think like a black hat to deal with security. Risk analysis starts with a blank page. The core of each touchpoints is to come up with a hypothesis of what might go wrong. That's what abuse cases are all about. Abuse cases (= misuse cases) help to think like an attacker. Systematically asking "what might some bad person cause to go wrong here?" uncover exceptional cases and overlooked security requirements. What motivates an attacker?* Money* Secrets* To be root* Impress friends* Spy on girlfriend How can I achieve this with the given software? → now you think like an attacker. Needs experience to be effective. Trick: think about how you humiliate someone, take everything from him and if he can't come back to you (by using this software) you have won.
Holding Software Vendors Accountable
Security Is Not a Set of Features
What You Can't Do
Creating Useful Abuse Cases, But No One Would Ever Do That!
Touchpoint Process: Abuse Case Development, Creating Anti-Requirements, Coders Corner, Creating an Attack Model
An Abuse Case Example, Attack Patterns from Exploiting Software, Make the client invisible, Target programs that write to privileged OS resources, Use a user-supplied configuration file to run commands that elevate privilege, make use of configuration file search paths, direct access to executable files, embedding scripts within scripts, leverage executable code in nonexecutable files, argument injection, command delimiters, multiple parsers and double escapes, user-supplied variable passed to filesystem calls, postfix NULL terminator, postfix, null terminate, and backslash, relative path traversal, client-controlled environment variables, user-supplied global variables (DEBUG=1, PHP Globals,...), session id, resource id, and blind trust, analog in-band switching signals (aka "Blue Boxing"), Attack pattern fragment: manipulating terminal devices, simple script injection, embedding scripts in nonscript elements, XSS in HTTP headers, HTTP query strings, User-controlled filenames, passing local filenames to functions that expect a URL, Meta-characters in E-mail Headers, Filesystem function injection, content based, Client-side injection, buffer overflow, cause web server misclassification, Alternate Encoding of the leading ghost characters, using slashes in alternate encoding, using escaped slashes in alternate encoding, unicode encoding, UTF-8 encoding, URL encoding, Alternative IP addresses, slashes and URL encoding combined, web logs, overflow binary resource files, overflow variables and tags, overflow symbolic links, MIME conversion, HTTP cookies, Filter failure through buffer overflow, Buffer overflow with environment variables, Buffer overflow in an API call, Buffer overflow in local command-line utilities, parameter expansion, String format overflow in syslog()
Abuse Cases Are Useful
Traditionally, software development in large corporations are removed from information security. Developers often traded like Pokémon cards. Thus software is developed without security. Software security should be enhanced by information security people.
Don't Stand So Close to Me
Kumbaya (for Software Security), Requirements: Abuse Cases, Design: Business Risk Analysis, Design: Architectural Risk Analysis, Test Planning: Security Testing, Implementation: Code Review, System Testing: Penetration Testing, Know When Enough Is Too Much, Fielded System: Deployment and Operations
Come Together (Right Now), The Infosec Boogey Man, Coders Corner
Future's So Bright, I Gotta Wear Shades
Adoting software security in large organizations is a challenge. Political factors:* Momentum: business dependent on applications, they are set in stone.* Territory: Many things at stake. Hard to tell a director he will lose database engineers and annual maintenance budget when applications are secured. Term "Secure Development Lifecycle" (SDL) used to describe goal state of software security program. This is a combination of already in place process and software security.Chapter is about how to accomplish cultural change to put SDL in place:1. Demonstrate value of software security2. Show initial success3. Build actionable roadmap for change. Chapter focuses on business process engineering.
The Business Climate
Building Blocks of Change, Overcoming Common Pitfalls, Over-reliance on Late-Lifecycle Testing, Management without Measurement, Training without Assessment, Lack of High-Level Commitment, Cigital change program maturity path sequence (6 phases), Stop the bleeding, Harvest the low-hanging fruit, Establish a foundation, Craft core competencies, Develop differentiators, Build out nice-to-haves
Building an Improvement Program
Establishing a Metrics Program, A Three-Step Enterprise Rollout
What about COTS (and Existing Software Applications)?, An Enterprise Information Architecture
Adopting a Secure Development Lifecycle
Knowledge management can play a central role in encapsulating and spreading software security. Information and knowledge aren't the same thing.Knowledge is information in context.Information is put to work using processes and procedures. e.g. checklist of security bugs.This checklist built into a static analysis tool is knowledge. Many checklists have no coherent items on its list. "Apply principle of least privilege" cannot be treated the same as "avoid buffer overflows".It's better to organize software security knowledge into coherent chunks. Bugs are not the only target in software security. Making a list of bug-types to avoid does not help. Creating an analyze tool to detect those bugs, does. Bugs can be found by tools, flaws require a smart human to find. Software security isn't about adopting various security features and/or conventions. (e.g. Blacklists are inferior to white-lists) Understanding a software puts you in a position to create correct input-filtering.Security Cookbooks are great, but you need to implement recipes, not only read them. Experience is the most powerful teacher. Checklists are overused. They are great in the hands of experts, but they are incomplete.e.g. STRIDE:* Spoofing* Tampering* Repudiation* Information disclosure* Denial of Service* Elevation of privilegeThere are more categories to attack a system. Don't limit yourself by using a checklist. Chapter is about organizing and cataloging knowledge, not about making it actionable.
Experience, Expertise, and Security
Security Knowledge: A Unified View, Software Security Unified Knowledge Architecture, A Bird's-Eye View of Software Security Knowledge Catalogs, Principles, Guidelines, Rules, Attack patterns, Historical risks, Vulnerabilities, Exploits
Security Knowledge and the Touchpoints
The Department of Homeland Security Build Security In Portal, Knowledge Catalog: Principle Item: Principle of Least Privilege, A Principle, A Rule, Aspects of Software Assurance, Best Practices, Knowledge, Tools, Business case, Dynamic navigation
Knowledge Management Is Ongoing
Software Security Now
Purpose of taxonomy is to help software developers understand common coding mistakes that impact security. Taxonomy of coding errors is more positive than taxonomy of attack patterns. But both approaches are valid and necessary. Goal of this taxonomy is to help developers understand how they impact security with their work. Taxonomy here presented only provides a starting point. Taxonomy here is influenced by security problems often found in large enterprise software projects. Collection of common errors. Taxonomy changes as time goes by, focuses on concrete examples. Taxonomy is made up of two distinct kinds of sets:* Phylum: type or particular kind of coding error, e.g. illegal pointer value.* Kingom: collection of phyla that share a common theme, e.g. input validation and representation.
On Simplicity: Seven Plus of Minus Two, Input Validation and Representation, API Abuse, Security Features, Time and State, Error Handling, Code Quality, Encapsulation, Environment
The Phyla, Input Validation and Representation, Buffer Overflow, Command Injection, Cross-Site Scripting, Format String, HTTP Response Splitting, Illegal Pointer Value, Integer Overflow, Log Forging, Path Traversal, Process Control, Resource Injection, Setting Manipulation, SQL Injection, String Termination Error, Struts, Duplicate Validation Forms, Erroneous validate() Method, Form Bean Does Not Extend Validation Class, Form Field without Validator, Plug-in Framework Not in Use, Unused Validation Form, Unvalidated Action Form, Validator turned Off, Validator without Form Field, Unsafe JNI, Unsafe Reflection, XML Validation, API Abuse, Dangerous Function, Directory Restriction, Heap Inspection, J2EE Bad Practices, getConnection(), Sockets, Often misused, Authentication, Exception Handling, Path Manipulation, Privilege Management, String Maniplation, Unchecked Return Value, Security Features, Insecure Randomness, Least Privilege Violation, Missing Access Control, Password Management, Empty Password in Configuration File, Hard-Coded Password, Password in Configuration File, Weak Cryptography, Privacy Violation, Time and State, Deadlock, Failure to Begin a New Session upon Authentication, File Access Race Condition: TOCTOU, Insecure Temporary File, J2EE Bad Practices, System.exit(), Threads, Signal Handling Race Conditions, Error Handling, Catch NullPointerException, Empty Catch Block, Overly Broad Catch Block, Overly Broad Throws Declaration, Unchecked Return Value, Code Quality, Double Free, Inconsistent Implementations, Memory Leak, Null Dereference, Obsolete, Undefined Behavior, Uninitialized Variable, Unreleased Resource, Use After Free, Encapsulation, Comparing Classes by Name, Data Leaking Between Users, Leftover Debug Code, Mobile Code, Object Hijack, Use of Inner Class, Non-Final Public Field, Private Array-Typed Field Returned from a Public Method, Public Data Assigned to Private Array-Typed Field, System Information Leak, Trust Boundary Violation, Environment, ASP .NET Misconfiguration, Creating Debug Binary, Missing Custom Error Handling, Password in Configuration File, Insecure Compiler Optimization, J2EE Misconfiguration, Insecure Transport, Insufficient Session-ID Length, Missing Error Handling, Unsafe Bean Declaration, Weak Access Permissions, More Phyla Needed
A Complete Example, Often Misused: Authentication, Abstract, Explanation, Example 1, Recommendations
Lists, Piles, and Collections, Academic Literature, Vulnerabilities, Incomplete parameter validation, Inconsistent parameter validation, Implicit sharing of privileges/confidential data, Asynchronous validation/inadequate serialization, Inadequate identification/authentication/authorization, Violable prohibition/limit, Exploitable logic error, Attacks, Stealing passwords, Social engineering, Bugs and Back Doors, Authentication Failures, Protocol Failures, Information Leakage, Exponential Attacks, Viruses and Worms, Denial-of-Service Attacks, Botnets, Active Attacks, Toward a Taxonomy, Nineteen Sins Meet Seven Kingdoms, Input Validation and Representation, Buffer Overflows, Command Injection, Cross-Site Scripting, Format String Problems, Integer Range Errors, SQL Injection, API Abuse, Trusting Network Address Information, Security Features, Failing to Protect Network Traffic, Failing to Store and Protect Data, Failing to Use Cryptographically Strong Random Numbers, Improper File Access, Improper Use of SSL, Use of Weak Password-Based Systems, Unauthenticated Key Exchange, Time and State, Signal Race Conditions, Use of "Magic" URLs and Hidden Forms, Error Handling, Failure to Handle Errors, Code Quality, Poor Usability, Encapsulation, Information Leakage, Environment, Seven Kingdoms and the OWASP Ten, Input Validation and Representation, OWASP A1: Unvalidated Input, OWASP A4: Cross-Site Scripting (XSS) Flaws, OWASP A5: Buffer Overflows, OWASP A6: Injection Flaws, API Abuse, Security Features, OWASP A2: Broken Access Control, OWASP A8: Insecure Storage, Time and State, OWASP A3: Broken Authentication and Session Management, Error Handling, OWASP A7: Improper Error Handling, Code Quality, OWASP A9: Denial of Service, Encapsulation, Environment, OWASP A10: Insecure Configuration Management
Go Forth (with the Taxonomy) and Prosper, Taxonomy goals, Simple, Intuitive to a developer, Practical (rather than theoretical and comprehensive), Amenable to automatic identification of errors with static analysis tools, Adaptable with respect to changes in trends that happen over time