In opdracht van SPL

en uitgevoerd door

Leo van Koppen MSIT

Cyber security ambassador

info@ES4CS.NL

4-3-2018 (CC) ES4CS.NL 1

master class

Veilig programmeren

Veilig programmeren

• Keuzedeel MBO - K0501

• Bij het ontwerpen van applicaties worden beveiligingsaspecten onderschat en weinig meegenomen.

• In de kwalificatiedossiers zit alleen een kleine basis aan security-onderwerpen.

• De wereld wordt echter steeds ‘digitaler’ en de beveiliging hiervan wordt meer en meer belangrijk.

• Om op de arbeidsmarkt snel in te kunnen spelen op specifieke beveiligingsonderwerpen of om beter voorbereid naar (specifieke) opleidingen in het hbo door te stromen is het volgen van het betreffende keuzedeel een pré

4-3-2018 (CC) ES4CS.NL 2

Doel master class

• Introductie in het ontwikkelen van veilige software

• Belang inzien van de noodzaak van het ontwikkelen van veilige software

• Aanleren te denken in security risico’s (Risicodenken ≠ paranoïde)

• Introductie in software ontwikkel methoden en best practices

• Aanbevelingen bij implementatie van het keuzedeel in het onderwijs

• Leerzame discussies voeren die het bovenstaande ondersteunen(veel onderwerpen in de slides, gedurende de dag selecteren waar behoefte aan is )

4-3-2018 (CC) ES4CS.NL 3

Voorstellen

“Schot voor de boeg” • Vandaag de dag hebben we het over smart

cars, smart cities, smart industry en natuurlijk het Internet of Things

5

Smart betekent in deze context (volgens mij) : gebaseerd op software algoritmes en big data

het ontstaan van een sterke afhankelijkheid van de kwaliteit van de software

We zullen de nieuwe smart producten zeer betrouwbaar moeten maken want anders zal… … het aantal security incidenten enorm toenemen

… en daarmee onze maatschappij ernstig verstoren

Dat betekent: security meenemen in het ontwerpproces

Software by design– privacy by design -

Zie ook rapport Cyber security raad:“Naar een veilig verbonden samenleving” https://www.cybersecurityraad.nl/030_Publicaties/

1. Introductie

2. Probleemverkenning • Noodzaak – incidenten – ontwikkelingen

3. Ontwikkelen van veilig software• Methoden en best practices

4. Risicodenken • Kroonjuwelen – dreigingen – kwetsbaarheden – gevolgen – tegenmaatregelen

5. Secure software development• Leidraad; SSD gebaseerd op Gary McGraw: Citigal (BSIMM)• Security requirements – ontwerp/architectuur – veilige coderen – penetration testing

6. Security maatregelen

7. Implementatie keuzedeel • Aanpak – tools + hulmiddelen – technische inrichting – referenties

Takeaways4-3-2018 (CC) ES4CS.NL 6

4-3-2018 (CC) ES4CS.NL 7

Cybersecurity anno 2016/2017

Bron CSBN 2016

De mogelijkheden hiertoe worden in (te) veel gevallen geboden door kwetsbaarheden in configuratie en software

De complexiteit van het product staat haaks op het leveren van een goede kwaliteit (beveiliging)

2.Noodzaak

Noodzaak • In veel situaties waar hacks hebben plaatsgevonden is er sprake van

het uitbuiten van zwakheden (vulnerabilities) in software.

• Applicaties zijn opgebouwd uit meerdere en soms ook oude (non-secure ontwikkelde) onderdelen en bevatten vulnerabilities die misbruikt (exploited) kunnen worden. • Soms pas na jaren!

• Hackers kunnen ongestoord en meestal onopgemerkt hun gang gaan.• Gemiddeld duurt het 202 dagen voordat een databreach ontdekt wordt (HPE

security trend report)

• Softwareleverancier wordt weleens vergeleken met een drugsleverancier: “er is geen enkele garantie op de kwaliteit van het spul dat geleverd wordt en toch raak je eraan verslaaft”

Security (= betrouwbaarheid garanderen/waarborgen)

• Betrouwbaarheid waarborgen van kritische informatie (kroonjuwelen) en kritische bedrijfsprocessen • Betrouwbaarheid gedefinieerd in (BIV):• Beschikbaarheid toegang tot /gebruik van informatie is gegarandeerd• Integriteit correctheid, juistheid, volledigheid van informatie• Vertrouwelijkheid exclusiviteit van informatie tussen partijent.g.v. afhankelijkheid van bedrijfsprocessen van informatie (voorziening) geldt:• Continuïteit van bedrijfsprocessen kan worden gewaarborgd

• Betrouwbaarheid speelt op alle lagen van een organisatie

MENSEN

BEDRIJFSPROCESSEN

APPLICATIE/DATA/INFO

INFRASTRUCTUUR

RISICO’S

ORGANISATIE

Bedreigingen

Het probleem• “Het cybersecurity probleem is (vaak) een software security probleem !”

• Kwetsbaarheden, ontwerpfouten, bugs, verkeerde configuraties, etc.

• Software security is (nog steeds) niet op de radar bij veel organisaties …en helaas ook niet bij veel software bedrijven en ontwikkelaars

• Het goede nieuws is: “Times are changing”• AVG/GDPR invloed

• Overheid + politiek

• Dat zet aan tot actie!

12

Intermezzo

Discussie

• (h)erken je het probleem dat security incidenten ontstaan t.g.v. matige kwaliteit van software

• Zouden software ontwikkelaars aansprakelijk moeten worden gesteld voor de matige kwaliteit?

• Waarom zetten software ontwikkelaars niet sterker in op non-functional requirements?

• Hoe staat het met de eigen verantwoordelijkheid van software ontwikkelaars?

4-3-2018 (CC) ES4CS.NL 13

3. Veilig programmeren• Waarom zou je secure software willen ontwikkelen?• “Omdat je het wil”

• Kritische data die beschermd moet worden• Kritische processen die bestuurd worden met deze software• Het past bij het imago van de organisatie

