Als het gaat om enterprise stack-beveiliging, zijn softwaretoepassingen de zwakste schakel. In De staat van applicatiebeveiliging, 2020, Forrester zegt dat de meeste externe aanvallen plaatsvinden door misbruik te maken van een softwarekwetsbaarheid (42%) of via een webtoepassing (35%).
Ontwikkelaars staan onder druk om functies zo snel mogelijk vrij te geven, aangezien applicaties complexer worden en de ontwikkelingstijdlijnen korter worden. Om gedifferentieerde en overtuigende applicatiefunctionaliteit te bereiken, vertrouwen ontwikkelaars steeds meer op bibliotheken van derden.
Deze verschuiving naar open source componenten zorgt ervoor dat veiligheid praktijken voor bedrijven complexer. Nieuwe frameworks zoals containers en API's maken applicatiebeveiliging nog ingewikkelder.
Omdat ontwikkelaars voortdurend onder druk worden gezet om nieuwe functies uit te brengen, lopen organisaties een zeer reëel risico dat de beveiliging het tempo niet bijhoudt. Beveiliging kan worden bereikt door best practices voor applicatiebeveiliging op te nemen in de levenscyclus van softwareontwikkeling en deze te implementeren.
Waarom zijn webbeveiligingstests belangrijk?
Het testen van webapplicaties en hun configuraties op beveiligingsproblemen is het doel van webbeveiligingstests. Applicatielaagaanvallen (dwz gericht op HTTP-gebaseerde applicaties) zijn de primaire doelen.
Het is gebruikelijk om verschillende typen invoer naar een webtoepassing te sturen om fouten te veroorzaken en ervoor te zorgen dat deze zich onverwacht gedraagt. Bij deze zogenaamde “negatieve testen” wordt het systeem gecontroleerd op gedrag dat niet de bedoeling is.
Het is ook belangrijk om op te merken dat Webbeveiligingstests gaat niet alleen over het testen van de beveiligingsfuncties die in de applicatie zijn geïmplementeerd (bijvoorbeeld authenticatie en autorisatie).
Het is ook nodig om te testen of andere functies (bijvoorbeeld bedrijfslogica en invoer- en uitvoervalidatie) op een veilige manier zijn geïmplementeerd. Veilige toegang tot de functies van de webapplicatie is het doel.
Wat zijn de verschillende soorten beveiligingstests?
- Dynamische applicatiebeveiligingstest (DAST). Om te voldoen aan wettelijke beveiligingsbeoordelingen, is deze geautomatiseerde applicatiebeveiligingstest ideaal voor intern gerichte applicaties met een laag risico. Een combinatie van handmatige webbeveiligingstests en DAST is de beste aanpak voor toepassingen met een gemiddeld risico en kritieke toepassingen die kleine wijzigingen ondergaan.
- Statische applicatiebeveiligingstest (SAST). Deze benadering van applicatiebeveiliging test zowel handmatig als automatisch. Op deze manier kan een applicatie worden getest zonder dat deze in een productieomgeving hoeft te draaien. Bovendien kunnen ontwikkelaars hiermee systematisch kwetsbaarheden in de softwarebeveiliging detecteren en elimineren door de broncode te scannen.
- Penetratie test. Vooral voor applicaties die grote veranderingen ondergaan, is deze handmatige applicatiebeveiligingstest ideaal. Evaluaties omvatten bedrijfslogica en op tegenstanders gebaseerde tests om geavanceerde aanvalsscenario's te identificeren.
- Zelfbescherming van runtime-applicaties (RASP). In deze evoluerende benadering van applicatiebeveiliging wordt een aantal technologische technieken gebruikt om een applicatie zo te instrumenteren dat aanvallen kunnen worden gevolgd terwijl ze worden uitgevoerd en, idealiter, in realtime kunnen worden geblokkeerd.
Hoe vermindert het testen van applicatiebeveiliging het risico van uw organisatie?
Meerderheid van aanvallen op webtoepassingen
- De SQL-injectietechniek
- Cross-site scripting (XSS)
- Op afstand uitvoeren van opdrachten
- Pad Traversal
Aanval resultaten
- Inhoud die beperkt is
- Accounts die zijn gehackt
- Kwaadaardige software-installatie
- Inkomsten verloren
- Klanten verliezen vertrouwen
- Reputatieschade
- En nog veel meer
De huidige webomgeving is onderhevig aan een breed scala aan problemen. Naast weten hoe een applicatie kan worden misbruikt, helpt het kennen van de mogelijke uitkomsten van de aanval uw bedrijf preventief de kwetsbaarheden aan te pakken en nauwkeurig te testen.
Beperkende controles kunnen worden toegepast tijdens de vroege stadia van de SDLC nadat de hoofdoorzaak van de kwetsbaarheden is geïdentificeerd. Bovendien kan een beveiligingstest van een webtoepassing profiteren van de kennis van hoe deze aanvallen werken om bekende aandachtspunten aan te vallen.
Om het risico van uw bedrijf te beheersen, moet u de impact van een aanval begrijpen, aangezien deze kan worden gebruikt om de totale ernst van de kwetsbaarheid te meten.
Als resultaat van een beveiligingstest kan het bepalen van de ernst van gedetecteerde problemen u helpen om de herstelinspanningen efficiënt en effectief te prioriteren. Minimaliseer het risico van uw bedrijf door te beginnen met kwesties van kritieke ernst en door te gaan naar kwesties met een lagere impact.
Een mogelijke impactbeoordeling van elke applicatie in de applicatiebibliotheek van uw bedrijf voordat een probleem wordt geïdentificeerd, kan helpen bij het prioriteren van applicatiebeveiligingstests.
Wanneer webbeveiligingstests een vaste lijst met spraakmakende applicaties hebben, kunnen we de tests plannen om eerst de kritieke applicaties van uw bedrijf te targeten, zodat het risico voor uw bedrijf kan worden verlaagd.
Welke functies moeten worden beoordeeld tijdens een beveiligingstest voor webtoepassingen?
Verschillende functies moeten worden onderzocht tijdens het testen van de beveiliging van webapplicaties, maar de lijst is niet uitputtend. Uw organisatie kan worden blootgesteld aan ernstige risico's door een ongepaste implementatie van elk.
- Applicatie- en serverconfiguratie- Defecten kunnen verband houden met de coderingsconfiguratie, webserverconfiguraties, enz.
- Invoervalidatie en foutafhandeling- De meest voorkomende injectiekwetsbaarheden, waaronder SQL-injectie en cross-site scripting (XSS), zijn het gevolg van slechte invoer- en uitvoerverwerking.
- Authenticatie en sessiebeheer- Kwetsbaarheden kunnen ertoe leiden dat gebruikers zich voordoen als gebruikers. Ook een sterk diplomabeleid is essentieel.
- autorisatie- Verificatie van het vermogen van de toepassing om verticale en horizontale escalatie van bevoegdheden te voorkomen.
- Bedrijfslogica- Dit soort logica is essentieel voor de meeste zakelijke toepassingen.
- Client-side logica- Dit type functie komt steeds vaker voor in moderne, JavaScript-zware websites, evenals websites die andere client-side technologieën gebruiken (bijv. Silverlight, Flash, Java-applets).
Top 10 best practices voor de beveiliging van webapplicaties
Hieronder vindt u de top tien best practices voor applicatiebeveiliging die uw organisatie al zou moeten implementeren.
#1 Volg uw activa
Als je niet weet wat je hebt, kun je het ook niet beschermen.
Voor welke functies of apps gebruik je specifieke servers? In welke webapps gebruik je open source componenten?
Vindt u het niet belangrijk om uw vermogen bij te houden? Het is erg belangrijk om te onthouden welke software er in elke applicatie draait - vraag het maar aan Equifax, die een boete van $ 700 miljoen kreeg voor het niet beschermen van de gegevens van meer dan 145 miljoen klanten.
Een van de klantenwebportalen van het kredietbeoordelaarsbureau werd gecompromitteerd nadat een open-sourcecomponent, Apache Struts, niet was gepatcht. Het bedrijf zegt niet te weten dat het klantenportaal de kwetsbare open source-component gebruikte.
Hoe eerder u begint met het bijhouden van uw vermogen, hoe minder kopzorgen en rampen u later zult hebben. Naarmate organisaties hun ontwikkeling opschalen, kan dit proces aanvoelen als een Sisyphean-taak.
U moet ook uw activa classificeren, en noteer de activa die van cruciaal belang zijn voor de functies van uw bedrijf en de activa die van minder belang zijn. Vervolgens kunt u bedreigingen beoordelen en deze later verhelpen.
#2 Voer een dreigingsanalyse uit
Als u een lijst maakt van wat u moet beschermen, kunt u de bedreigingen identificeren waarmee u wordt geconfronteerd en hoe deze kunnen worden beperkt.
Hoe zouden hackers kunnen inbreken in uw applicatie? Welke bestaande beveiligingsmaatregelen heeft u getroffen? Welke extra hulpmiddelen zijn nodig?
U moet deze en andere vragen beantwoorden als onderdeel van uw dreigingsanalyse.
Maar u moet ook realistisch zijn over het beveiligingsniveau dat u kunt genieten. Hoe veilig u uw systeem ook maakt, u kunt het nog steeds hacken. Bovendien moet je eerlijk zijn over de maatregelen die je team in de loop van de tijd kan handhaven.
U kunt het risico lopen dat uw beveiligingsnormen en -praktijken worden genegeerd door te veel aan te dringen. Neem beveiliging serieus en overhaast het niet.
Gebruik de volgende formule om uw risico te evalueren:
Risico = kans op aanval x impact van aanval.
Risico kan ook worden gezien als de kans dat iets gebeurt versus de ernst van de gevolgen.
Ook al zou het catastrofaal zijn als een walvis uit de lucht zou vallen en je zou verpletteren, het is onwaarschijnlijk dat dit zal gebeuren.
Aan de andere kant is een muggenbeet tijdens een wandeling vrij waarschijnlijk, maar het is niet waarschijnlijk dat het significante schade aanricht naast een paar jeukende bultjes.
#3 Blijf op de hoogte van uw patching
De nieuwste patches op uw besturingssystemen installeren? Gebruikt u software van derden? De kans is groot dat je achterloopt, wat betekent dat je wordt blootgesteld.
Een van de belangrijkste stappen die u moet nemen om de beveiliging van uw software te waarborgen, is de software bij te werken, hetzij van een commerciële leverancier of van een open-sourcegemeenschap.
Wanneer een kwetsbaarheid wordt ontdekt en op verantwoorde wijze wordt gerapporteerd aan de product- of projecteigenaren, wordt deze gepubliceerd op sites met beveiligingsadvies en in databases zoals de WhiteSource Vulnerability Database.
Indien mogelijk moet vóór publicatie een fix worden gemaakt en vrijgegeven, zodat gebruikers hun software kunnen beveiligen.
Als u echter geen patch toepast wanneer er een beschikbaar komt, profiteert u niet van een verbeterde beveiliging.
Als u bang bent dat het bijwerken naar de nieuwste versie uw product kan beschadigen, geautomatiseerde tools kan veel helpen. Elke dag van de week moet u prioriteit geven aan het updaten en patchen als onderdeel van uw best practices voor applicatiebeveiliging.
#4 Beheer uw containers
In de afgelopen jaren zijn containers in populariteit gegroeid naarmate meer organisaties de technologie adopteren vanwege de flexibiliteit, wat het proces van het ontwikkelen, testen en implementeren van componenten in verschillende omgevingen gedurende de levenscyclus van softwareontwikkeling (SDLC) vereenvoudigt.
Het is algemeen aanvaard dat containers beveiligingsvoordelen bieden die hen een voordeel geven. Bovendien zijn ze vanwege hun op zichzelf staande OS-omgeving gesegmenteerd qua ontwerp, waardoor het risiconiveau wordt verlaagd.
Toch blijven containers kwetsbaar voor exploits zoals een uitbraakaanval, waarbij het isolement is doorbroken. Containers kunnen ook een kwetsbaarheid bevatten in de code die erin is opgeslagen.
Voor CI/CD-pijplijnbeveiliging moet u van begin tot eind scannen op kwetsbaarheden, ook in uw registers.
Naast deze scans omvatten best practices voor applicatiebeveiliging bij het werken met containers ook belangrijke taken zoals het ondertekenen van uw eigen afbeeldingen met tools zoals Docker Content Trust als u Docker Hub gebruikt, of Shared Access Signature als uw team gebruikmaakt van Microsoft Azure.
#5 Geef prioriteit aan uw herstelwerkzaamheden
Er is de afgelopen jaren een toenemend aantal kwetsbaarheden en deze trend vertoont geen tekenen van vertraging op korte termijn.
Bijgevolg zijn ontwikkelaars bezig met sanering. Voor teams die hun applicaties veilig willen houden en toch gezond blijven, is prioritering essentieel.
Bedreigingsbeoordelingen worden uitgevoerd op basis van de ernst van een kwetsbaarheid (CVSS-classificatie), het kritieke karakter van de getroffen toepassing en een aantal andere factoren.
U moet weten of de open source-kwetsbaarheid daadwerkelijk van invloed is op uw eigen code als het gaat om open source-kwetsbaarheden.
Ineffectief en geen hoog risico, zelfs als de CVSS-classificatie van het kwetsbare onderdeel van cruciaal belang is als het geen oproepen van uw product ontvangt.
Slimme strategieën zijn strategieën die prioriteit geven aan de meest urgente bedreigingen, op basis van de aanwezige factoren, en die met een laag risico voor later overlaten.
#6 Versleutelen, versleutelen, versleutelen
De OWASP Top 10 bevat al jaren versleuteling van gegevens in rust en onderweg, waardoor het een vereiste is voor elke lijst met best practices voor toepassingsbeveiliging.
Man-in-the-middle-aanvallen en andere vormen van inbraak kunnen gevoelige gegevens blootleggen wanneer u uw verkeer niet goed afsluit.
Wanneer je wachtwoorden opslaan en gebruikers-ID's in platte tekst, bijvoorbeeld, u brengt uw klanten in gevaar.
Zorg ervoor dat u SSL gebruikt met een bijgewerkt certificaat als onderdeel van uw basischecklist voor versleuteling. Laat jezelf niet achter nu HTTPS de standaard is. Hashen is ook aan te raden.
Bovendien moet je nooit "je eigen crypto rollen" zoals ze zeggen. Overweeg beveiligingsproducten die worden ondersteund door een toegewijd team met de ervaring om het werk goed te doen.
#7 Rechten beheren
U hoeft niet iedereen in uw organisatie toegang te geven tot alles. Applicaties en gegevens zijn alleen toegankelijk voor degenen die ze nodig hebben door de best practices voor netwerkbeveiliging en best practices voor applicatiebeveiliging te volgen.
Hiervoor zijn twee redenen. Het eerste dat u moet doen, is voorkomen dat een hacker marketinggegevens gebruikt om toegang te krijgen tot een systeem dat andere, meer gevoelige gegevens bevat, zoals financiële of juridische gegevens.
Bedreigingen van binnenuit zijn ook een punt van zorg, of ze nu onbedoeld zijn - zoals het verliezen van een laptop of het verzenden van de verkeerde bijlage naar een e-mail - of kwaadaardig.
Het principe van het minste voorrecht om werknemers alleen de gegevens te geven die ze nodig hebben als het gaat om toegang tot gegevens, kan uw blootstelling verminderen in vergelijking met het feit dat er geen controles zijn.
#8 Omarm automatisering voor uw kwetsbaarheidsbeheer
De beveiliging van hun applicaties is de afgelopen jaren steeds belangrijker geworden voor ontwikkelaars, vooral als het gaat om taken als kwetsbaarheidsbeheer.
Om de verschuiving naar links van beveiliging aan te pakken, testen ontwikkelaarsteams vroeg en vaak, waarbij ze zoveel mogelijk van hun beveiligingscontroles vroeg in het ontwikkelingsproces pushen, wanneer het gemakkelijker en goedkoper is om kwetsbaarheden te verhelpen.
Om het logge testproces te beheren vanwege de enorme hoeveelheid kwetsbaarheden, hebben ontwikkelaars geautomatiseerde tools nodig.
Om mogelijke beveiligingsproblemen in uw eigen code te vinden, kunnen tijdens de ontwikkeling statische applicatiebeveiligingstests (SAST) en dynamische applicatiebeveiligingstests (DAST) worden gebruikt.
Beveiligingsgaten worden gedicht met SAST's en DAST's, maar bedrijfseigen code vormt een relatief klein deel van uw algehele code.
In meer dan 92% van alle moderne applicaties vormen open-sourcecomponenten 60-80% van uw codebase. Uw checklist voor applicatiebeveiliging moet prioriteit geven aan het beveiligen van open source-componenten.
Met behulp van analysetools voor softwaresamenstelling kunnen teams geautomatiseerde beveiligingscontroles en -rapporten uitvoeren in de SDLC, waarbij ze elk open source-onderdeel in hun omgeving identificeren en aangeven welke van hen een bekende kwetsbaarheid heeft die een beveiligingsrisico vormt voor uw applicaties.
U kunt uw kwetsbaarheden beter beheren door uw geautomatiseerde tests voor open source-beveiligingsproblemen naar links te schuiven.
#9 Penetratietesten
Een lijst met beste praktijken voor applicatiebeveiliging zou onvolledig zijn zonder pentesten te noemen, hoewel geautomatiseerde tools helpen bij het opsporen van de overgrote meerderheid van beveiligingsproblemen.
Door te testen met pen en papier kunt u uw app porren en porren om zwakke punten te vinden. Als een vastberaden hacker probeert in te breken in uw applicatie, weten goede pentesters precies welke stappen ze moeten nemen.
Hackers kunnen worden ingehuurd of freelancers kunnen deelnemen aan bug bounty-programma's zoals BugCrowd en HackerOne. Uw bedrijf zou een bug bounty moeten sponsoren als u dat nog niet doet.
Als u pentesters inhuurt, is het veel beter om ervoor te betalen dan om de gevolgen van een echte inbreuk op te vangen.
#10 Wees voorzichtig met tokens
Ondanks het feit dat dit gemakkelijk te beveiligen is, beveiligen veel ontwikkelaars hun tokens niet goed voor derden.
Door populaire ontwikkelaarswebsites te doorzoeken, kunt u eenvoudig onbeveiligde tokens online vinden. In plaats van tokendetails ergens anders op te slaan, nemen ontwikkelaars ze gewoon op in hun open-source repositories.
Een basis best practice voor toepassingsbeveiliging is om uw tokens van derden op de juiste manier te beveiligen. Je moet tokens die je hebt gekocht niet in je code laten rondslingeren zodat iemand anders het kan meenemen.
Best practices voor applicatiebeveiliging als basispraktijken
Elk van de best practices die hier worden beschreven, moet worden geïntegreerd in het continue ontwikkelingsproces van uw organisatie. De applicaties en gegevens van uw bedrijf lopen gevaar als u het risico niet minimaliseert. Volg deze stappen om het risico te minimaliseren.
Het vermijden van de fouten die anderen waarschijnlijk zullen maken, is een manier om hackers voor te blijven, dus u bent moeilijker te richten op aanvallen. Er zal nooit een perimeter- of applicatiebeveiligingsmaatregel zijn die volledig hackproof is.
Het volgen van deze basis-best practices kan er echter toe bijdragen dat uw applicatie niet de moeite waard is voor hackers.
