Software Development Lifecycle & Development Models

• Who is involved during the SDLC?

  • Developers

  • Testers

  • Software Architects

  • Security Architects

  • Project managers

  • Clients

• 

  • Planning – Market to ship software, training, incorporate security.

  • Business requirements and analysis – Including security, but other features needed. A way to measure results.

    • Software requirements

      • Internal (libraries, storage)

      • External (connections)

      • Hardware

      • Users

  • Design

    • Devs involved

    • Risk analysis

    • Legacy or new code?

    • Functional requirements

    • Security requirements

    • Audit and debug methods

  • Implementation

    • Dev phase

    • Actual coding happens

    • Code review

    • Unit testing

    • Security: white box testing. See whole source code.

  • Testing

    • Functionality tests

    • Static analysis

    • Dynamic analysis

    • Security testing

      • Gray box

      • Black box

    • You will break your code

  • Deployment

    • Pushing the code out

    • Delivery vs deployment

    • Secure distribution

      • Code signing

      • DRM

      • Licensing

  • Maintenance

    • Ongoing monitoring

    • Break and fix

    • Patching

      • Functionality

      • Security

    • Monitor external dependencies

  • Retirement, End Of Life

    • End of maintenance

    • Purchased?

    • Retiring the software

      • External services

      • Active user accounts

    • Use the docs if you have them!

• OWAS Software Security Assurance Process

• Microsoft Secure Development Lifecycle

• SANS on secure coding

• Software development methods

  • Chaos

    • Just code

    • Fix when possible

    • Not really documented

    • Not measurable

    • Not thoroughly tested

    • Pros: good for small projects

    • Cons: everything else

  • Waterfall

    • You have a plan

    • A very strict plan

    • Focus on one phase at a time

    • Advance when only one phase is 100%

    • Pros:

      • Simple to understand

      • Works if perfectly planned

    • Cons:

      • Difficult to implement

      • Works only if perfectly planned

  • Agile

    • Values and principles

      • People and interactions

      • Working software is most important

      • MVP – Minimum viable product

      • Welcome change

      • Rapid response to change

    • Pros:

      • Teamwork

      • Realistic

      • Flexible

    • Cons

      • Not so good for complexity

      • Goals not very clear

      • High dependency on individuals

  • Iterative

    • Not full specs, just a part

    • Advance between iterations

    • Pros:

      • Good when reqs are well-defined

      • But some functionality is requested later

      • Easy to measure progress

    • Cons:

      • Requires more resources

      • Not so good for changing requirements

      • Not useful for small projects

  • Spiral

    • Waterfall + Iterative

    • Incremental releases

    • No linear path

    • Pros:

      • Good for long term projects

      • Changing requirements

      • smaller iterations, smaller risk

    • Cons:

      • Hard to manage

      • Many in-between phases