Veilige software ontwikkelen; hoe gaat Ambrero hiermee om?

De IT-sector is continu in beweging, waarbij goede softwarebeveiliging kennis voor ontwikkelaars cruciaal is een vereiste in ons werk. Bij Ambrero ontwikkelen we dan ook toekomstgerichte en veilige software die voldoen aan de laatste standaarden. Het beschermen van persoonsgegevens en data is een vast onderdeel tijdens onze softwarecyclus.

Dit is van essentieel belang, zeker omdat er een hernieuwde aandacht is voor online veiligheid bij veel organisaties door de Algemene Verordening Gegevensbescherming (AVG). De gevolgen kunnen namelijk groot zijn wanneer je hier als organisatie niet aan voldoet. Hoe gaat Ambrero om met het veilig ontwikkelen van software en waarom is dit zo belangrijk?

Hack leidt tot schade

De belangrijkste reden om veilige software te ontwikkelen is het risico op schade. Denk aan financiële schade als gevolg van een hack. Waardoor je website of applicatie onbereikbaar is en je als organisatie direct omzet misloopt. Daarbovenop zorgt de nieuwe privacywetgeving ervoor dat je bij nalatigheid rondom je beveiliging een boete riskeert. En die kan al snel oplopen tot 20 miljoen euro.

Naast financiële schade leidt een hack ook tot de nodige imagoschade. Vertrouwen komt te voet en gaat te paard, waardoor een hack grote gevolgen kan hebben voor je organisatie op langere termijn.

Veiligheid in ons DNA

Binnen Ambrero zit veilige software ontwikkelen in onze DNA. In eerste instantie zijn software developers vooral bezig om de wensen van klanten te realiseren. Bij ons zorgen we ook voor een veilig en betrouwbaar eindresultaat.

Dit doen we door ervoor te zorgen dat iedereen bij Ambrero over voldoende kennis beschikt. Medewerkers worden opgeleid om veilige software te ontwikkelen. Hiervoor houden we minimaal één keer per jaar een presentatie over de nieuwste ontwikkelingen op dit gebied. Zodat iedereen goed op de hoogte blijft, met de juiste mindset.

Aanpak om veiligheidsproblemen te voorkomen

Ambrero borgt de veiligheid van een website of applicatie met een aantal maatregelen. Eén daarvan is dat we gespecialiseerd zijn op drie technologie-oplossingen, namelijk: Java stack, .NET stack, Ambrero Base framework. Hierover hebben we diepgaande kennis opgebouwd. We weten hoe met deze oplossingen veilige applicaties worden gebouwd.

Daarnaast gebruiken we een aantal praktische tools. We werken volgens het vier ogen principe, de code die een ontwikkelaar schrijft wordt altijd gecheckt door een collega. En we voeren bijvoorbeeld een codeanalyse uit om beveiligingslekken op te sporen of controleren componenten op bekende beveiligingsproblemen. Deze controles voeren we uit aan de hand van de lijst van meest voorkomende beveiligingsrisico’s.

De top 10 beveiligingsrisico’s voor software

Het Open Web Application Security Project (OWASP) is een non-profit organisatie die zich volledig heeft toegelegd op het verbeteren van softwareveiligheid. Eens in de 3-4 jaar stellen zij een lijst van de meest voorkomende beveiligingsrisico’s op.

Hieronder staat de top-10 (uit 2017) met een aantal maatregelen die we kunnen treffen voor ieder beveiligingsrisico. Het is geen standaard werkwijze, onze aanpak is afhankelijk van de klantvraag en het product.

1. Injection
   

   Al jaren is het injecteren van onveilige code door buitenstaanders een van de meest voorkomende beveiligingsrisico’s voor websites en applicaties. Eén van de maatregelen die we nemen is het opstellen van een veilige lijst voor invoervalidatie.

2. Broken Authentication
   

   In dit geval zijn de gebruikersgegevens niet beschermd wanneer deze worden opgeslagen. Denk aan wachtwoorden of gebruikerssessies die verzonden worden over een onbeveiligde verbinding die hackers daardoor kunnen onderscheppen.

   Daarom implementeren we multi-factor authenticaties. Sommige klanten willen daarbij met hun bedrijfswachtwoord kunnen inloggen op de applicatie. Om dit te realiseren maken we een koppeling met een authenticatiesysteem en zorgen we ervoor dat deze omgeving veilig is.