• “Omdat het moet”• Wetgeving zoals ”wet datalekken” of “Europese privacy verordening (GDPR)“• Regelgeving via normen, bijv. NEN7510 in de gezondheidszorg • Of internationale regelgeving zoals Basel I, II, III in de financiële wereld• Procesindustrie, telecom, infrastructuur e.a. hebben soortgelijke reguleringen en

wetgeving

Bij softwareontwikkeling wordt te vaak teveel de prioriteit gelegd bij functionaliteit (functionele requirements) en ontwikkeltijd en security en andere kwaliteitsaspecten (non functionalrequirements) zijn vaak slechts bijzaak, krijgen geen of nauwelijks prioriteit

Noodzaak (je wil het!) Security requirements krijgen te weinig aandacht. Met als gevolg problemen en daarmee extra kosten.

Noodzaak- feiten Problemen: datalekken en gehackte of gecompromitteerde systemen

Noodzaak – (je moet het) Is er rekening gehouden met wetgeving? (datalekken, privacy)

Noodzaak- trends

• Wat is de stand van zaken?

• Meer organisaties zien de noodzaak van security requirements in.

• Security is nog te veel herstelwerk en te weinig “security by design”

19

Motivatie• Bijna elk software ontwikkelproces is in de basis onvoldoende

ingericht om security kwesties adequaat aan te pakken

• Voortdurend worden ontwerpfouten (security flaws) te laat gesignaleerd in de ontwikkelcyclus, met als gevolg:• Hogere kosten van herstel

• Hogere beheerkosten

• Bijna alle organisaties besteden tijd en aandacht an networksecurity (Firewalls, IDS, etc ) en IT-beheer

• …maar slechts een klein deel daarvan investeert ook in een security strategie voor applicatieontwikkeling zoals: security by design, code reviews e.a.

20

Dus….

• De sleutel tot een verbeterde security is, een gedegen procesinrichten waarbij meetbaar betere security kan worden opgeleverd.

• Er moet een verandering plaatsvinden in het proces van softwareontwikkeling, waarbij een sterke focus is op security

• DOEL: breng het aantal security vulnerabilities terug door meer aandacht te besteden aan ontwerp, implementatie en documentatie

• Identificeer en verwijder vulnerabilities tijdens het ontwikkelproces zo vroeg mogelijk!!!

Intermezzo

Discussie

• Zwakheden in de software ontstaan vooral door:• fouten (bugs) die worden gemaakt tijdens het coderen

• fouten tijdens het ontwerp (onvoldoende nagedacht)

• het niet detecteren van fouten in de software tijdens het testen

• Wat zouden bezwaren kunnen zijn voor invoering van security by design?

• Wat is dé (meest) efficiënte aanpak bij het voorkomen van fouten?

4-3-2018 (CC) ES4CS.NL 21

Noodzaak van “security by design”

(NIST, Barry Boehm)

Een fout herstellen van software in productie is 150X zo duur dan in requirements fase

24

3. Ontwikkelen van Secure Software

Drie essentiële onderdelen

• Eenduidig ingericht proces inclusief risicoanalyse

• Goede methoden, technieken en tools

• Kennis en vaardigheden van de software engineer

• Eenduidig proces gebaseerd op:

• S(S)DL – Secure (Software)Development Lifecycle• Ingericht in traditionele of modern software development lifecycle

techniques

• Waarbij in elke fase van de ontwikkeling aandacht is voor security

Overzicht secure software development methods

• Basis: methode SSD van Citigal/ Gary McGraw• Aangevuld mijnerzijds met basis elementen security

• Frameworks • CIP (outsourcing) • Microsoft SDL (software development life cycle)• Secure software foundation • OWASP, • OpenSAMM, BSIMM

• Good practices • Richtlijnen bijv NCSC)• OWASP testing guide

25

Positionering• Standards : ISO27001; NEN 7510; ISO25010, Common Criteria

• Best practices:

• OWASP

• GRIP op SSD van het CIP

• Frameworks:

• Microsoft SDL

• Secure Software alliance

• Maturity models: • BSIMM

• OpenSAMM

• (werken aan volwassenheid/maturity)

26

• Befaamd om de OWASP top 10!• Belangrijke referentie

• Er is veel meer dan dat!• Check it out! OWASP.ORG

4-3-2018 (CC) ES4CS.NL 27

Grip op Secure Software Development

• Randvoorwaarden:

• Inrichting en volwassenheid van de organisatie

• Kennis & awareness bij stakeholders

3 pijlers

• Contactmomenten

• Standaard beveiligingseisen

• Processen

• Resultaat secure software development proces• http://www.cip-overheid.nl/downloads/grip-op-ssd/

Overzicht van het proces

Microsoft

4-3-2018 (CC) ES4CS.NL 30

2002 at Microsoft: Bills Memo about Trustworthy computing

Microsoft secure software development

Education Accountability

Administer and track security training

IncidentResponse (MSRC)

Establish release criteria and sign-off as

part of FSR

Ongoing Process Improvements

Process

Guide product teams to meet SDL requirements

Secure software alliance https://securesoftwarealliance.org/

BSIMM Building Security In

• The Building Security In Maturity Model

• Gary McGraw and Cigital

• Gebruikmakend van 7 Touchpoints

33

BSIMM a Software Security Framework

• Four domains/ Twelve practices See informIT article on BSIMM

• OpenSAMM Software Assurance Maturity Modelhttp://www.opensamm.org

a framework for the governance of development processes of (secure) software in your business

35

OpenSAMM Security Practices• The Security Practices cover all areas relevant to software

security assurance• Each one is a ‘silo’ for improvement

Intermezzo

Discussie

• Vanuit het voorgaande, m.n. beide maturity modellen OpenSAMM en BSIMM, is de vraag welke onderdelen uit deze modellen passen binnen het MBO ?

Stelling

• “Veilig programmeren is in het MBO een keuzedeel, maar gezien de noodzaak van veilige software, moet het een integraal onderdeel zijn van de kwalificatie dossier van de applicatieontwikkelaar”

4-3-2018 (CC) ES4CS.NL 37

Drie pilaren van software security *)

