Developing Secure Software

Developing Secure Software

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
       • 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
     • Implementation phase: the code should be reviewed it it should be formally stated who can modify the code
       • Test plans must be followed throughout implemntation and development
     • Testing Phase: testing the security of the application is a crucial part of the testing phase
       • External Reviews
       • Security Pushes
     • Maintainence Phase: The security of the application should continue to be checked and updated
       • Including a good response service to bug reports

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

3. Secure by Design, Default and Deployment

   • Secure by Design
     • 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
   • Secure by Default
     • 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
   • Secure by Deployment
     • Provide good security documentation
     • Patch quickly and well
     • Provide easy access to safety resources
   • Additional Principles:
     • 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

4. Threat Modeling

   • You can only defend a system if you have an idea of how people may try an compromise it
     • Additional benefits of threat modeling
       • 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
     • Threat modeling is time-consuming, but pretty easy
   • The process
     • 1. Decompose Application
       • 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
     • 2. Determine Threats
       • 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
     • 3. Rank Threats
       • Threat tree's
         • We can use our threat classification to categorize threats into a tree, and can then model them.
     • 4. Mitigation