När det kommer till företagsstacksäkerhet är mjukvaruapplikationer den svagaste länken. I Tillståndet för applikationssäkerhet, 2020Forrester säger att majoriteten av externa attacker sker antingen genom att man utnyttjar en sårbarhet i programvaran (42 %) eller genom en webbapplikation (35 %).
Utvecklare är under press att släppa funktioner så snart som möjligt eftersom applikationer blir mer komplexa och utvecklingstiderna krymper. För att uppnå differentierad och övertygande applikationsfunktionalitet förlitar sig utvecklare alltmer på tredjepartsbibliotek.
Denna övergång till komponenter med öppen källkod gör säkerhet mer komplexa metoder för företag. Nya ramverk som behållare och API:er komplicerar applikationssäkerheten ytterligare.
Med utvecklare som pressas att släppa nya funktioner ständigt, står organisationer inför en mycket reell risk för att säkerheten inte kan hålla jämna steg. Säkerhet kan uppnås genom att införliva bästa praxis för applikationssäkerhet i mjukvaruutvecklingens livscykel och implementera dem.
Varför är webbsäkerhetstestning viktigt?
Att testa webbapplikationer och deras konfigurationer för säkerhetssårbarheter är målet med webbsäkerhetstestning. Applikationsskiktsattacker (dvs. inriktade på HTTP-baserade applikationer) är de primära målen.
Det är vanligt att man skickar in olika typer av input till en webbapplikation för att framkalla fel och få den att uppträda oväntat. I dessa så kallade ”negativa tester” inspekteras systemet för beteende som inte är avsett.
Det är också viktigt att notera det Webbsäkerhetstestning handlar inte bara om att testa de säkerhetsfunktioner som är implementerade i applikationen (t.ex. autentisering och auktorisering).
Det är också nödvändigt att testa att andra funktioner (t.ex. affärslogik och in- och utdatavalidering) implementeras på ett säkert sätt. Säker åtkomst till webbapplikationens funktioner är målet.
Vilka är de olika typerna av säkerhetstester?
- Dynamiskt applikationssäkerhetstest (DAST). För överensstämmelse med lagstadgade säkerhetsbedömningar är detta automatiserade programsäkerhetstest idealiskt för internt vända, lågriskapplikationer. En kombination av manuell webbsäkerhetstestning och DAST är den bästa metoden för medelriskapplikationer och kritiska applikationer som genomgår mindre förändringar.
- Statiskt applikationssäkerhetstest (SAST). Denna metod för applikationssäkerhet testar både manuellt och automatiskt. En applikation kan testas på detta sätt utan att den behöver köras i en produktionsmiljö. Dessutom tillåter det utvecklare att systematiskt upptäcka och eliminera säkerhetssårbarheter i programvaran genom att skanna källkoden.
- Penetrationstest. Speciellt för applikationer som genomgår stora förändringar är detta manuella applikationssäkerhetstest idealiskt. Bedömningar inkluderar affärslogik och motståndarbaserade tester för att identifiera avancerade attackscenarier.
- Runtime Application Self Protection (RASP). Ett antal tekniska tekniker används i detta föränderliga tillvägagångssätt för applikationssäkerhet för att instrumentera en applikation på ett sådant sätt att attacker kan övervakas när de utförs och, helst, blockeras i realtid.
Hur minskar applikationssäkerhetstestning din organisations risk?
Majoriteten av webbapplikationsattacker
- SQL-injektionstekniken
- Cross-Site Scripting (XSS)
- Utförande av kommandon på distans
- Traversering av stig
Attackresultat
- Innehåll som är begränsat
- Konton som har utsatts för intrång
- Skadlig programinstallation
- Förlorade intäkter
- Kunder tappar förtroendet
- Anseende skada
- Samt mycket mer
Dagens webbmiljö är utsatt för en lång rad problem. Förutom att veta hur en applikation kan utnyttjas, kommer att känna till de potentiella utfallen av attacken hjälpa ditt företag att förebygga ta itu med sårbarheterna och noggrant testa för dem.
Begränsande kontroller kan tillämpas under de tidiga stadierna av SDLC efter att ha identifierat grundorsaken till sårbarheterna. Dessutom kan ett webbapplikationssäkerhetstest dra fördel av kunskapen om hur dessa attacker fungerar för att rikta in sig på kända platser av intresse.
För att hantera ditt företags risk måste du förstå effekten av en attack, eftersom den kan användas för att mäta sårbarhetens totala svårighetsgrad.
Som ett resultat av ett säkerhetstest kan fastställande av svårighetsgraden av upptäckta problem hjälpa dig att prioritera saneringsinsatser effektivt och effektivt. Minimera ditt företags risk genom att börja med frågor av kritisk svårighetsgrad och gå vidare till frågor med lägre påverkan.
En potentiell konsekvensbedömning av varje applikation i ditt företags applikationsbibliotek innan ett problem identifieras kan hjälpa dig att prioritera applikationssäkerhetstestning.
När webbsäkerhetstestning har en etablerad lista med högprofilerade applikationer, kan vi schemalägga testerna för att rikta in ditt företags kritiska applikationer först så att risken mot ditt företag kan minskas.
Vilka funktioner bör granskas under ett säkerhetstest för webbapplikationer?
Flera funktioner bör undersökas under säkerhetstestning av webbapplikationer, men listan är inte uttömmande. Din organisation kan utsättas för allvarliga risker genom en olämplig implementering av var och en.
- Applikations- och serverkonfiguration- Defekter kan vara relaterade till krypteringskonfiguration, webbserverkonfigurationer, etc.
- Indatavalidering och felhantering- De vanligaste injektionssårbarheterna, inklusive SQL-injektion och cross-site scripting (XSS), är resultatet av dålig in- och utdatahantering.
- Autentisering och sessionshantering- Sårbarheter kan leda till efterbildning av användare. En stark legitimationspolitik är också väsentlig.
- Tillstånd- Verifiera applikationens förmåga att förhindra vertikal och horisontell behörighetseskalering.
- Företagslogik- Denna typ av logik är väsentlig för de flesta affärsapplikationer.
- logik på klientsidan- Den här typen av funktion blir allt vanligare på moderna, JavaScript-tunga webbplatser, såväl som på webbplatser som använder andra klientsidesteknologier (t.ex. Silverlight, Flash, Java-applets).
Topp 10 bästa praxis för webbapplikationssäkerhet
Följande är de tio bästa metoderna för applikationssäkerhet som din organisation redan bör implementera.
#1 Spåra dina tillgångar
Om du inte vet vad du har kan du inte skydda det.
För vilka funktioner eller appar använder du specifika servrar? I vilka webbappar använder du komponenter med öppen källkod?
Tycker du att det inte är viktigt att spåra dina tillgångar? Det är mycket viktigt att komma ihåg vilken programvara som körs inom varje applikation – fråga bara Equifax, som fick böter på 700 miljoner dollar för att ha misslyckats med att skydda data från över 145 miljoner kunder.
En av kreditvärderingsinstitutets kundwebbportaler komprometterades efter att en öppen källkodskomponent, Apache Struts, inte patchades. Företaget säger att det inte var medvetet om att kundportalen använde den sårbara öppen källkodskomponenten.
Ju tidigare du börjar spåra dina tillgångar, desto färre huvudvärk och katastrofer får du senare. När organisationer skalar sin utveckling kan denna process kännas som en sisyfisk uppgift.
Du bör också klassificera dina tillgångar, notera de som är avgörande för ditt företags funktioner och de som är av mindre betydelse. Sedan kan du bedöma hot och åtgärda dem senare.
#2 Utför en hotbedömning
Om du gör en lista över vad du behöver skydda kan du sedan identifiera de hot du möter och hur de kan mildras.
Hur skulle hackare kunna ta sig in i din applikation? Vilka befintliga säkerhetsåtgärder har du på plats? Vilka ytterligare verktyg krävs?
Du måste svara på dessa och andra frågor som en del av din hotbedömning.
Ändå måste du också vara realistisk om vilken säkerhetsnivå du kan njuta av. Oavsett hur säkert du gör ditt system kan du fortfarande hacka det. Dessutom måste du vara ärlig om de åtgärder ditt team kan upprätthålla över tid.
Du kan riskera att dina säkerhetsstandarder och rutiner ignoreras genom att trycka på för mycket. Ta säkerheten på allvar och skynda inte på det.
Använd följande formel för att utvärdera din risk:
Risk = Sannolikhet för attack x Impact of Attack.
Risk kan också ses som sannolikheten för att något ska hända kontra hur allvarliga konsekvenserna är.
Även om det skulle vara katastrofalt om en val faller från himlen och krossar dig, är det osannolikt att det kommer att hända.
Ett myggbett på en vandring är å andra sidan ganska troligt, men kommer sannolikt inte att orsaka betydande skada utöver några få kliande knölar.
#3 Håll koll på din patchning
Installerar du de senaste patcharna på dina operativsystem? Använder du programvara från tredje part? Chansen är stor att du släpar efter, vilket betyder att du är utsatt.
Ett av de viktigaste stegen du bör vidta för att säkerställa säkerheten för din programvara är att uppdatera programvaran, antingen från en kommersiell leverantör eller från en öppen källkodsgemenskap.
När en sårbarhet upptäcks och ansvarsfullt rapporteras till produkt- eller projektägaren publiceras den på säkerhetsrådgivningssajter och databaser som WhiteSource Vulnerability Database.
Om möjligt bör en fix skapas och släppas före publicering, vilket ger användarna möjlighet att säkra sin programvara.
Om du däremot inte använder en patch när en blir tillgänglig kommer du inte att dra nytta av förbättrad säkerhet.
Om du är orolig för att uppdatering till den senaste versionen kan skada din produkt, automatiserade verktyg kan hjälpa mycket. Vilken dag i veckan som helst bör du prioritera uppdatering och korrigering som en del av dina bästa metoder för applikationssäkerhet.
#4 Hantera dina containrar
Under de senaste åren har behållare vuxit i popularitet när fler organisationer använder tekniken på grund av dess flexibilitet, vilket förenklar processen att utveckla, testa och distribuera komponenter i olika miljöer under hela mjukvaruutvecklingens livscykel (SDLC).
Det är allmänt accepterat att containrar erbjuder säkerhetsfördelar som ger dem en fördel. På grund av deras fristående OS-miljö är de dessutom segmenterade efter design, vilket sänker risknivån.
Ändå fortsätter containrar att vara sårbara för utnyttjande som en breakout-attack, där isoleringen har brutits. Behållare kan också innehålla en sårbarhet i koden som lagras i dem.
För CI/CD-pipelinesäkerhet bör du söka efter sårbarheter från början till slut, inklusive i dina register.
Utöver dessa skanningar inkluderar bästa praxis för programsäkerhet vid arbete med behållare också viktiga uppgifter som att signera dina egna bilder med verktyg som Docker Content Trust om du använder Docker Hub, eller Shared Access Signature om ditt team använder Microsoft Azure.
#5 Prioritera dina åtgärdsalternativ
Det har funnits ett ökande antal sårbarheter under de senaste åren, och denna trend visar inga tecken på att sakta ner snart.
Följaktligen är utvecklare upptagna med sanering. För team som hoppas kunna hålla sina applikationer säkra samtidigt som de förblir sunda, är prioritering avgörande.
Hotbedömningar görs baserat på svårighetsgraden av en sårbarhet (CVSS-klassificering), hur kritisk den påverkade applikationen är och ett antal andra faktorer.
Du måste veta om sårbarheten med öppen källkod faktiskt påverkar din egen kod när det kommer till sårbarheter med öppen källkod.
Ineffektiv och inte en hög risk även om CVSS-betyget för den sårbara komponenten är kritisk om den inte tar emot samtal från din produkt.
Smarta strategier är de som prioriterar de mest angelägna hoten först, baserat på de faktorer som finns, och lämnar lågriskerna till senare.
#6 Kryptera, kryptera, kryptera
OWASP Top 10 har inkluderat kryptering av data i vila och under överföring i flera år, vilket gör det till ett krav för alla applikationssäkerhetslista med bästa praxis.
Man-in-the-middle-attacker och andra former av intrång kan avslöja känslig data när du misslyckas med att låsa din trafik ordentligt.
När du lagra lösenord och användar-ID:n i vanlig text, till exempel, utsätter du dina kunder för risker.
Se till att du använder SSL med ett uppdaterat certifikat som en del av din grundläggande checklista för kryptering. Låt dig inte lämnas kvar nu när HTTPS är standarden. Hashing rekommenderas också.
Dessutom bör du aldrig "rulla din egen krypto" som de säger. Överväg säkerhetsprodukter som stöds av ett dedikerat team med erfarenhet för att göra jobbet rätt.
#7 Hantera privilegier
Du behöver inte ge tillgång till allt till alla i din organisation. Applikationer och data är endast tillgängliga för dem som behöver dem genom att följa bästa praxis för nätverkssäkerhet och bästa praxis för applikationssäkerhet.
Det finns två skäl till detta. Det första du behöver göra är att förhindra en hackare från att använda marknadsföringsuppgifter för att få tillgång till ett system som innehåller annan mer känslig data, till exempel ekonomi eller juridisk.
Insiderhot är också ett problem, vare sig det är oavsiktligt – som att förlora en bärbar dator eller skicka fel bilaga till ett e-postmeddelande – eller skadliga.
Principen om minsta privilegium att förse anställda med endast den data de behöver när det gäller att komma åt data kan minska din exponering jämfört med att inte ha några kontroller på plats.
#8 Omfamna automatisering för din sårbarhetshantering
Säkerheten för deras applikationer har blivit allt viktigare för utvecklare under de senaste åren, särskilt när det kommer till uppgifter som sårbarhetshantering.
För att ta itu med säkerhetens förskjutning åt vänster, testar utvecklarteam tidigt och ofta, och driver så många av sina säkerhetskontroller tidigt i utvecklingsprocessen när det är enklare och billigare att åtgärda sårbarheter.
För att hantera den svårhanterliga testprocessen på grund av den stora mängden sårbarheter, kräver utvecklare automatiserade verktyg.
För att hitta potentiella säkerhetssårbarheter i din proprietära kod kan statisk applikationssäkerhetstestning (SAST) och dynamisk applikationssäkerhetstestning (DAST) användas under utvecklingen.
Säkerhetshål stängs med SAST och DAST, men proprietär kod utgör en relativt liten del av din totala kod.
I mer än 92 % av alla moderna applikationer utgör komponenter med öppen källkod 60–80 % av din kodbas. Din applikationssäkerhetschecklista bör prioritera att säkra komponenter med öppen källkod.
Med hjälp av analysverktyg för mjukvarusammansättning kan team köra automatiserade säkerhetskontroller och rapporter i hela SDLC, identifiera varje öppen källkodskomponent i sin miljö och indikera vilken av dem som har en känd sårbarhet som utgör en säkerhetsrisk för dina applikationer.
Du kan bättre hantera dina sårbarheter genom att flytta dina automatiska tester för säkerhetsproblem med öppen källkod till vänster.
#9 Penetrationstestning
En lista över bästa praxis för applikationssäkerhet skulle vara ofullständig utan att nämna penntestning, även om automatiserade verktyg hjälper till att fånga de allra flesta säkerhetsproblem.
Genom att testa med penna och papper kan du peta och driva din app för att hitta svagheter. Om en beslutsam hackare försöker bryta sig in i din applikation vet duktiga penntestare exakt vilka steg de behöver ta.
Hackingföretag kan anlitas eller frilansare kan delta i bug-bounty-program som BugCrowd och HackerOne. Ditt företag bör sponsra en bug-bounty om du inte redan gör det.
Om du anlitar penntestare är det mycket bättre att betala för dem än att ta itu med konsekvenserna av ett verkligt brott.
#10 Var försiktig med tokens
Trots det faktum att detta är lätt att säkra, säkrar många utvecklare inte sina tokens ordentligt för tredje part.
Genom att söka efter populära utvecklarwebbplatser kan du enkelt hitta osäkra tokens online. Istället för att lagra tokendetaljer någon annanstans, inkluderar utvecklarna dem helt enkelt i sina arkiv med öppen källkod.
En grundläggande bästa praxis för applikationssäkerhet är att korrekt säkra dina tredjeparts-tokens. Du bör inte lämna tokens som du har köpt liggande i din kod som någon kan ta.
Best Practices för applikationssäkerhet som grundläggande praxis
Var och en av de bästa metoderna som beskrivs här bör integreras i din organisations kontinuerliga utvecklingsprocess. Ditt företags applikationer och data är i fara om du inte minimerar risken. Följ dessa steg för att minimera risken.
Att undvika de misstag som andra sannolikt kommer att göra är ett sätt att ligga före hackare, så det är svårare att angripa dig. Det kommer aldrig att finnas en perimeter eller applikationssäkerhetsåtgärd som är helt hacksäker.
Men att följa dessa grundläggande bästa praxis kan gå långt för att hålla din applikation inte värt besväret för hackarna.
