Slide 1

Slide 1 text

SECURE SDLC FOR SMALLER TEAMS SECURITY AS A PROCESS

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

WHO IS USING IT? WINDOWS 10

Slide 4

Slide 4 text

WHO WAS USING IT? WINDOWS XP

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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.

Slide 8

Slide 8 text

?

Slide 9

Slide 9 text

(EXCERPT) SDL TIMELINE AT MICROSOFT Source

Slide 10

Slide 10 text

SOFTWARE DEVELOPMENT LIFECYCLE Source:Wikimedia

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

MICROSOFT SDL Source: Microsoft SDL practices

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

DEMO

Slide 19

Slide 19 text

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.

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

THAT’S ALL I GOT

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

THANK YOU.