Online Mind Mapping and Brainstorming

Create your own awesome maps

Online Mind Mapping and Brainstorming

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.

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).

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).

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.

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.

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.

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.

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.

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.

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.

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.

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.