Het bouwen van veilige mobiele applicaties in agile teams Wat is er nodig om niet de krantenkoppen te halen?
Myth busters Mobile apps zijn wegwerpoplossingen Agile betekent cowboys Scrum betekent onveilig One size fits all MDM is de oplossing voor al je problemen MAM is de oplossing voor al je problemen
Agile Agile op zich helpt niet om secure apps te bouwen Kan juist een bedreiging vormen door sterke focus op features Dus: kaders vooraf stellen is belangrijk
Segmentering Dagelijks • Dagelijks gebruik • Data die je wilt bewaren • Apps gooi je niet weg • Bijv. Banking, Mail, Notities, Twitter
value
risk
Periodiek • Specifiek voor bepaalde evenementen • Tijdelijk karakter maar in die periode wel voor jou van waarde
value
risk
Wegwerp • Marketing • Momenteel 90% van de apps in de App Stores • Malware (vaak Android)
value
risk
Heeft een Scrum aanpak effect op de beveiliging van applicaties? • SCRUM zegt niets over de uiteindelijke software die je maakt. Het zegt alleen dat: • We niet meer denken in een sequentie van stappen waarbij er bij iedere stap een overhandiging is naar een andere discipline • We kiezen er voor met het hele team aan het zelfde doel te werken en gedurende deze “sprint” helpen we elkaar vanuit de verschillende disciplines
• Hierbij zijn er ook agile practices ontwikkeld die onlosmakelijk met scrum worden geaccocieerd, maar niet des scrums zijn • Test driven development, automated builds, geautomatiseerde regressive testing, continuous deployment, learning feedback loop, etc.
• Scrum != doe maar raak voor een knaak • Vereis veel discipline van een team en er zijn veel practices die worden doorgevoerd om de snelheid er in te houden
Scrum Scrum Master rollen Is de team coach Helpt team tijdens de daily standup Lost impedements op Advocaat van werkwijze team Helpt PO bij het prioriteren Helpt de projectleider in het managen van stakeholders, etc
Product Owner Team Members Het team van mensen die de klus moeten klaren, meestal zijn hierin de rollen Analyst, Ontwikkelaar, Tester minimaal vertegenwoordigd
De persoon die bepaalt wat er in het product moet komen en conform welke specificities Wordt vaak geholpen door team leden om zaken uit te zoeken, te specificeren en te documenteren in de sprint
Security Expert
Security Aware!
Scrum en beveiliging? Product Owner moet op de hoogte zijn van benodigde beveiliging voor zijn product Definition of Done bepaalt wat er opgeleverd wordt – Maak beveiliging onderdeel van DoD
Prioritering! Er is een risico dat er features boven beveiliging worden gesteld Help PO door toevoegen security expert aan het team
Risico analyse & BIV Om beveiliging voldoende op de agenda te krijgen is het van belang dat het risico wordt ingezien – Maak dus een gedegen risico analyse
Veel bedrijven onderkennen al een zogenaamde BIV classificatie (Beschikbaarheid , Integriteit, Beveiliging) – Ook bekend als AIC, CIA (engelse afkorting Confidentiality, Integrity & Availabillity)
Classificatie BIV • Een dergelijke rating wordt gedaan op ieder aspect en gescoord op een schaal van 1-3
• Dus bijv een app die 1-1-2 scoort heft dus een relatief lage beschikbaarheid, een lage integriteit en medium beveiligings aspect • Deze kan je vertalen naar technische maatregelen
• Het hebben van een dergelijke vertaling maakt het controleren op de genomen maatregelen erg eenvoudig voor de auditor • Indien men een bepaalde eis niet kan implementeren kan het project een waiver aanvragen • Dit wordt dan gedaan o.b.v. een risico analyse en het vaststellen wat het residual risk is als het niet volledig wordt gemitigeerd • Ook dit kan de auditor dan meemenem in zijn eindoordeel • Spanningsveld tussen B (kan vereiste zijn voor marketing) en V
BIV Voorbeeld • Integriteit • 1 laag
• Geen maatregelen, standard HTTP/REST/ SOAP is voldoende • Data mag publiek worden gezien • Data mag op device worden opgeslagen clear text
• 2 midden
• Beveiligde communicatie verbinding anonym • Social network authenticatie is voldoende, wel identitiet maar niet gebruikt voor beveiliging, alleen uniciteit • Data op device encrypted, niet aanpasbaar buiten de app om
• 3 hoog • • • • •
Non repudiation Signing van messages Traceerbaarheid wie heeft wat gedaan Client authenticatie (bijv certificates 2 way SSL) Data op device ongewenst indien noodzakelijk minimaal niveau 2
Wanneer 1, 2 of 3 • Risico op: • Information disclosure, klant data, transactie data,
• Impact • Haal je de krant, Financieel, juridisch, bestaansrecht van je bedrijf
• Wat is het gewin bij breken van security • Kans dat men het gaat proberen (hacker incentive)
Security risico’s (STRIDE) Spoofing Tampering Repudiation Information disclosure Denial of service Elevation of privilege
Threat model Define the application requirements: – – – –
Identify business objectives Identify user roles that will interact with the application Identify the data the application will manipulate Identify the use cases for operating on that data that the application will facilitate
Model the application architecture – – – –
Model the components of the application Model the service roles that the components will act under Model any external dependencies Model the calls from roles, to components and eventually to the data store for each use case as identified above
Identify any threats to the confidentiality, availability and integrity of the data and the application based on the data access control matrix that your application should be enforcing
What’s the app’s target audience? B2B
B2E
B2C
Mobile Application/Device Mgmt
?
Wrapper
Mobile Vormen van beveiliging – – –
Data at rest Data in transit ...
Spanningsveld tussen usability en beveiliging "out of box" security features –
Niet zomaar op vertrouwen, goed kijken wat de gebruiker daarmee doet
Beveiliging van platforms –
Android Wild Wild West is minder betrouwbaar dan Windows / iOS die via strakke policies worden gepubliceerd (malware)
Veel gemaakte fouten (checklist) (teveel open deur??) – – – – – –
https = veilig? Sleutel onder de deurmat Zelfgebouwde crypto (geen standaard protocollen) Security by obscurity BIV niet goed vertalen naar maatregelen Back end niet veilig (vergeten dat dit ook onderdeel van de app is)
Wat maakt mobile anders dan de PC? Variatie aan devices en operating systemen
Wat maakt mobile anders dan de PC? Local cache nodig door beperkte connectivity
Wat maakt mobile anders dan de PC? Altijd bij je, gemakkelijk te verliezen
Wat maakt mobile anders dan de PC? Security versus gebruikersgemak (drempels)
Beveiligen van mobile apps Toegangsbeveiliging tot de app / data Wat te doen bij verlies of diefstal Wat is het risico – Ongeautoriseerd uitvoeren van functies? – Ongeautoriseerd gebruiken van de data op het device?
Wat wordt vaak vergeten? – De app is maar 20%, de rest is de server kant! – Een gangbare app heeft een server side API nodig om goed te functioneren • Batterij levensduur, kracht van de processor, beperkte bandbreedte, etc
– Zijn de API’s goed beveiligd tegen oneigenlijk gebruik?
Platform UI Data
Serialization Caching
Application Business Logic
Security
AuthN/AuthZ Encryption Data Self Destruction
Utilities
Analytics Logging
Device services
Multi platform strategy: tackle security at once
Privacy What user information does the marketing app gather? How safely is that data stored? How are users identified/distinguished? Write only
API
API 2
Privacy: logging and tracing Logging and tracing in an app can expose sensitive data to developer tools Same goes for usage stats (e.g. Google Analytics)
Data beveiliging Data at rest – Opslaan in data vaults • Bijv. Password in OS specifieke keychain • Encryptie van data (maar waar laat je de sleutel?)
Data in transit – Standaard http – Protocol beveiliging (SSL) • One or two way authentication (client certificates)
Toegangsbeveiliging Pincode – Veel gebruikt, kent nodige risico’s – Bijv. Het touch scherm laat na verloop van tijd zien welke combinatie is gebruikt…. – Zwakke authenticatie (4 a 5 nummers) eenvoudig brute force mogelijk • Bouw dus backoff in (na x pogingen langere wachttijd en doe dat progressief)
Passwords – Ook veel toegepast, ook bekende problemen – i.v.m. continu onthouden van tientallen wachtwoorden wordt de klant lui – Beter: gebruik federation (Google ID, Facebook ID, Microsoft ID, etc)
Biometrie (gezichtsherkenning, vingerafdruk, etc.) – Nog weinig toegepast – Veiligheid vs. gemak
Development platforms HTML5 based apps security concerns – HTML based apps (e.g. PhoneGap) are subject to same security risks as web sites (https://www.owasp.org/index.php/HTML5_Security_Cheat_Sheet)
– Cross Site Scripting attacks – JavaScript injection – Cross domain requests
Code at rest: PhoneGap can download and never store sensitive JavaScript code, thereby protecting IP
Development platforms Most cross platform development tools rely on underlying OS features for secure storage and data encryption
Common mistakes Easy Audit Points SSL will solve my security needs – Wrong: – It only provides a security solution to Data in transit and protects the communication channel from evesdropping and modifications of the message • Tampering, repudiation, information disclosure
It does not protect your data at rest It does not protect you from people starting your app unauthorized …
Common mistakes (data at rest) Encryption of the data on the local device Only solves the issue when someone wants to access the data unauthorized, since it is now encrypted But where is the key? – How to obtain the key in your app? – From the server? • Ok, but how do I set up initial communication to retrieve the key?
– Key built into the app • Easy to discover with disassembler tools! It’s the most random string in the image
Common mistakes Forgotten cross site request forgery – Allow others to download images, or artifacts from your API/Website so others can create a fake version of your app to disclose information
One more thing… Public wifi (zonder sleutel) vulnerability TODO: uitzoeken Marcel
