Create your own awesome maps

Even on the go

with our free apps for iPhone, iPad and Android

Get Started

Already have an account?
Log In

Software Security by Mind Map: Software Security
5.0 stars - 2 reviews range from 0 to 5

Software Security

Part 1: Software Security Fundamentals

1. Defining a Discipline

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

2. A Risk Management Framework

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

Part 2: Seven Touchpoints for Software Security

3. Introduction to Software Security Touchpoints

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

Moving Left

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

4. Code Review with a Tool

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

Ancient History

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

5. Architectural Risk Analysis

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

Knowledge Requirement

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

6. Software Penetration Testing

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

7. Risk-Based Security Testing

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

8. Abuse Cases

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

9. Software Security Meets Security Operations

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

Part 3: Software Security Grows Up

10. An Enterprise Software Security Program

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

Continous Improvement

What about COTS (and Existing Software Applications)?, An Enterprise Information Architecture

Adopting a Secure Development Lifecycle

11. Knowledge for Software Security

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

12. A Taxonomy of Coding Errors

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