• Risico management

• Touch points (best practice) van secure software development

• Kennis en vaardigheden van de engineers

*) based on Gary McGraw, Software security (building software in)

38

Kennis en vaardigheden

• Een vakman/vrouw (competente professional), met kennis van zaken

• In staat zijn om….• Juiste inschatting te maken van de situatie

• Weten hoe aan te pakken

• Juiste gereedschappen te gebruiken

• Goede methoden/werkwijzen te kiezen in verschillende omstandigheden

• Kwaliteit te leveren

• Competente professional• “het is de vent en niet de tent”!

• “aan zijn gereedschap herken je de vakman”

4-3-2018 (CC) ES4CS.NL 40

Uit het keuze deelKennis• Heeft specialistische kennis van gangbare en specifieke beveiligingseisen voor applicaties (zoals authenticatie,

autorisatie, het beperken van complexiteit, defence in depth en safe by default)

• Heeft specialistische kennis van de do’s en don’ts van specifieke beveiligingseisen voor applicaties

• Heeft specialistische kennis van de consequenties van wetgevingen omtrent computercriminaliteit en de bescherming van persoonsgegevens voor het ontwikkelen van veilige applicaties

• Heeft specialistische kennis van verschillende manieren om fouten binnen een applicatie effectief af te handelen

• Heeft specialistische kennis van verschillende manieren om cryptografie toe te passen om een applicatie te beveiligen

