Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Security as a process

Security as a process

We will look into the software development lifecycle, how to turn it into a secure software development lifecycle and take a look at a tool that can help with that even if you are just a small team and not a large process driven company.

Frank Kleine

October 12, 2019
Tweet

More Decks by Frank Kleine

Other Decks in Programming

Transcript

  1. SECURE SDLC FOR
    SMALLER TEAMS
    SECURITY AS A PROCESS

    View Slide

  2. FRANK KLEINE
    • Software Architect @ United
    Internet Corporate Service
    GmbH
    • Security SPOC for
    department
    • Love travelling with railways
    • Critic, rants etc about the
    talk: @bovigo

    View Slide

  3. WHO IS
    USING IT?
    WINDOWS 10

    View Slide

  4. WHO
    WAS
    USING IT?
    WINDOWS XP

    View Slide

  5. STUDY FROM 2004
    HOW SECURE WERE OPERATING SYSTEMS?
    • Windows XP + SP1: 4 minutes on Internet before compromised
    • Windows XP + SP1 + ZoneAlarm: most secure, not compromised
    • Windows XP + SP2: not compromised
    • Windows Small Business Server 2003: 8 hours until compromised
    • Mac OS X 10.3.5, Linspire (Linux): not compromised
    Source: Automated “Bots” Overtake PCs Without Firewall Within 4 Minutes

    View Slide

  6. SOME REASONS
    WHY WAS WINDOWS INSECURE?
    • Not created with computers connected to the world in mind
    • Attacks from outside simply weren’t an issue
    • Suddenly, everyone connects their computers to the internet
    • Probably missing knowledge about new security risks attached to
    the new usage scenarios

    View Slide

  7. THINGS CHANGED
    TODAY
    • We commonly don’t talk about Windows being insecure by default
    any more.
    • Yes, there are still attacks and security fixes are issued all the
    time, but they don’t gain headlines most of the time.
    • Most attacks today require user interaction - back then they
    didn’t.

    View Slide

  8. ?

    View Slide

  9. (EXCERPT)
    SDL TIMELINE AT MICROSOFT
    Source

    View Slide

  10. SOFTWARE DEVELOPMENT LIFECYCLE
    Source:Wikimedia

    View Slide

  11. THINK ABOUT SECURITY IN ALL PHASES.
    AND SECURE?
    • Requirements analysis: identify security requirements and
    objectives
    • Design: identify important components, think about risks
    • Implementation: write tests, do code reviews, use available tools
    to prevent security flaws
    • Testing: search systematically (and automatically) for security flaws
    • Evolution: provide means to react quickly on discovered flaws

    View Slide

  12. THAT’S NICE, BUT WE ARE NOT MICROSOFT
    HOW TO START?
    • Learn about what’s available
    • Pick something to start with
    • If it works for you - great, go ahead and pick the next one
    • If it doesn’t - abandon and try something else

    View Slide

  13. MICROSOFT SDL
    Source: Microsoft SDL practices

    View Slide

  14. STARTED IN 2017, BUT SEEMS TO BE DEAD
    OWASP SSDLC PROJECT
    Source: OWASP

    View Slide

  15. TL;DR?
    OWASP APPLICATION SECURITY VERIFICATION STANDARD
    Source: OWASP

    View Slide

  16. ORIGINALLY STARTED AT 1&1
    NOW AN OFFICIAL OWASP PROJECT
    OWASP SECURITYRAT
    Source: OWASP

    View Slide

  17. A TOOL THAT MAY HELP
    SECURITYRAT
    The core functionality of SecurityRAT ("Requirement Automation Tool") can be described in the
    following steps:
    1. You tell SecurityRAT what kind of a software artefact you're going to develop / are running
    2. SecurityRAT tells you which requirements you should fulfil.
    3. You decide how you want to handle the desired requirements.
    4. You persist the the artefact state in an issue tracker and create tickets for the
    requirements where an explicit action is necessary
    5. Throughout the continuous development of the particular artefact, you respect the rules
    defined in SecurityRAT and document relevant changes in requirement compliance
    whenever appropriate.
    Focus of SecurityRAT is currently put on automation of procedures rather than quality of
    requirements. There is a set of requirements provided which you can start with, nevertheless it is
    recommended to create your own set of requirements which fits your company risk profile.
    Source: OWASP

    View Slide

  18. DEMO

    View Slide

  19. HOW MUCH OF A TIME SINK IS THAT?
    EFFORTS
    • Setting up SecurityRAT: 1 day
    • Modifying the requirements to your needs: how much time are
    you willing to spend?
    • Tip: start with the requirements that the default set brings, and
    whenever you think one isn’t right just modify it then. Don’t
    rework all the requirements right on introduction.
    • For the actual run-through when a new project is started: 60-90
    minutes. Your mileage may vary.

    View Slide

  20. BECAUSE THERE’S A LOT MORE TO DISCOVER
    SOME MORE LINKS
    • Addressing Security Requirements in Development Projects -
    Daniel Kefer, René Reuter @ AppSecEU 16
    • SecurityRAT @ Github
    • Microsoft SDL Progress Report from 2010
    • Microsoft Security Development Lifecycle
    • OWASP Application Security Verification Standard

    View Slide

  21. THAT’S ALL I GOT

    View Slide

  22. NOT THE USUAL “WE HAVE JOBS” ANNOUNCEMENT
    I’M LOOKING FOR A NEW JOB
    • Software Architect
    • Developer (mainly Go & PHP)
    • @bovigo

    View Slide

  23. THANK YOU.

    View Slide