Developing Secure Software - created from Mind Map

Page 1

Stages of Security

Security should be factored into every stage of the software development life cycle

Design Phase: a threat model should be drawn up, this will then be refered to and followed throughout the rest of the development process

Implementation phase: the code should be reviewed it it should be formally stated who can modify the code

Testing Phase: testing the security of the application is a crucial part of the testing phase

Maintainence Phase: The security of the application should continue to be checked and updated

Security questions should be asked and followed up during interviews

Threat modeling should be a key part of the design process and not rushed

When the design is complete it should be reviewed by the security team

The bug bar and the end-of-line plans should be set too

Test plans must be followed throughout implemntation and development

External Reviews

Security Pushes

Including a good response service to bug reports

Analiseing a Bug

After a bug is detected a triage process is carried out to determine when how and if a bug is going to be fixed

How many people does this bug affect?

How core is it to the requirements?

How much effort will it take to fix?

How likley is fixing the bug going to cause regression bugs?

(pretty much) All software has bugs in it, just some are so minor or hard to fix, that it's just not worthwhile amending them

Secure by Design, Default and Deployment

Secure by Design

Secure by Default

Secure by Deployment

Additional Principles:

Security should start before the project starts

Guidelines should be produced for all aspects of the project

Learn from project mistakes, and update guidelines and search for similar problems when a potential bug is discovered

Try and work out how the software may be broken, during the design phase (use threat models)

Code that is dificult to maintain should not be used

Don't give users any higher privalages than is absolutley necissary

Keep it simple

Only include features the are essential

Sensitive data should be treated with care

Provide good security documentation

Patch quickly and well

Provide easy access to safety resources

Minimize your attack surface

Use defense in depth

Backwards compatibility can cause issues

Employ secure defaults

Assume external systems are insecure

Plan on failure

Security features are not secure features

Don't mix code and data

Fix security issues correctly

Threat Modeling

You can only defend a system if you have an idea of how people may try an compromise it

The process

Additional benefits of threat modeling

Threat modeling is time-consuming, but pretty easy

You can understand your code better

You'll find more of the bugs before the users do

They can be used by others to understand your program

They help with testing

1. Decompose Application

2. Determine Threats

3. Rank Threats

4. Mitigation

Must be done in a rigorous and formal manor

Modelling should be used

Data flow diagrams

UML activity diagrams

Capture how information flows through your program

Layered, start at a high level and work down the levels

For each model determine how you and others would break it

STRIDE

Spoofing Identity - can the attacker pretend to be someone there not?

Tampering with data - can the attacker maliciously manipulate data

Repudiation - can the attacker be anonymous

Information Disclosure - can the attacker gain access to information they wearn't supposed to know

Denial of Service - can the attacker use DoS on other users?

Elevation of Privilege - can the attacker access places they shouldn't be

Threat tree's

We can use our threat classification to categorize threats into a tree, and can then model them.

Developing Secure Software