• Heeft specialistische kennis van de frameworks van OWASP en SANS waarin de meest voorkomende kwetsbaarheden van`software en hun oplossingen zijn beschreven

• Heeft specialistische kennis van de aanpak Secure Software Development (SSD) waarin de aanpak beschreven staat om te komen tot veilige applicaties

• Heeft specialistische kennis van de veiligheidsaspecten van services, input/output en privileges die door een applicatie gebruikt kunnen worden

• Heeft specialistische kennis van de technieken die gebruikt worden voor het patchen van veiligheidslekken in software

• Heeft specialistische kennis van de belangrijkste technieken en hulpmiddelen die gebruikt worden voor het verifiëren of een applicatie kwetsbaar is voor aanvallen (pentesten)

• Heeft specialistische kennis van de beveiligingsaandachtspunten ten behoeve van de acceptatietest van een applicatie, waaronder het achterhalen van niet gespecificeerde ongewenste functionaliteit

4-3-2018 (CC) ES4CS.NL 41

Vervolg, uit het keuze deelVaardigheden

• Kan in overleg met gebruikers en beheerders specifieke beveiligingseisen voor een applicatie opstellen en deze uitleggen aan de opdrachtgever

• Kan specifieke beveiligingseisen van een applicatie beoordelen en de bevindingen toelichten aan gebruikers, beheerders en/ofde opdrachtgever

• Kan gangbare en specifieke beveiligingseisen voor een applicatie verwerken in een testplan

• Kan controleren of een ontwerp van een applicatie voldoet aan gangbare beveiligingseisen en de bevindingen toelichten aan gebruikers, beheerders en/of de opdrachtgever

• Kan een effectieve foutafhandeling binnen een applicatie ontwerpen en uitleggen aan medeontwikkelaars

• Kan cryptografische technieken toepassen om een applicatie te beveiligen

• Kan controleren of de eigen code en code van anderen voldoen aan gangbare en specifieke beveiligingseisen

• Kan de authenticatie van gebruikers in een applicatie op een veilige manier implementeren

• Kan op een veilige manier autorisaties implementeren

• Kan relevante handelingen van gebruikers vastleggen in een logbestand of database

• Kan het juiste gebruik van een applicatie controleren en/of achteraf fouten en overtredingen opsporen en dit toelichten aan gebruikers, beheerders en/of de opdrachtgever

4-3-2018 (CC) ES4CS.NL 42

4.“Risicodenken”

• De basis van (cyber) security is het denken in risico’s• Formeel, risicomanagement is het startpunt voor het inrichten van

beveiligingsmaatregelen

• Risicodenken • Wat is van waarde dat bescherming nodig heeft?

• “Ken je organisatie”; “waar zijn we kwetsbaar?”

• Wat zijn relevante dreigingen ?

• Welke risico lopen we ?

• Welke risico willen we lopen ? Risk appetite

• Welke maatregelen moeten worden genomen? security controls

4-3-2018 (CC) ES4CS.NL 43

Pilaar 1: Risicomanagement

Risicomanagement

• Breng situatie in kaart

• Identificeer technische risico’s voor de business

• Bepaal een risicomanagement strategie

• Bepaal de benodigde maatregelen

44

Risico’s ontstaan t.g.v. bedreigingen op assets/ de kroonjuwelen. Kwetsbaarheden vereisen dat er maatregelen moeten worden genomen

• Kroonjuwelen: (assets) is ons land met infrastructuur en inwoners;

A. Bedreiging: is het water

B. Maatregelen: dijken en duinen

C. Kwetsbaarheid: kwaliteit van de dijken, waaronder de hoogte van de dijk, zwakke dijken t.g.v. slecht onderhoud; uitdroging

Begrippen

• Risicoassessment • Welke risico’s lopen we?• Risicoanalyse is nodig om dit te kunnen bepalen: bepaling van:• De impact van relevante bedreigingen schade• De kans van optreden van deze bedreigingen kwetsbaarheid

• Risico = Kans x Impact • Een risico is een schadeverwachting in een bepaalde periode

• Risico’s managen!• Welke risico’s …. moeten we afdekken .. willen we accepteren …• Risicostrategie bepalen!

• Hoe risico’s effectief en efficiënt te managen

• Modellen en standaarden kunnen helpen

Risico’s beoordelen + managen

.46

Risico assessments in praktijk

• Startpunt • Context en scope bepalen (organisatie, proces, systeem)• Waardebepaling; betrouwbaarheidseisen, kosten

• Business impact bepalen (BIA)• Relevante processen/systemen selecteren en analyseren• “Wat als”- vraag stellen, en impact/schade inschatten (Hoog-Midden-Laag)• IMPACT wordt uitgedrukt in; GELD, REPUTATIE, MENSENLEVENS

• Relevante bedreigingen en kwetsbaarheden bepalen (T&VA)• Afhankelijk van business context, locatie, maatschappelijk positie e.a.• Organisatie is “in control”; maatregelen op orde, IT-beheer op orde• Welke threats zijn werkelijk aan de orde; incidenten zijn een indicator• KANS bepalen op basis van threats, kwetsbaarheden en aanwezige controls

• Risicobepaling KANS * IMPACT• Risico = H * H = zeer groot • Risico = L * M = gering

RISK ASSESSMENT

RISK ANALYSIS

CONTEXT ESTABLISHMENT

RISK IDENTIFICATION

RISK ESTIMATION

RISK EVALUATION

RISK TREATMENT

RISK DECISION POINT 1Assessment satisfactory

RISK DECISION POINT 2Treatment satisfactory

RISK ACCEPTANCE

RIS

K C

OM

MU

NIC

AT

ION

RIS

K M

ON

ITO

RIN

G A

ND

RE

VIE

W

No

No

Yes

Yes

RIS

K C

OM

MU

NIC

AT

ION

RIS

K M

ON

ITO

RIN

G A

ND

RE

VIE

W

Risico management vlg.ISO27005 (standaard)

Risico management benadering1. Begrijp de business

• in welke context wordt de software gebruikt

2. Onderken de business en technische (IT) risico’s• Voer een risico assessment uit• Maak gebruik van methoden en/of frameworks bijv.

• ISO27005 serie (ISO27001/27002/27005)

• IRAM van ISF • Cybersecurity Framework van NIST

• (volgende slides)

3. Bepaal risico’s! • Risk = kans * impact (voor de business)

• rankings: LOW-MEDIUM-HIGH

4. Bepaal de “risk appetite”

5. Bepaal “risk mitigation strategy”

6. Implementeer dit in je ontwikkelmethode48

Risicobeheersing

Risico strategie

• Risico modificeren (mitigeren)• Maatregelen nemen ter; impactminimalisatie, afschrikking, eliminatie,

preventie, detectie, correctie, herstel

• Risico behouden• Geen noodzaak tot maatregelen, het risico is binnen de marge

• Risico ontwijken• Activiteit niet uitvoeren waardoor het risico niet optreedt

• Risico delen• Risico bij een andere partij neerleggen door bijv. outsourcing toe te passen

4-3-2018 (CC) ES4CS.NL 49

Threat modeling (microsoft)

• Meer specifiek gericht op software ontwikkeling

• Security doelstellingen, gebaseerd op:• Bescherming van identiteit;

• Financieel; kosten maatregelen en/of herstel

• Reputatie; belangrijk, maar lastig te kwantificeren

• Privacy (compliancy);

• Beschikbaarheid (garanties); vastgelegd in SLA

• Applicatie overzicht • Onderdelen – datastromen – trust zones

• Decompositie van applicatie• Identificeren van onderdelen van de applicatie waar

security een rol zou kunnen/moeten spelen

4-3-2018 (CC) ES4CS.NL 50

https://www.owasp.org/index.php/Threat_Risk_Modeling

Threat modelling

• STRIDE classificatie • S = Spoofing identity (vervalsen van identiteit)

• T = Tampering data (manipulatie van data)

• R = Repudiation (onweerlegbaarheid in transacties

• I = Information disclosure (openbaarmaking van data)

• D = Denial of service (ondermijnen van services)

• E = Elevation of privilege (wijzigen van autorisaties)

• DREAD classificatie

• Risk_DREAD = (DAMAGE +

REPRODUCIBILITY + EXPLOITABILITY +

AFFECTED USERS + DISCOVERABILITY) / 5

4-3-2018 (CC) ES4CS.NL 51

Intermezzo

Discussie

• Hoeveel tijd wordt er in het huidige onderwijs besteed aan ontwerp?• (non-) functionele specificaties, functioneel ontwerp, technische ontwerp

• (bijvoorbeeld) in verhouding met programmeren en testen?

• Is het wenselijk dat je binnen AO zoveel extra tijd moet gaan besteden aan de requirements fase? Dwalen we daarmee niet te veel af van waar het om gaat, nl. goede software produceren

4-3-2018 (CC) ES4CS.NL 52

5-3-2018 (CC) ES4CS.NL 53

https://www.nist.gov/cyberframework

Risico’s mitigeren NIST cybersecurity framework (overall beeld)

5. Secure software development Pilaar 2: SSD

55

7 Touchpoints

1. Code review2. Risico analyse3. Penetration testing4. Risico gebaseerd testen5. Abuse cases6. Security requirements7. Security operations

Risicomanagement• Breng situatie in kaart • Identificeer technische

risico’s voor de business• Bepaal een

risicomanagement strategie• Bepaal de benodigde

maatregelen

Fase 1: Requirements

• Requirements voor applicatie• Functionele eisen

• Functionaliteit van de applicatie

• Standard: ISO25010

• Niet functionele Eisen Security requirements (6)

• Security requirements kunnen worden afgeleid uit• Risicoanalyse / risicomanagement (WAT JE WIL)

• Compliancy eisen (WAT JE MOET)

57

Compliancy en software ontwikkeling

Voor software ontwikkeling betekent dit:

• Regels vertalen naar eisen waaraan de software moet voldoen

• Opnemen in requirements!• Functionele requirements

• Non-functionele requirements security requirements

• Requirements zijn een onderdeel van het functioneel ontwerp

• Security requirements zijn essentieel voor “veilige software”

• Security requirements nader uitwerken in technisch ontwerp

4-3-2018 (CC) ES4CS.NL 58

Je moet compliancy

• Doel: regels (wetgeving) opstellen die afdwingen dat er maatregelengenomen gaan worden

• Wetgeving; indien het een landelijke (Europese) kwestie is• Geldt voor alle bedrijven en burgers

• Regelgeving; indien het een branche, bepaalde sector een kwestie is• Overheidsorganisaties en grote ondernemingen stellen (gezamenlijk regels op)

• Geldt voor alle afdelingen en medewerkers

• Meestal erg globaal en abstract, lastig te begrijpen en niet direct toepasbaar • Regels vertalen naar concrete security maatregelen

4-3-2018 (CC) ES4CS.NL 59

Hoe dwing je maatregelen af?

Voorbeeld: Privacy wetgeving (je moet)

• beveiliging van persoonsgegevens (zoals bedoeld in artikel 13 van de Wet bescherming persoonsgegevens)

• NU: Wetgeving datalekken:• Sinds 1 januari 2016 geldt de meldplicht datalekken. • organisaties moeten direct een melding (< 72u) moeten doen bij de Autoriteit

Persoonsgegevens zodra zij een ernstig datalek hebben. • een kwijtgeraakte USB-stick met persoonsgegevens, • een gestolen laptop of • een inbraak in een databestand door een hacker

• Europese privacy verordening (GDPR)• De wetteksten van de Verordening en de Richtlijn zijn op 4 mei 2016 in het

Publicatieblad van de Europese Unie gepubliceerd.• Vanaf 25 mei 2018 is de Verordening van toepassing.• Op 6 mei 2018 moeten de EU-lidstaten de Richtlijn hebben omgezet in nationale

wetgeving

Privacy by default

• Technische en organisatorische maatregelen nemen om ervoor te zorgen dat u, als standaard, alléén persoonsgegevens verwerkt die noodzakelijk zijn voor het specifieke doel dat u wilt bereiken. Bijvoorbeeld door:• een app die u aanbiedt niet de locatie van gebruikers te laten registeren als

dat niet nodig is;

• op uw website het vakje ‘Ja, ik wil aanbiedingen ontvangen’ niet vooraf aan te vinken;

• als iemand zich op uw nieuwsbrief wil abonneren niet meer gegevens te vragen dan nodig is.

4-3-2018 (CC) ES4CS.NL 61

Privacy by design

• Dit houdt in dat al bij het ontwerpen van producten en diensten (in de vorm van een applicatie) ervoor wordt gezorgd dat persoonsgegevens goed worden beschermd

• Lastig, want: wat is een goede bescherming?

• Dat komt neer op: • analyseren wat de risico’s zijn impact analyse risicoanalyse

• op basis daarvan (security) maatregelen vooraf inbouwen

• in termen van softwareontwikkeling is dat: • Security requirements opstellen

• Security maatregelen implementeren

• Veilig code produceren

4-3-2018 (CC) ES4CS.NL 62

7 touchpoints of software security

Fase 1: use cases + abuse cases

• Requirements of the application

• Use case modelling• De use case van de gebruiker functionaliteit

• De use cases of the hacker Abuse or misuse cases

• Abuse cases• Een manier van threat modelling

• Denken vanuit het hacker

• Hoe kan ik het system misbruiken?

• Creatief process (out-of-the-box denken)

64

Voorbeeld: Abuse case

Fase 2: Architecture and design

• Basis is de uitkomst van de risico analyse• security risico’s zijn bepaald

• ..en de juist mitigatie van de risico’s is bepaald

• Vervolg is het opstellen van een architectuur ontwerp• Doel: architecten, ontwerpers dienen eenzelfde beeld te hebben

op de security

• Maak gebruik van de juiste security principes (security principes)

• Eenduidige beschrijving van de architectuur eisen

Project start architecture

66

Structuur;architectuurlagen

• Gebruikers• Gedrag, cultuur

• Beheersing van de toegang• Access control

• Webapplicatie zelf• Vulnerabilities, patching

• Webserver (platform)• Configuratie, updates

• Operating system• Configuratie, hardening

• Netwerkdiensten (protocollen)

Security design principles1. Secure the weakest link

2. Defence in depth (layers of defence)

3. Fail securely (not like Bob in Windows 2000)

4. Grant least privilege (safe defaults)

5. Separate privileges

6. Economize mechanism (keep it simple)

7. Don’t share mechanisms (don’t share authorizations)

8. Be reluctant to trust (anticipate on attacks)

9. Assume your secrets are not safe (in your code)

10. Mediate completely (check, double check)

11. Make security usable (make it not to odious)

12. Promote privacy (it’s a good attitude)

13. Use your resources (make use of the help from your friends)

68

Fase 3: Test plannen• Risk based testing (4) gebaseerd op twee strategieën

• Testen van de security functionaliteit• Met standaard test methoden en technieken

• Op basis van de vulnerabilities en threats • Wat zijn de aanval patronen?

• SQL-injection/ XSS/ buffer overflows

• Wat zijn de resultaten van de abuse cases?

Security testing gaat over …

• making sure bad things don’t happen

QA testing gaat over …

• making sure good things happen

69

Fase 4: Secure coding

• Maak gebruik van de juiste programming techniques • Maak gebruik van standards en references

• Zoals OWASP, “24 deadly sins ..”, IEEE/ISO…

• Maak gebruik van code review (1)

• Maak gebruik van code review analysis tools• Helpen bij het testen (beoordelen) van je code in een vroeg

stadium

• Tools:

• Gerrit, Crucible, Review board, Fortify

• Opensource: LAPSE+ (Java), Orizon (Owasp)

70

Volgende week bij de Security Academy

Fase 5: Test en test resultaten

71

• Risicoanalyse uitkomsten

• Threats (aanvalsoppervlak)

• Bekende kwetsbaarheden (OWASP top 10)

• Risk appetite en maatregelen

• Is input voor…

• Penetration testing

• Tools (Kali) & Services (consultants)

• Verschillende omgevingen (OTAP)

• Volgende week aan de orde

Feedback uit het veld

• Security operations• Security Operation Centers -- SIEM tooling• Vulnerability management • Threat intelligence

• Externe analyse

• Feedback van gebruikers• Productieomgeving • Op verschillende platforms• Beta testers• Error reports van gebruikers• Bugs bounty program• Responsible disclosure policy

72

Feedback uit het veld

• Helpende hackers

• Hacken is strafbaar!

• Hackers zijn creatief• Zijn van waarde voor organisaties• Vinden zwakheden en melden deze

• Dilemma• Door te hacken worden zwakheden gevonden• Zwakheden melden bevordert de security• Maar is hacken is strafbaar!• Responsible disclosure policy biedt een oplossing

4-3-2018 (CC) ES4CS.NL 73

Pilaar 3: kennis en vaardigheden

74

7 Touchpoints

1. Code review2. Risico analyse3. Penetration testing4. Risico gebaseerd testen5. Abuse cases6. Security requirements7. Security operations

Risicomanagement

• Continue proces

• Identificeer technische risico’s voor de business

• Bepaal een risico-management strategie

Kennis

& vaardigheden• Architect

• Software engineer

• Tester

Kennis en vaardigheden

• Opdoen in het keuzedeel • Met name kennisaspecten

• Kennismaken met methoden, technieken en tools

• Kennis toepassen vaardigheden ontwikkelen• Tijdens stages (eisen stellen aan het stagebedrijf)

• Omgaan met vertrouwelijke informatie en integriteit

• Beeld ontwikkelen van de stand van zaken/ urgentie/ noodzaak

• Vaardigheden ontwikkelen testen en het gebruik van tooling

• Tijdens projecten/ andere kwalificaties uit het dossier• Het moet niet alleen beperkt blijven tot een keuzedeel, de meerwaarde uitbuiten

5-3-2018 (CC) ES4CS.NL 75

Intermezzo

Discussie

• Hoe sta je tegenover het aanmoedigen van je studenten om deel te gaan nemen aan meetups van hacking communities bijvoorbeeld:• Hackerone

• Hackers space on the internet

• Lokale hackers spaces

• https://hackerspaces.nl/

5-3-2018 (CC) ES4CS.NL 76

6. Security maatregelen en veilig programmeren

Voor veilig programmeren komt dat neer op:

1. “Access control” Logisch toegangsbeheer • Authenticatie wie ben je?

• Autorisatie wat mag je?

• Administratie wat heb je gedaan?

2. “Encryptie” versleutelen van informatie • Opslag: files, databases + passwords

• Transport (SSL/TLS)

3. “Juiste aanpak” gestructureerde werkwijze (architectuur)• Voorkomen van kwetsbaarheden in ontwerp en realisatie (code)

4-3-2018 (CC) ES4CS.NL 77

Triple A

Maar ook …

• Kennis en vaardigheden van programmeur

• Aanpak en werkwijzen die gehanteerd (moeten) worden (Scrum, e.a.)

• Gebruik van programmeertalen en programmeeromgeving • Gebruik van bibliotheken en externe modules /bundles

• Configuratie van de software: webserver, databaseserver etc.

• Onderhoud van applicatie/software/servers• Vulnerability management, patch management, threat intelligence

• Organisatie aspecten; cultuur, menselijke factor

4-3-2018 (CC) ES4CS.NL 78

Maatregelen volgens 27002• Belangrijk voor programmeur

zijn: • H9 access control

• H10 Cryptografie

4-3-2018 (CC) ES4CS.NL 79

Cryptografie

• Coderen volgens een algoritme (gebruikmakend van een sleutel)

• Decoderen bij hetzelfde gegeven algoritme met dezelfde sleutel

• De sleutel geeft a.h.w. toegang tot het origineel

• De key is key!

• De sleutel (opslag) is de zwakke plek van cryptografie

• Met cryptografie kan vertrouwelijkheid worden gerealiseerd

• Cryptoanalyse = het analyseren en/of het kraken van de code/sleutel

• Hoe groter de sleutel des te lastiger is de code te kraken

• Met cryptografie kan ook integriteit worden gerealiseerd

• Speciale vorm van cryptografie nl.: one way hashing 4-3-2018 (CC) ES4CS.NL 80

Symmetrisch cryptografie

• AES (Advanced Encryption Standard)

• Één sleutel voor encryptie en dezelfde sleutel voor decryptie (gedeeld geheim)

• Alice en Bob moeten allebei in het bezit zijn van de dezelfde sleutel

• Probleem: hoe breng je een geheime sleutel bij de andere partij?

5-3-2018 (CC) ES4CS.NL 81

AES

• Ontworpen door 2 Belgen; Rijmen en Daemen: gaven de naam Rijndael

• Winnaar van een door de NIST uitgeschreven competitie • Nadat de andere standaard DES en 3DES in 1999 was gekraakt

• Kenmerken zijn: • Symmetrisch algoritme (dus een gedeelde sleutel)• Verschillende sleutellengten mogelijk 128, 192 of 256 bits • Zowel in software als hardware te implementeren • Bevat drie elementaire bewerkingen die veel malen worden herhaald

• Indrukwekkend algoritme en realisatie daarvan:• https://www.youtube.com/watch?v=mlzxpkdXP58• flash simulatie software)

5-3-2018 (CC) ES4CS.NL 82

Asymmetrische encryptie

• Lost het probleem op van symmetrische encryptie (delen van sleutel)

• Werkt met 2 sleutels : een openbare public key en een geheime private key

5-3-2018 (CC) ES4CS.NL 83

RSA-systeem Ontwikkeld aan het MIT by Rivest, Shamir en Adleman (1978)

Hashing

• Een cryptografische algoritme

• Gebruikt geen sleutels

• Éénrichting encryptie

• Het resultaat is een binaire code met een vaste lengte

• Het wordt onmogelijke geacht om uit de hashwaarde het origineel te bepalen

5-3-2018 (CC) ES4CS.NL 84

• Verschillende algoritmes (functies) mogelijk• MD2, MD4, MD5 (128 bits Ron Rivest, MIT)• SHA-1, SHA-2 (160 bits, US standaard)

Toepassing bij passwords

5-3-2018 (CC) ES4CS.NL 85

Hybride systemen

5-3-2018 (CC) ES4CS.NL 86

Toepassing in communicatie

• SSL/TLS protocol• Symmetrische encryptie

• = sessie sleutel

• Asymmetrische encryptie • Uitwisseling sessie sleutel

• Certificaat uitwisseling • Garantie voor publieke sleutel

• Controle geldigheid

• Optie in verschillende algoritmes

5-3-2018 (CC) ES4CS.NL 87

Samenvattend

Cryptografie

• Symmetrische encryptie: AES encryptie

• één sleutel, sleutelengte bepaalt de sterkte van de encryptie

• Sleutelbeheer/opslag moet zorgvuldig gebeuren

• Asymmetrische encryptie: RSA algoritme

• Twee sleutels; publieke sleutel = openbaar ; privé sleutel = geheim

• Sleutelbeheer: publieke sleutel en privé sleutels vraagt beheer

• Hashing

• Geen sleutel; éénrichting encryptie; hashwaarde heeft een vaste lengte

5-3-2018 (CC) ES4CS.NL 88

Toegangsbeveiliging Access control • Toegang bieden tot een informatiesysteem

• Gebruiker moet zijn (digitale) identiteitaantonen • Bewijzen dat je de persoon bent die je zegt dat je

bent

• Het proces van toegang verlenen wordt authenticatie genoemd

• Gebruiker (subject) krijgt op basis van een autorisatie schema (policy) toegang tot het object (of niet)

4-3-2018 (CC) ES4CS.NL 89

Digitale identiteit

• Username /password of PIN

• Smartcard, token (SMS), RFID , USB Key

• Biometrisch (vinger, oog, stem, gezicht)

• Nieuwe methoden:

• 2 factor authenticatie (username/password + token)

• Federatieve identiteit: een andere partij zorgt voor identificatie (zegt wie je bent) bijv. Facebook, Google, Digid, IDaaS

• Beschikbare kenmerken toevoegen aan identiteit: IP-adres, GPS locatie, kenmerken van je systeem, toetsaanslag e.a.

4-3-2018 (CC) ES4CS.NL 90

▪ Wat je weet !

▪ Wat je hebt !

▪ Wie je bent !

Identificatie middelen

• Passwords

• Tokens

• Challenge response systems

• Smartcard

• USB-key

• Private key (PKI)

• Biometrie: • Fingerprint

• Iris scan

4-3-2018 (CC) ES4CS.NL 91

Autorisaties

• Toegangsrechten verlenen aan gebruiker

• Onderscheid tussen de verschillende gebruikers(rollen):• Bezoeker, leidinggevende, eigenaar, administrator

• Onderscheid maken tussen LEZEN, WIJZIGEN, DELETEN, AANMAKEN etc. van informatie/files/directories/ accounts etc.

• Verschillende methoden/systemen van toekennen van autorisaties

• Heeft te maken met hoeveelheid beheer werkzaamheden

• Dergelijke systemen kunnen vanuit de applicatie worden aangeroepen

4-3-2018 (CC) ES4CS.NL 92

Autorisatie/access matrix

• Objects versus subjects

• Velden bevatten de rechten, zoals • Lezen

• Schrijven

• Eigenaar

• …

Logging

• Wie heeft toegang gehad tot het systeem?

• Wat heeft de persoon gedaan?

• Opslaan in een logfile

• Om later te kunnen analyseren• Fraude zaken

• Systeem crashes

• Verkeerde transacties

• Kan in regelgeving vereist zijn• Compliancy

4-3-2018 (CC) ES4CS.NL 94

“Kunt mij laten zien wie er toegang heeft gehad tot het systeem?”

Pijnpunten in access control

Business

OwnerEindgebruikerIT Admin ontwikkelaar Security/ Compliance

Koppeling naarpartners en andereverkoopkanalen tekostbaar

Governance, beheersing en inzicht, compliancy, need for control

Te veel passwords

Wachttijd voordattoegang kanworden verleend

Password vergeten

Password wijzigen

Te vaak inloggen

Beheer van accounts ; verzoken voorwijzigingenenpassword resets

Gebruik van onveiligesynchronisatiescripts

Extra (redundant) code in elkeapplicatie

Inconsistenties

Onderhoud van code

Voldoen aangeavanceerdeopties (federatieveidentiteit)

Te veel spook accounts, “uit dienst getredenmedewerkers”

Bperktemogelijkheid tot het uitvoeren van audits

95

7. Implementatie keuzedelen

• Essentie is:• Veilig ontwerp maken kennis hebben van risico’s (bedreigingen +

kwetsbaarheden)• Veilige code kunnen produceren incl. reviews + gebruik tooling • Testen, waaronder penetration testing (ethical hacking)

• Kennisaspecten• Kennis van risico + security management• Principes (CIA), kwetsbaarheden, bedreigingen, risico’s, controls etc.

• Vaardigheidsaspecten • Vaardig in het toepassen van methoden, best practices, tooling, etc.

noodzakelijk voor het opleveren van een veilig product

4-3-2018 (CC) ES4CS.NL 96

Uitvoering keuzedeel

• Leermiddelen • Boek: Cyber security & veilig programmeren Gabriël Sanchez Cano

• Bronnen met bruikbaar onderwijsmateriaal • OWASP https://www.owasp.org/index.php/Main_Page

• Microsoft https://www.microsoft.com/en-us/sdl/default.aspx

• Centrum voor Informatie & privacy

• https://www.cip-overheid.nl/category/producten/secure-software/

• Commerciële aanbieders:• https://www.certifiedsecure.com/frontpage

• https://www.checkmarx.com/

• https://placestolearn.nl/product-category/keuzedeel-mbo/

4-3-2018 (CC) ES4CS.NL 97

Aanbevelingen aanpak inrichting keuzedeel

• Aandacht besteden aan cyber security essentials

• Aandacht besteden aan ethische aspect / juiste attitude• Omgaan met geheimhouding, integer gedrag (VOG, NDA, security policies)

• Start met ethical hacking /penetration testing (Kali Linux)• Creëer een virtual security lab, standaard omgeving vanuit de opleiding.• Als je weet hoe eenvoudig het systeem te hacken is, dan werkt dat

motiverend; ”Je wilt niet dat jouw software te hacken is”• Challenges van certified secure zijn uitdagend en leerzaam; goede aanvulling

• Ontwikkel kennis en vaardigheden voor het veilig coderen

• Integreer veilig programmeren in je andere onderwijseenheden stages, projectonderwijs, events (hackatons, CTF-games)

4-3-2018 (CC) ES4CS.NL 98

Test en werkomgeving

• Virtuele omgeving • Virtual box https://www.virtualbox.org/• VMware https://www.vmware.com/products/workstation-player/workstation-player-evaluation.html

• Pentesting tool: Kali Linux https://www.kali.org/

• Target: Vulnerable websites https://www.owasp.org/index.php/OWASP_Vulnerable_Web_Applications_Directory_Project• https://www.owasp.org/index.php/OWASP_Vulnerable_Web_Applications_Directory_Project/Pages/Offline

• Building a Virtual Lab to Practice Pen Testing (with virtualbox or VMware) • https://www.cybrary.it/0p3n/tutorial-for-setting-up-a-virtual-penetration-testing-lab-at-your-home/

• https://www.youtube.com/watch?v=5egBxI5Nnwo• https://kb.help.rapid7.com/docs/setting-up-a-penetration-testing-lab

4-3-2018 (CC) ES4CS.NL 99

SPL-Examen

• Opgedeeld in onderdelen; vragen en opdrachten over• Ontwerp + architectuur • Vragen over en opdrachten over coderen• Testplannen en pentration testing (gebruikmakend van SPL- virtula lab)

• Omvang: 5 uur

• Opdracht: Webapplicatie + App

• Gegeven: Casus • Casusbeschrijving + functioneel + technisch ontwerp + bijlagen

• Eerste ervaring: pittige examen!• evaluatie en validatie vind nog plaats

4-3-2018 (CC) ES4CS.NL 100

Pas op!

• Eindkwalificatie en examentermen zijn geformuleerd op eindniveau (4)• Aan het einde van de 3 jarige opleiding• Na 3 jaar, inclusief stage en opgedane praktische ervaring• Examen gaat uit van kennis én vaardigheden (ervaring)• Binnen een half jaar een student naar het examenniveau brengen is daardoor

heel lastig

• Van groot belang voor succes is• Plaats van het keuzedeel in de opleiding (2e of 3e jaar)• Plaats van het examen in de opleiding (2e of 3e jaar)

• Mijn advies naar SBB en SPL is geweest om kennis en vaardigheden separaat te toetsen (maar is nog niet gerealiseerd)

4-3-2018 (CC) ES4CS.NL 101

Takeaways

• Keuzedeel veilig programmeren gaat ook over risico- en security management

• Security requirements is en belangrijk onderdeel voor invulling van een “veilig programmeren”

• Naast het kunnen produceren van veilig code is ook elemenatirekennis noodzakelijk van security maatregelen zoals access control, cryptografie

• Security testen zoals pentesting en ethical hacking zijn eveneens een essentieel onderdeel in het programma en werken motiverend voor veilig programmeren

4-3-2018 (CC) ES4CS.NL 102

Takeaways

• Veilig programmeren vereist ook aandacht te schenken aan de ethische (en juridische) aspecten en bijbehorende werkwijzen (NDA)

• Er is veel open source en online materiaal beschikbaar ter ondersteuning van het keuzedeel veilig programmeren

• Besteed aandacht een gestandaardiseerde (adequate en veilige) inrichting in de vorm van een virtueel hacking en ontwikkellab

• Goede inrichting van het keuzedeel in het totale programma vanOA vereist aandacht. Ervaring opdoen in de praktijk bevordert goede examenresultaten

• Uiteindelijk zou veilig programmeren een integraal onderdeel van OA moeten zijn (worden)

5-3-2018 (CC) ES4CS.NL 103

Belangrijke bronnen • OWASP top 10 (https://www.owasp.org/index.php/Top_10_2013-Top_10)

• Fameus! 3 jaarlijks overzicht van meest voorkomende kwetsbaarheden in (web gebaseerde) software

• Indicatie over de fouten die gemaakt worden in de software • Maar ook hoe deze voorkomen kunnen worden • Tal van aanbevelingen en hulpmiddelen op OWASP.ORG• Opensource, gratis tools en kennisbronnen

• SANS top 25 (https://www.sans.org/top25-software-errors/ )

• Soortgelijk overzicht • Niet alleen web gebaseerde applicaties

• Worden beiden vaak als een norm gehanteerd

Leo van Koppen MSIT

info@ES4CS

4-3-2018 (CC) ES4CS.NL 105

Referenties / bronnen• https://cve.mitre.org/

• https://nvd.nist.gov/

• http://cwe.mitre.org/top25/

• https://www.owasp.org/index.php/Top_10_2013-Top_10

• https://www.sans.org/top25-software-errors/

• https://autoriteitpersoonsgegevens.nl/nl/melden/meldplicht-datalekken

• https://autoriteitpersoonsgegevens.nl/nl/over-privacy/wetten/europese-privacyrichtlijn

• http://nvlpubs.nist.gov/nistpubs/specialpublications/NIST.sp.800-162.pdf

• https://en.wikipedia.org/wiki/X.509

• Bronnen: grafieken uit:• Ponemon Institute: research 2012 Application Security Gap Study: A Survey of IT Security &

Developers

• Cybersecurity trend report 2016: (HPE)

Sources & reading • http://www.cigital.com/~gem/books/

• http://en.wikipedia.org/wiki/Software_development_process

• https://buildsecurityin.us-cert.gov/articles/best-practices/risk-management/risk-management-framework-(rmf)

• http://getbarkeep.org/

• https://www.owasp.org/index.php/Source_Code_Analysis_Tools

• http://en.wikipedia.org/wiki/Exploit_(computer_security)

• http://www.exploit-db.com/

• https://www.securesoftwarefoundation.org/

• http://www.cip-overheid.nl/downloads/grip-op-ssd/

• http://www.microsoft.com/security/sdl/default.aspx

• http://www.bsimm.com/

• http://www.opensamm.org

• http://www.google.com/about/appsecurity/reward-program/

• https://www.owasp.org/index.php/Category:OWASP_CLASP_Project

• http://www.safecode.org/107