Secure software development. NGI 27 mei Zoetermeer Leo van Koppen

Transcriptie

1 Secure software development NGI 27 mei Zoetermeer Leo van Koppen

2 Gebruik van Socrative voor interactiviteit Internet is beschikbaar SSID: DIF Password: Dalhem079 Download Socrative student app Of ga naar: m.socrative.com Join Room number: Geef uw mening en of antwoord op de voorgelegde vragen

3

4 Actualiteit keek op de week

5 Richard A. Clarke Richard Alan Clarke (Boston, oktober 1951) was een Amerikaans overheidsfunctionaris. Hij verschafte nationaal veiligheidsadvies aan de Amerikaanse presidenten Ronald Reagan, George H.W. Bush, Bill Clinton en George W. Bush op het gebied van inlichtingendiensten en terrorisme van 1973 tot Clarkes specialiteiten waren cyber security, antiterrorisme en homeland security. Hij was de antiterrorisme-adviseur in de VS National Security Council ten tijde van de aanslagen op 11 september Hij trad in januari 2003 terug.

6 Waarom een lezing over software security? Omdat.. we hackers (in welke hoedanigheid dan ook) te veel kansen geven criminele activiteiten uit te kunnen voeren we de georganiseerd misdaad de kansen bieden om onze business te ondermijnen.. we criminele regiems de mogelijkheden geven om onze veiligheid in gevaar te brengen Omdat de bestrijding van cyber criminaliteit adequater moet worden aangepakt! en o ja zeker! mensen maken (de) fouten!

7 Waarom de focus op secure software development? Omdat. De software laag een zwakke schakel is IT-infrastructuur en bedrijfsorganisatie zijn minder kwetsbaar voor aanvallen Security requirements bij aanvang (meestal) geen rol spelen Tijd en functionaliteit lijken de enige criteria te zijn Kwaliteit niet alleen in de testfase kan worden aangetoond De complexiteit van de hedendaagse software eist een gedegen en gestructureerde aanpak. Het was al genoemd Mensen zijn de zwakke schakel. ook bij het maken van software

8 Software development Kenmerk (traditioneel): een gestructureerde aanpak modellen en methoden SDM, RAD, UML, Unified Process Gestructureerd testen, TMAP Testen meenemen in design (RUP) Hulpmiddelen Web-richtlijnen NCSC SSD CIP-overheid Normenkader icomply en OWASP Al jarenlang een belangrijke referentie

9 OWASP testing framework work flow

10 Secure development: drie pijlers (Gary McGraw) Risk management Continuous process Identify technical risk for the business Define a mitigation ISM strategy Information Security Management 7 Touchpoints Code review Risk analysis Penetration testing Risk based testing Abuse cases Security requirements Security operations Knowledge Security awareness Competences 10

11

12 Noodzaak is er.. Waarom lijken we de strijd te verliezen? We weten het wel, maar doen het niet Alleen aandacht voor functionaliteit, tijd (en geld) Security valt vaak in de categorie should or would haves Waar te beginnen? Bewustmaken! Motiveren! Faciliteren! Confronteren! Afdwingen! Wie en hoe? verschillende stakeholders Inzicht geven! risicoanalyse Hulpmiddelen/ Methoden OWASP Responsible disclosure Regelgeving, wetgeving

13 Randvoorwaarden voor een secure aanpak? Ambitie van leverancier Men ziet de noodzaak in! Kwaliteit (betrouwbaarheid) leveren Ambitie van de klant Onderdeel van de requirements, aanpak en/of oplevering Standaarden hanteren ISO, IEEE, PCI-DSS, PAS standaards Methodieken hanteren, zoals OWASP (knowledge, good practices & tools) Microsoft SDLC (secure development lifecycle ) Afdwingen Compliancy? Wetgeving en naleving Regulering (garantie van kwaliteit van software)

14 Programma Methodiek: Martin Knobloch OWASP Risk management Frans van Gessel Responsible disclosure David van Es ISM-student i.o.v. SURF Secure development Marcel Koerts Secure development ( Pauze Normenkader voor secure software development Hans de Vries/ Fred Hendriks Interactieve discussie Stellingen en vragen

15 Gebruik van Socrative voor interactiviteit Internet is beschikbaar SSID: DIF Password: Dalhem079 Download Socrative student app Of ga naar: m.socrative.com Join Room number: Geef uw mening en of antwoord op de voorgelegde vragen

16 Martin Knobloch OWASP

17 Frans van Gessel Risico s

18 David van Es responsible

19 Marcel Koerts Secure Software Development

20 Pauze

21 Hans de Vries Normenkader

22 Interactieve sessie: Stellingen Stelling 1:. Stelling 2: Security moet je inbouwen en niet aanbouwen! Dat geldt met name bij software ontwikkeling Stelling 3: Security inbouwen is een kwestie van methodiek. Software development is van oudsher sterk gedomineerd door een methodische aanpak, dus secure software ontwikkeling kan vrij eenvoudig secure worden gemaakt! Stelling 4: Voorafgaande aan een software ontwikkeltraject moet te allen tijden de betrouwbaarheidseisen (BIV) worden vastgesteld Stelling 5: Secure development moet worden afgedwongen met normenkaders waartegen geaudit kan worden!

23 Interactieve sessie: Stellingen Stelling 6: Secure development moet worden afgedwongen vanuit wetgeving Stelling 7: Uses cases kunnen niet zonder abuse cases Stelling 8: Kwaliteit (betrouwbaarheid) van software is een aparte feature bij aankoop Stelling 9: Software onderdeel vormt van de kritische infrastructuur dient aan wettelijke security eisen te voldoen Stelling 10: Responsible disclosure maakt het mogelijk dat software effectief getest kan worden (crowd testing) Stelling 11: Geleden schade veroorzaakt door in de software kan worden verhaald op de ontwikkelaar

24 JA/NEE/geen mening- vragen Aandacht voor security start al bij hello world Betrouwbaarheid van software is extra requirement en daar betaal je voor. Software heeft een keurmerk nodig Software heeft een garantie certificaat nodig Software voor overheidsinstellingen dient te voldoen aan wettelijke eisen Virtualisatie software, embedded software en OS en dienen met een garantiecertificaat te worden opgeleverd. Een normenkader is een goede stap naar kwaliteitssoftware Biedt het werken met een methodiek voldoende garantie? Is wetgeving een voorwaarde om kwaliteit van software af te dwingen? Is het opleggen van een methodiek een juiste start voor secure development?

25 Meerkeuze vragen Welke van de security activiteiten spreekt u meest aan? Risicomanagement/ abuse cases/ code reviews/ pentesting/allemaal Wanneer wordt een kwaliteitsgarantie voor software noodzakelijk? Altijd/ als het een requirement is/ bij privacy/ bij kritische infrastructuur Vier ogen principe bij de software ontwikkeling is vereist: Altijd/ als het een requirement is/ bij privacy / bij kritische infrastructuur

26 Veilige software? Dat is moeilijk, dat moet je aan de softwarebouwer overlaten. Afspraken over veilige software regel je in een contract. Veilige software dat is een kwestie van goed testen. Eisen stellen aan veiligheid kost geld

27 Terminologie Application security is about protecting software and the system that software runs in a post-facto way, after development is complete Information Security can be defined as: The concepts, techniques, technical measures, and administrative measures used to protect information assets from deliberate or inadvertent unauthorized acquisition, damage, disclosure, manipulation, modification, loss, or use

28 software engineering proces (used by ESA)

29

30