Hallo, iedereen.
Vandaag gaan we het niet hebben over hacken en inbreken in systemen, zoals we gewoonlijk doen,
maar over beveiliging en specifiek over hoe we websites, webtoepassingen, mobiele toepassingen enzovoort kunnen beveiligen.
Het is duidelijk dat hacks en inbreuken een enorme negatieve impact hebben op bedrijven, van het verlies van vertrouwen van klanten
tot financiële verliezen.
Gelekte gebruikersgegevens, juridische kwesties en de lijst gaat maar door.
Als je nu op Google gaat zoeken naar hoe je je website of applicatie kunt beveiligen, krijg
je een hoop onzin te zien.
Ik was eigenlijk zo teleurgesteld in de clickbait artikelen die eigenlijk geen uitleg of nuttige informatie
gaven.
De meesten stelden voor om back-ups te gebruiken, sterke wachtwoorden in te stellen en HTTPS te gebruiken.
Maar back-ups beveiligen uw website niet, ze helpen u alleen om te herstellen.
Ook het gebruik van ETP's versleutelt de communicatie, maar beveiligt de website niet echt.
De enige nuttige tip was het gebruik van sterke wachtwoorden.
Maar de meeste hackers gaan niet zitten en proberen het wachtwoord te raden zoals je in Hollywood-films ziet.
Zij zullen vertrouwen op kwetsbaarheden en zwakheden in uw toepassing, en zij zullen die uitbuiten
om toegang te krijgen, ongeacht het wachtwoord dat u gebruikt.
Zelfs als je een zeer, zeer complex wachtwoord hebt, zelfs als je HTTPS gebruikt en zelfs als je back-ups hebt, is veel hiervan
eigenlijk irrelevant.
Ook maakt het niet echt uit waar je de applicatie laat hosten, of je een A gebruikt. W. of een andere cloud provider,
en het maakt niet uit hoe je deze applicatie inzet.
Als je Kubernetes gebruikt of als je Docker gebruikt, maakt het niet echt uit.
Het is eigenlijk heel, heel eenvoudig.
Als u een kwetsbare webapplicatie hebt, zullen hackers deze kwetsbaarheden of zwakheden gebruiken om
toegang te krijgen tot deze applicatie.
Genoeg gekletst.
Laten we het hebben over hoe we websites en toepassingen daadwerkelijk kunnen beveiligen.
Allereerst, voordat we erover beginnen, is het heel belangrijk te begrijpen dat het bereiken
van 100 procent veiligheid onmogelijk is.
Wij proberen alleen de veiligheid van onze toepassingen te verbeteren en ervoor te zorgen dat zij zo veilig
mogelijk zijn.
Dit gezegd zijnde, zullen de volgende vier benaderingen u helpen de beveiliging van uw toepassingen te verbeteren,
ongeacht het soort toepassingen en ongeacht waar ze zijn geïnstalleerd.
Zoals ik al zei, het maakt niet uit of je ze installeert op Amazon of ergens anders op een WIC of iets
anders, en het maakt niet uit hoe je het inzet als je Docker en zo gebruikt.
Dus het eerste wat je moet doen is ervoor zorgen dat je op deze manier veilige code schrijft.
Uw toepassing wordt vanaf de grond opgebouwd om veilig te zijn en geen bugs of kwetsbaarheden te introduceren die door hackers
kunnen worden uitgebuit om toegang te krijgen.
Nu zou dit geweldig zijn als je het kunt, maar het probleem is dat het gemakkelijker gezegd is dan gedaan, omdat de ontwikkelaars
moeten worden opgeleid en onderwezen in de methoden die hackers gebruiken om systemen te misbruiken en toegang te krijgen.
En zelfs als u dat doet, vertrouwen ontwikkelaars vaak op bibliotheken van derden en kan de hele toepassing door iemand
anders zijn geschreven.
Daarom kunt u eenvoudigweg geen veilige code schrijven, omdat u eigenlijk niet de schrijver of de ontwikkelaar van
deze toepassing bent.
Dat brengt me bij het tweede punt.
Herziening van de code.
Dit is eigenlijk heel goed, zelfs als je de applicatie zelf hebt geschreven, en zelfs als je ervoor hebt gezorgd
dat je veilige code schrijft, is het een heel goed idee om die code te laten nakijken door andere ontwikkelaars of een
ander team.
Voor het geval dat de ontwikkelaars die de aanvraag hebben geschreven iets over het hoofd hebben gezien of over het hoofd hebben gezien, dan
zal dat bij de herziening worden opgemerkt.
Ook als u de code gebruikt die is geschreven door andere ontwikkelaars of bibliotheken van derden, zal een
code review dit probleem oplossen, omdat u alles kunt nakijken.
En nogmaals, dit is echt, echt goed omdat je eigenlijk elke regel bekijkt en ervoor zorgt
dat niets kwetsbaar is of hackers in staat stelt je applicatie te misbruiken en toegang te krijgen.
Het grootste nadeel hiervan is dat als je een grote codebasis hebt, dit erg tijdrovend
en ook erg duur kan zijn.
De derde benadering, die naar mijn mening zeer essentieel is, is het laten uitvoeren van een pentest.
In een pentest.
Je huurt eigenlijk een team van ethische hackers in om te proberen je applicatie te hacken.
Deze ethische hackers zullen uw applicatie op dezelfde manier benaderen als Black Hat hackers.
Ze gaan proberen zoveel mogelijk informatie te verzamelen en alle zwakke plekken en kwetsbaarheden te ontdekken en kijken
of ze die kunnen uitbuiten om toegang te krijgen.
Aan het eind, als ze klaar zijn, geven ze u een gedetailleerd rapport van alles wat ze hebben gevonden, zodat
u het kunt doorgeven aan uw ontwikkelaars en eventuele kwetsbaarheden die ze ontdekken kunt verhelpen.
Het grote voordeel van deze methode is dat u aanvalsoppervlakken kunt testen die u met andere methoden niet
kunt testen, zoals uw servers waarop uw webapplicatie draait en de zwakste schakel, namelijk de medewerkers.
Dus deze hackers, de ethische hackers, kunnen zelfs social engineering gebruiken en het koppelen aan andere eenvoudigere aanvallen
of eenvoudigere kwetsbaarheden die ze op uw systeem kunnen vinden om te zien of ze die kunnen gebruiken om toegang te krijgen.
De nadelen hiervan zijn dat het een beetje duur kan zijn en dat het niet toekomstbestendig is.
Wat ik bedoel is dat als u uw applicatie vandaag laat testen door een echt goede ethische hacker en er vervolgens
voor zorgt dat u elke kwetsbaarheid die zij vinden patch, dit alleen betekent dat uw webapplicatie vandaag veilig
is.
Het garandeert niet dat het veilig blijft voor de volgende maand of het volgende jaar, omdat elke verandering
die u maakt, elke functie die u pusht, of elke bug die u oplost, andere bugs of zwakke plekken in de beveiliging kan
introduceren die vervolgens kunnen worden gebruikt om in te breken in uw applicatie.
Niet alleen dat, maar ook als u weer software van derden of plugins bijwerkt, kan dat allemaal kwetsbaarheden
introduceren, en een test zal dat niet kunnen opvangen omdat u de Panthers alleen vandaag doet, en deze toekomstige
veranderingen niet getest zullen worden.
De vierde benadering, die dit probleem daadwerkelijk kan aanpakken, is een bug bounty-programma.
Een bug bounty-programma is in feite een uitnodiging aan alle ethische hackers over de hele wereld om uw toepassing
te testen en hun bevindingen in te dienen.
En u zou alleen betalen voor geldige bugs of geldige rapporten.
Het belangrijkste voordeel is hier, zoals je waarschijnlijk al geraden hebt, dat je je applicatie
laat testen door een groot aantal hackers, dus de kans dat ze kwetsbaarheden vinden is groter.
En het is eigenlijk toekomstbestendig, want zolang je die bug bounty lijst live hebt, zullen deze hackers altijd
je applicatie blijven testen en je motiveert ze met bounties.
Dus dit kan van alles zijn, van een T-shirt tot een geldprijs.
Om er zeker van te zijn dat ze daadwerkelijk doorgaan met het testen van je applicatie.
Dus zelfs als u nieuwe wijzigingen of nieuwe functies aanbrengt of dingen bijwerkt, maakt het niet veel
uit omdat hackers uw toepassing zullen blijven testen in de hoop bugs te vinden en bounty's te krijgen voor hun bevindingen.
Daarom gebruiken grote bedrijven als Facebook en Google deze bug bounty programma's, ook al volgen ze
alle andere benaderingen.
Zoals ik al zei, gebruiken ze dit nog steeds om ervoor te zorgen dat hun systemen altijd zo veilig mogelijk zijn en
zo min mogelijk bugs bevatten.
De nadelen hiervan zijn, ten eerste, dat het moeilijk is te garanderen dat alle aanvalsvlakken worden bestreken.
En ten tweede hebben veel bedrijven niet het bereik dat Google en Facebook hebben, dus kunnen ze niet zo
goed reclame maken voor hun bug bounties als de grote bedrijven.
Ze kunnen niet veel ethische hackers krijgen om hun website te testen.
Het is een uitdaging voor hen om deze bug bounty programma's te maken en de ingediende rapporten te valideren.
Maar dit wordt aangepakt door de bug bounty platforms die we tegenwoordig hebben, zoals bug bounty, dotcom
en de andere platforms.
Bug Bounty is eigenlijk een zusterbedrijf van die beveiliging.
Dus mijn mening is misschien een beetje bevooroordeeld, maar ik ben er vrij zeker van dat onze prijzen het meest concurrerend zijn
en dat we dezelfde service bieden.
Dus hoe dan ook, ik ben overal bij betrokken.
Je hebt de keuze.
Je kunt kijken wat je wilt, en het spijt me als ik je in de war heb gebracht met de herfstaanpak.
die ik net noemde, maar naar mijn mening zou je idealiter al deze vier benaderingen willen
volgen, als je kunt.
Dit kan behoorlijk duur worden.
Daarom doen veel bedrijven dat niet.
En ze zouden een compromis sluiten en alleen gaan voor drie en vier.
Dus ze doen alleen een patch test en hebben een bug bounty programma.
En dan sluiten andere bedrijven soms nog meer compromissen.
En kies een van de twee, doe een bug bounty programma of doe een pentest.
Naar mijn mening is een pentest geen vervanging voor een bug bounty-programma en vice versa.
Ik zou je aanraden de twee te doen, omdat, zoals ik al zei, elk van hen zijn voor- en
nadelen heeft.
Maar als je ze echt niet allebei kunt doen, doe er dan tenminste één als minimum.
Als eigenaar van een website of app bent u verantwoordelijk voor de gebruikersgegevens die de gebruikers u toevertrouwen,
en daarom moet u ten minste het absolute minimum doen om ervoor te zorgen dat hun gegevens veilig
worden behandeld en beveiligd.