3. Sensitive Data Exposure
   

   Diverse webapplicaties en API’s beschermen gevoelige informatie onvoldoende zoals financiële of persoonlijke gegevens. Daarom identificeren we eerst welke data gevoelig is, waar deze wordt opgeslagen en indien nodig wordt deze vervolgens versleuteld. Gevoelige data slaan we niet op als dat niet nodig is. En autocomplete velden in formulieren die gevoelige informatie verzamelen schakelen we uit.

   Verder zorgen we ervoor dat wachtwoorden worden opgeslagen met een algoritme dat specifiek is ontworpen voor wachtwoordbescherming. Denk aan bcrypt, PBKDF2 en scrypt.

4. XML External Entities (XXE)
   

   Sommige XML processors zijn verouderd of slecht geconfigureerd, waardoor hackers deze kunnen aanvallen door een XML bestand te uploaden die is voorzien van kwetsbare code. Daarom voeren we regelmatig controles uit om te zien of deze oplossingen nog up-to-date zijn en implementeren waar nodig updates.

5. Broken Access Control
   

   Vaak zijn de gebruikersrechten niet op de juiste manier ingesteld. Hackers kunnen hiervan profiteren en functionaliteiten of data benaderen. Op deze manier kunnen zij bijvoorbeeld gebruikersrechten wijzigen, waardoor je zelf geen toegang meer hebt tot de applicatie. Mede daarom implementeren we in de meeste gevallen bepaalde controlemechanismes.

6. Security Misconfiguration
   

   Het kan voor komen dat een web- of applicatieserver gedateerd is. Daarom voeren we periodiek scans en audits uit om na te gaan of er onnodige toepassingen zijn geactiveerd of geïnstalleerd die de veiligheid in gevaar brengen. Daarnaast lopen we na of de beveiligingsinstellingen van frameworks ingesteld staan op de juiste waarden.

7. Cross-Site Scripting (XSS)
   

   XSS zwakheden ontstaan wanneer een applicatie gebruikersdata naar een browser verzendt zonder dat deze content goed is gevalideerd. Om dit te voorkomen zorgen we voor een invoervalidatie en werken we op basis van Content Security Policy. Dit biedt de mogelijkheid om bij een browser aan te geven vanaf welke locatie en/of welke bronnen er content mag worden opgehaald.

8. Insecure Deserialization
   

   Bij dit veiligheidsprobleem kunnen aanvallers op afstand de applicatie aanpassen. Een van de voor de hand liggende oplossingen is om geen toegang te verlenen aan niet gevalideerde bronnen. Als dat niet mogelijk is implementeren we integriteitscontroles.

9. Using Components with Known Vulnerabilities
   

   Vaak worden er bij de bouw van applicaties open source componenten gebruikt die in eerste instantie veilig zijn, maar later toch onveilig blijken. Klanten kunnen dit zelf in de gaten houden of uitbesteden aan een softwarebedrijf. Bij Ambrero bieden we deze service via een Service Level Agreement (SLA). Eén van de onderdelen is een periodieke controle op mogelijke kwetsbaarheden van componenten en een check of hiervoor nieuwe releases zijn uitgebracht.

10. Insufficient Logging & Monitoring
    

    Hierbij wordt onvoldoende bijgehouden of er sprake is geweest van ongeautoriseerde handelingen. Dit biedt hackers de mogelijkheid om over een langere periode aanvallen uit te voeren op systemen en data aan te passen, te kopiëren of te verwijderen. Hierbij is het zaak om fouten bij onder meer login pogingen en validatie te registeren. Op deze manier worden verdachte accounts geïdentificeerd. Insufficient Logging & Monitoring wordt door Ambrero alleen meegenomen als dit past binnen het beschikbare budget.

Zet veilige software hoog op de agenda

Hierbij de belangrijkste redenen om te zorgen voor veilige software op een rij:

• Beschermen van persoonsgegevens
• Voorkomen van cybercriminaliteit
• Vermijden van inkomstenderving
• Voorkomen van imagoschade

Daarom is het van groot belang om samen te werken met een softwarebedrijf met up-to-date kennis van veiligheid. Om dit te checken kun je specifiek vragen naar de werkwijze waarmee ze de veiligheidsstandaarden van software borgen. En wees je bewust van de aandachtspunten bij het ontwikkelen van veilige software! Zoals hier beschreven als de top 10 van beveiligingsrisico’s.