Horrorverhalen over securitylekken online lijken steeds erger te worden. Eerst werden er her en der creditcardgegevens gestolen, daarna werden er duizenden in één klap opgezogen en later werden dat miljoenen records van financiële gegevens die slecht beveiligde bedrijfsomgevingen verlieten.
Inmiddels zijn we afgestompt voor de bedreiging door al het nieuws over wéér een grote hack. Creditcardgegevens zijn maar een klein onderdeel van de buit waar gewiekste cybercriminelen op uit zijn en er komen schokkende verhalen uit de onderzoekscentra die de cyberoorlog bestuderen.
Het ontwerpen van veilige software begint al voordat de eerste regels worden geschreven – en dat is eigenlijk een Herculestaak. Om gatenbestendige code te schrijven moeten ontwikkelaars, ontwerpers, auditors en managers van tevoren bedenken wat er allemaal mis kan gaan met elk aspect van de programmatuur. Het is onmogelijk om alle acrobatische toeren te voorzien die slimme hackers, maar je kunt wel de aanvalsvectoren beperken en zorgen dat bij een eventuele inbraak de impact beperkt blijft.
Hier volgen 17 tips om sterker beveiligde code te maken. Deze lijst is verre van volledig, maar is een goed begin om je dichter bij dat doel te brengen. Schroom niet om je eigen ideeën om beveiligde code te schrijven achter te laten in een reactie hieronder. We worden immers uiteindelijk allemaal beter van robuustere beveiliging.
Tip 1: Invoermogelijkheden grondig testen
Aanvallers zoeken naar een toegangsweg tot je programma en de makkelijkste weg is de deur die je zelf openzet. Als gebruikers zelf iets kunnen invoeren in je site of applicatie, zullen hackers hun aandacht richten op mogelijkheden om daar iets mee te doen.
Een klassiek voorbeeld is de buffer overflow, waarbij het vrijgemaakte werkgeheugen volloopt. Dit wordt meestal veroorzaakt als C-programmeurs iedere string van tekens toelaten, totdat de string ‘0’ bereikt; het officiële C-symbool voor het laatste teken. Maar aanvallers ontdekten lang geleden al dat je het geheugen vol kunt laten lopen door lange pakketjes data te sturen, zolang ze maar niet die beëindigende ‘0’ sturen. Omdat het geheugen volloopt, worden stacks in de programmatuur overschreven en als je daar slim mee omspringt, kun je delen van de applicatie op afstand herschrijven.
Tijdens Webwerelds aandachtsperiode voor beveiligingslekken in 2011, Lektober, bleken gaten die SQL-injectie mogelijk maken vaak voor te komen. Bij zo’n aanval worden aanvallen gesmeed door malafide queries te bouwen. Je site vraagt bijvoorbeeld om een postcode die aan een record wordt toegevoegd, maar met wat trucjes is die scope flink uit te breiden. Als de software zomaar alle invoer accepteert, voer je malafide code rechtstreeks de SQL-database binnen.
De oplossing ligt in het grondig testen van de grootte en de structuur van de data die binnenkomen. En vertrouw nooit, maar dan ook nooit, de persoon aan de andere kant van de verbinding.
Over het algemeen zoeken programmeurs zoveel mogelijk flexibiliteit en zo min mogelijk beperkingen. Alle data die binnenkomen controleren kost de software veel tijd en is vermoeiend voor de ontwikkelaar. Talen als XML en JSON hebben niet veel manieren ingebouwd om deze problemen te voorkomen. Dus om hun programmatuur te beveiligen moeten ontwikkelaars vooral zelf de gebruikersinvoer checken.
Tip 2: Sla alleen op wat strikt noodzakelijk is
Voordat je om het postadres vraagt, bedenk dan eerst of het echt nodig is om de klant ouderwets een brief te sturen via het postkantoor. Als je uitsluitend via e-mail communiceert, is het dan wel nodig om adressen te weten te komen? Het kost tijd en opslagruimte om informatie te verwerken en het is een aantrekkelijk doelwit voor cyberdieven.
Programmeurs willen nogal eens gaan denken als een obsessieve verzamelaar en slaan kopieën op van alles wat maar weinig kans heeft om op een dag van nut te zijn. Dit instinct komt goed van pas bij het debuggen, maar laat een flink dataspoor achter.
Is iedere rij en kolom in een tabel wel echt nodig? Als je twijfelt over het nut van deze records is het tijd om formulieren korter en databasetabellen kleiner te maken. Probeer verzamelwoede te vermijden en maak alles zo simpel mogelijk. Datadieven zullen je verafschuwen, maar klanten vinden het alleen maar fijn dat ze minder tijd aan die webformulieren hoeven te besteden.
Tip 3: Vertrouw niet volledig op wachtwoorden
Iedereen weet hoe kwetsbaar het wachtwoordsysteem is, maar een betere oplossing ligt momenteel niet voor handen. Mensen vergeten wachtwoorden, kiezen makkelijk te raden woorden en gebruiken ze maar steeds weer opnieuw. Maar alternatieven zijn minder flexibel of een stuk complexer om te gebruiken.
Sommige bedrijven gebruiken al multifactor-authenticatie door meer stappen te gebruiken om identiteiten te verifiëren. Ze sturen dan bijvoorbeeld een sms’je met een code naar je telefoon die je dan vervolgens via de webinterface moet intikken. Dat is een handig mechanisme, totdat je je telefoon niet op zak hebt, de batterij leeg is of als je in een gebouw zit waar je geen bereik hebt.
Het is altijd mogelijk om meer beveiliging toe te voegen met bijvoorbeeld dongels met cryptografische sleutels. Deze zijn alleen duur en nog makkelijker kwijt te raken dan een telefoon. Weer andere sites houden bij via welk IP-adres je inlogt. Als het netwerk binnenkomt via een onbekend adres, sturen ze je voor de zekerheid een beleefd e-mail tje.
Deze systemen zijn allemaal niet perfect, maar stukken beter dan simpelweg op een wachtwoord te vertrouwen. Wees je dus bewust van de beperkingen van een wachtwoord, zelfs al hebben die een stevige mix van hoofdletters, onderkast, cijfers en tekens.
Tip 4: Onderhandel over de feature-eisen
Beveiligde programmatuur bouwen doe je niet alleen in de editor. Wanneer managers hun eisen opstellen en deze bespreken met de ontwikkelaars, moet iedereen serieus kijken naar hoe deze eisen later obstakels kunnen veroorzaken. Een feature kan leuk zijn, maar soms zorgt deze ervoor dat je nog meer gevoelige gegevens moet bewaren en daarom een hoger beveiligingsniveau moet nastreven. Is een mooie feature al deze extra kopzorgen wel waard?
Hét moment om ervoor te zorgen dat de uiteindelijke applicatie sterk beveiligd is, is het moment dat het document van feature-eisen nog in de beginschoenen staat. Dit eisenpakket is dan flexibeler, omdat klanten nog niet enthousiast zijn gemaakt voor features die je dwingen om andere securitykeuzes te maken.
Tip 5: Bouw vertragingen in
Veel aanvallen gebruiken een brute force-methode waarbij zoveel mogelijk variaties geprobeerd worden. Het kan duizenden, miljoenen of miljarden pogingen duren, maar de computer maalt daar niet om. Sommige mensen screenscrapen databases door zich voor te doen als gebruiker en miljoenen queries uit te voeren. Anderen proberen miljarden wachtwoorden uit tot de juiste combinatie is gevonden.
De oplossing om daarmee om te gaan is door progressieve vertragingen in te bouwen waar deze bots op vastlopen, op dezelfde manier als diensten of applicaties tarpits gebruiken. Je software moet niet vliegensvlug zijn, maar snel genoeg dat het voor mensen aanvoelt als watervlugge database. Maar voor een bot kan die snelheid tergend traag zijn.
Progressieve vertragingen worden bijvoorbeeld door een aantal log-in programma’s gebruikt, waarbij de vertraging op de database wordt verdubbeld bij elke foute poging. Weer anderen beperken het aantal aanvragen dat binnen kan komen via elk IP-adres. En sommige systemen vragen om een e-mailadres om je te vertragen. Een mens merkt niet zoveel van deze ingebouwde vertragingen, maar een bot wordt er behoorlijk inefficiënt van.
Tip 6: Gebruik versleuteling nog vaker dan je al wilde doen
Versleuteling wordt nog te weinig gebruikt omdat dit een extra stap toevoegt aan het systeem en debuggen wordt daar nog lastiger van. Het kan al moeilijk zijn om fouten te vinden in een systeem, het wordt er niet makkelijker op als je je daarbij ook nog eens door een ondoorgrondelijke laag cijfers moet worstelen.
Maar wat voor jou ondoorgrondelijk is, is eveneens ondoorgrondelijk voor de aanvallers. Door persoonlijke data te versleutelen voor ze worden opgeslagen in de database bespaart je veiligheidszorgen over de database, het onderliggende besturingssysteem en de hypervisor die het geheel draait. De juiste hoeveelheid versleuteling hoeft de functionaliteit niet te frustreren en de extra beveiligingslaag is zelfs een feature op zichzelf.
Tip 7: Werp muren op
De wens voor beveiliging delft meestal het onderspit als het gebruiksgemak erdoor wordt ondermijnt. Mensen vinden het verschrikkelijk om opnieuw in te loggen in een afgeschermd deel van het systeem, maar het kan zeer onveilig zijn om alles aan elkaar te koppelen binnen één portal. De zwakste schakel zorgt er namelijk voor dat alles voor het oprapen ligt.
Het is niet eenvoudig om te bepalen hoe eenvoudig een gebruiker zou moeten kunnen navigeren binnen het systeem. Hoe makkelijker je het legitieme gebruikers maakt, hoe simpeler het wordt voor een hacker als deze is binnengeglipt. Het kan logisch zijn om gevoelige onderdelen onder te brengen in een gescheiden systeem waarbij gebruikers opnieuw moeten inloggen. Een bank geeft misschien via de portal de mogelijkheid om mutaties te bekijken of geld te storten, maar er is dan meer authenticatie vereist om geld over te schrijven.
Tip 8: Gebruik bewezen libraries
Het is moeilijk om encryptie juist uit te voeren. Zelfs de beste theorie en zorgvuldig opgezette code kan backdoors en mazen bevatten. Een goed geteste library opnieuw bouwen is meestal verkeerd, maar het is nog problematischer als er versleuteling bij komt kijken. Goed geteste libraries zijn op dit vlak nóg belangrijker dan op andere gebieden. Ga voor betere code en probeer het wiel niet opnieuw uit te vinden.
Tip 9: Gebruik interne API’s
Al vroeg in hun carrière leren de meeste ontwikkelaars om programmatuur zoveel mogelijk op te splitsen en met elkaar te communiceren via goede API’s. Voor security is deze praktijk zelfs nog waardevoller want door API’s te gebruiken zijn audits makkelijker uit te voeren, gaten te vinden en problemen op te lossen. De modules kunnen apart bekeken worden en de resultaten tot een totaalplaatje worden gecombineerd. Het ligt vaak voor de hand om om dezelfde reden interne submodules te maken.
Tip 10: Laat auditors van buiten de code doornemen
Als een bedrijf investeert in een solide basis, zou het ook moeten investeren in audits van de ontworpen code. Hierdoor komen fouten aan het licht en worden suggesties gedaan om de code op te schonen. Over het algemeen geldt dat meer ogen ervoor zorgen dat potentiële problemen eerder worden opgemerkt. Buitenstaanders kunnen ook een patstelling doorbreken en hebben niet te maken met interne kantoorpolitiek. Ze weten vaak niet meer dan de eigen ontwikkelaars, maar hebben het voordeel niet betrokken te zijn bij interne partijen.
Tip 11: Gebruik analytische tools
Tools om de code te analyseren kunnen de moeite waard zijn. Ze zijn verre van perfect en niet zo slim als mensen, maar ze raken niet verveeld of moe. Tools als FindBugs van de University of Maryland zoeken naar veel voorkomende fouten die we inkloppen als we even niet goed opletten. Veel van deze fouten hebben niet zoveel te maken met security, maar sommige kunnen fataal zijn voor de code.
Tip 12: Beperk de rechten
Ontwikkelaars kijken graag vooruit en door gebruikers zoveel mogelijk toegang te geven, bereid je de software simpel op de toekomst voor. Als mensen net bij het project worden betrokken, waarom zou je ze dan geen leesrechten geven op de hele database en rechten om code toe te voegen? Als de software van een van je ontwikkelprojecten toegang tot een database nodig heeft, waarom zou je dan niet een automatische login aan het programma toevoegen om eenvoudig te lezen, schrijven en updaten?
Het openlaten van deuren is een simpele manier om irritante blokkades te voorkomen als gebruikers aan de slag willen en ze tegen een muur oplopen. Maar denk terug aan de allereerste tip: een open deur is het eerste pad dat hackers proberen om binnen te komen. Het is daarom een goed basisprincipe om de software én gebruikers de minst mogelijke rechten te geven die zijn vereist om hun werk uit te kunnen voeren.
Als dit een procedurele nachtmerrie wordt voor management dat allemaal wijzigingsverzoeken moet goedkeuren voor gebruikers die meer rechten nodig hebben, kan de architectuur wel eens te complex zijn opgezet. Sla je te veel informatie op? Als gebruikers meer informatie willen dan waar je bereid bent toegang tot te geven, bewaar je waarschijnlijk te veel gegevens. Door minder op te slaan (zie tip 2) is het makkelijker om meer gebruikers toegang te geven tot meerdere elementen.
Tip 13: Houd de aanvaller in het achterhoofd
Sla je bankgegevens op? Dan is de gemiddelde dief geïnteresseerd in je database. Maar het wordt alleen maar gevaarlijker als je bijvoorbeeld gps-locaties van gebruikers opslaat. Van tevoren nadenken over wie jouw data graag zouden willen stelen is een goede manier om je voor te bereiden.
Als je een specifieke aanvaller in gedachten hebt, kun je ook rekening houden met diens aanvalsvector terwijl je het systeem ontwerpt. Ze geven je een mooie houvast van hoe het programma juist niet gebruikt moet kunnen worden. Geen enkele beveiligingsmethode is perfect of volledig. Het is daarom een goed begin om te evalueren om welke aanvallen je je zorgen moet maken.
Tip 14: Zorg voor vertrouwen
Het is makkelijk om mensen die inloggen bij je site van nature te wantrouwen, maar denk eraan dat het ook andersom werkt en gebruikers jouw site kunnen wantrouwen. Ben jij wel echt de bank die ze zoeken of ben je een phishingsite die belangrijke gegevens probeert te ontfutselen.
Sommige sites besteden daarom aandacht aan methoden om te bewijzen dat ze de portal zijn die gebruikers zoeken. Bijvoorbeeld door een door de gebruikers opgegeven persoonlijke groet of foto weer te geven. Deze methode maakt het verkeer veiliger voor beide partijen.
Tip 15: Blijf op de hoogte
Het is van groot belang om de vakpers bij te houden om te zien hoe dreigingen zich ontwikkelen. Webwereld en Computerworld zijn bijvoorbeeld zulke bronnen die nieuwe aanvalsvectoren en trends beschrijven. Goede artikelen op websites en in vakbladen geven je een voorsprong doordat je even kunt nadenken als een cybercrimineel: hoe zou ik een systeem aanvallen?
Door te begrijpen wat er in het (recente) verleden is gebeurd, kun je je beter voorbereiden op de toekomst als je wordt blootgesteld aan een soortgelijke aanval. Cybercriminelen wisselen ideeën uit op schimmige fora en nieuwe aanvalsmogelijkheden worden op die manier regelmatig worden opgepikt door de vakpers. Door te weten wat er gaande is voorkom je dat een nieuwe dreiging koud op je dak valt.
Tip 16: Ga er dieper op in
De vakpers is een eerste stap om grote problemen te vermijden. Maar om je te wapenen, verdient het aanbeveling om onderzoeksrapporten en boeken te lezen die worden gepubliceerd als onderzoekers het probleem dieper hebben bekeken. Dit soort artikelen en boeken geven vaak een praktische omschrijving en methodes om de blootgelegde issues in de toekomst te voorkomen.
Het is vaak kostenbesparend om tijd en geld in een paar goede boeken te steken waarin goedbetaalde consultants hun adviezen geven. Een boek van zo’n schrijver dat 100 of 200 euro kost kan schreeuwend duur lijken, maar niet als je bedenkt dat dezelfde consultant 300 per uur eist en minimaal 20 uur moet worden ingehuurd.
Tip 17: Leer bij
Blijf je vaardigheden aanscherpen door je in te schrijven bij een (universitaire) opleiding of door een cursus online te volgen. Dit is ook een goede manier om dingen te leren die nog niet in boekvorm zijn geschreven. Deze docenten volgen ook de laatste trends via academische congressen en hebben zodoende vaak een hoop tips en trucs opgepikt. Zelfs als je al veel over een onderwerp weet, kan het erg zinnig zijn om een cursus te volgen om je bij te spijkeren over de nieuwste ontdekkingen en publicaties.
-
-
Er zijn nog geen reacties.Reageer
Preview