Cybersäkerhet för utvecklare: Lathund
Hem Säkerhet Cybersäkerhet för utvecklare: Lathund

Cybersäkerhet för utvecklare: Lathund

Publicerat av: Redaktionen

Frågan om cybersäkerhet berör inte bara experter utan även vanliga utvecklare.

Inte alla projekt kan ha en särskilt utsedd säkerhetsspecialist, så den som på ett eller annat sätt behöver bära denna börda kan vara du.

I sådana fall kan det vara bra att ha en lathund, så jag har tagit fram en lista över saker som behöver hanteras. Listan är varken kort eller lång, men den verkar åtminstone vara relativt hanterbar och begriplig.

Lathund för cybersäkerhet

Tankesättet kring programvarusäkerhet är i grunden annorlunda och därför inte så intuitivt jämfört med allmänna funktionskrav, som vi ofta bryr oss mest om. Ändå är säkerhet en avgörande egenskap hos programvara, särskilt när det gäller programvarustyrda maskiner som kan påverka livet och hälsan för kunder, eller system som behandlar personuppgifter.

Även om det önskade programbeteendet ofta anses vara det huvudsakliga målet, så är det viktigaste problemet med säkerhet däremot vad ett program inte bör göra – alltså att förhindra det oönskade beteendet.

Säkerhetsegenskaper

De tre främsta egenskaperna hos programvarusäkerheten som vi strävar efter att efterfölja är:

  • Konfidentialitet
    Innebär att känslig information inte får läcka ut till obehöriga parter.
  • Integritet
    Innebär att bevarad information inte får skadas av obehöriga parter.
  • Tillgänglighet
    Innebär att ett system ska förbli lyhört för förfrågningar (enligt de överenskomna villkoren).

Intuitiv tillgänglighet associeras ofta med skydd mot DoS-attacker, men det är inte begränsat till dem. Tänk bara på följande problem av samma betydelse:

  • Förnyelse av IP-adressinnehav.
  • Förnyelse av domännamnsinnehav.
  • Utbyte av krypterings- och autentiseringscertifikat.

När sådana situationer kränks anses programvaran vara sårbar.

Cybersäkerhet för utvecklare: LathundSårbarhet är en säkerhetsrelevant programvarudefekt som kan utnyttjas för att uppnå ett oönskat beteende. Om en sårbarhet orsakas av en bristfällig design snarare än kod kallas det ett fel.

Säkerhetsprinciper

Det finns en uppsättning gemensamma principer som du bör följa för att bygga säker programvara. I allmänhet kan principerna delas in i följande kategorier:

  • Förebyggande eliminera defekter helt och hållet
    Det är till exempel möjligt att eliminera hela grupper av defekter genom att använda minnessäkra språk som Java eller C# istället för C/C++.
  • Begränsning minska skadan från exploatering av en okänd defekt
    Till exempel kan skadan i den kapade databasen minskas kraftigt om datan krypteras. Att blockera konton med misstänkt beteende och kräva ytterligare bekräftelse innan potentiellt skadliga åtgärder utförs är ett annat exempel.
  • Upptäckt identifiera och förstå angrepp (dvs övervakning)
    Det är nödvändigt att få information om potentiellt skadliga åtgärder så snart som möjligt. Omfattande telemetri i realtid är till stor hjälp i sådana fall.
  • Återställande ångra skadan
    ”Snabbt upplockad anses inte vara tappad” – därför är det alltid nödvändigt att ha datan säkerhetskopierad och att extra resurser är redo att vara tillgängliga i brådskande fall. Utöver detta är det mycket viktigt att ha procedurer för att återställa hackade användares konton.

De grundläggande principerna du bör följa när du utformar, implementerar eller underhåller programvaran är följande:

  • Välj enkelhet (förebyggande)
    1. Gynna enkel design
      ”Keep it simple, stupid” är en välkänd meme som passar perfekt i det här sammanhanget.
      Tänk till exempel efter en extra gång när du väljer mellan en gammaldags monolit och överhypade mikrotjänster. Överväg alltid tillgängliga funktioner och expertis.
    2. Använd felsäkra standardvärden
      Använda inte standardlösenord, tillämpa kryptografi som följer branschstandarden, välj vitlistning framför svartlistning etc.
    3. Förvänta dig inte en expertanvändare
      Ju mer obegränsad makt du lämnar över – desto större är risken för att användarfel. Till exempel kräver installation av applikationer från opålitliga källor på Android (APK-filer) uttrycklig aktivering av funktionen i enhetsinställningar, vilket är en hyfsat idiotsäker lösning.
    4. Gynna enkelt användargränssnitt
      Återigen – komplexiteten är säkerhetens fiende. Ett komplext användargränssnitt ökar risken för ett misstag från både utvecklares och användares sida.
    5. Undvik att tillåta användare att göra säkerhetsval
      Anta inte att användarna förstår kryptografischeman eller ens regler för säkert onlinebeteende, låt dem därför inte välja krypteringsalgoritmer och nycklar eller osäkra lösenord.
  • Motvilligt förtroende (förebyggande/begränsning)
    1. Använd en liten betrodd datorbas
      Ju fler komponenter (både hårdvara och mjukvara) som ditt system består av, desto bredare är attackytan. Av den anledningen bör varje ny plattform och varje tjänst du integrerar med betraktas som en risk.
    2. Undvik att använda din egen kryptografi
      Kryptografi är en så oerhört viktig fråga att det bara är fåfängt att försöka genomföra dess aspekter på egen hand, såvida du inte är en expert. Rätt tillvägagångssätt är istället att använda öppna, branschstandardiserade protokoll och algoritmer.
    3. Minsta möjliga behörigheter för komponenter och användare
      Var försiktig när du ger behörigheter till ditt program och användare (även indirekt). Behöver ditt program verkligen åtkomst till ett filsystem? Måste läsrättigheter i en databas kanske utföras under ett konto med högre behörigheter?
    4. Validering av indata
      Mata inte systemet med felformaterad data. Definiera tydligt vilka gränser som gäller för giltig data och upprätthåll dem genom vitlistning.
    5. Främja integritet – begränsa tillgången till personuppgifter
      Den formella definitionen av privata/personliga uppgifter kan variera beroende på lokal lagstiftning, men den gemensamma nämnare är den direkta eller indirekta möjlighet det ger att identifiera den individ som uppgifterna tillhör.
    6. Uppdelning
      Använd processer, containers och sandboxes för att isolera komponenter – eller till och med specifika åtgärder – från varandra.
  • Försvar på djupet (alla)
    1. Säkerhet genom mångfald (HTTPS + säkert språk + datakryptering + VPN)
      Kombinera alla säkerhetsmekanismer som står till ditt förfogande. Undvik samtidigt att använda verktyg du inte behärskar och hitta en expert om det behövs.
    2. Använd standardiserade och öppna källkodslösningar (undvik säkerhet genom vaghet)
      Sluta tro att proprietär programvara eller protokoll (särskilt dina egna) ger något slags skydd för att ingen känner till dem. Endast allmänt tillgängliga och professionella verktyg och protokoll kan hävda att de är säkra.
  • Övervakning och spårbarhet (förebyggande/återställande)
    1. Samla in loggar, telemetri
      Glöm inte att skapa larm för farliga/misstänkta händelser.
    2. Gör säkerhetskopior/ögonblicksbilder
      Håll dem på separata servers och ha mekanismer för deras återställande.

Det är säkert möjligt att komma på fler liknande principer, även om det i de flesta fall bör räcka att följa de redan definierade principerna.

Säker utvecklingsprocess

Det är ganska vanligt att behandla säkerhetsfrågor reaktivt och skjuta upp dem tills de utnyttjas och blir oacceptabla, vilket är ett bristfälligt tillvägagångssätt.

En säker utvecklingsprocess innebär att nödvändiga aktiviteter och metoder införs för varje steg i utvecklingen:

  • Krav
    1. Definiera säkerhetskrav (abuse case)
      Abuse case – motsatsen till ett use case (eller funktionellt krav). Det bör uttryckligen definiera vad ett system inte ska göra.
    2. Definiera de nödvändiga säkerhetsegenskaperna för systemkomponenterna (dvs konfidentialitet, integritet, tillgänglighet)
      Identifiera exakt vilka delar av den bevarade datan som är konfidentiella. Identifiera vilka roller som finns i systemet och vilken data de ska manipulera. Ta fram tillgänglighetskrav.
    3. Definiera säkerhetsmekanismer för att stödja de här egenskaperna (authentication, authorization, audit)
      De här tre mekanismerna betraktas ofta som en ”Golden Standard of Security”. Ett system kan inte anses säkert om det saknar ett av dem.
    4. Definiera hotmodeller
      Detta innebär att det är nödvändigt att identifiera en skadlig aktör och möjliga attackytor (t.ex. nätverkstrafik, lokala filer eller till och med visad data, etc.).
  • Design
    1. Hotdriven design (svarar på tidigare definierade hotmodeller i systemets design).
    2. Arkitektonisk riskanalys / -bedömning (identifiera potentiella brister i designen).
    3. Tillämpa säkerhetsprinciperna som definierats ovan (förebyggande, begränsning, upptäckt, återställande).
  • Genomförande
    1. Följ bästa kodningspraxis och riktlinjer.
    2. Genomför obligatoriska kodgranskningar.
    3. Använd automatiseringsverktyg för att upprätthålla högsta kodkvalitet.
      1. Statisk
      2. Symboliskt utförande.
      3. Konkoliskt utförande.
  • Testning
    1. Riskbaserade säkerhetstester
      Dessa tester syftar till de mest kritiska delarna av systemet, identifierade genom hotmodellering.
    2. Penetrationstestning
      Säkerhetsspecialister spelar gärningsmannens roll i ett försök att ta sig igenom säkerhetsmekanismerna.
    3. Fuzz-testning
      Att mata systemet med slumpmässig och felformad data kan ofta avslöja oönskade beteenden.

Vanliga konstruktionsfel och implementeringsfel

När du följer den säkra utvecklingsprocessen bör du alltid tänka på de misstag som utvecklare ofta gör sig skyldiga till:

  • Utgår ifrån ett förtroende i stället för att uttryckligen ge det.
  • Använder en autentiseringsmekanism som kan kringgås.
  • Auktoriserar utan tillräcklig förståelse för sammanhanget.
  • Blandar ihop datainstruktioner med kontrollinstruktioner. Detta var orsaken till ökända SQL-injektioner, XSS-attacker och fjärrkodkörningar.
  • Validerar inte data.
  • Använder inte kryptografin korrekt.
  • Identifierar inte känsliga data.
  • Integrerar externa komponenter utan att överväga deras attackyta.
  • Begränsar kommande förändringar av föremål och aktörer hårt.

OWASP- och topp 10-sårbarheter

Open Web Application Security Project är en ideell organisation som fokuserar på att förbättra säkerheten för programvara. Du kan ha god användning för dess resurser. De ger användbara riktlinjer och lathundar för populära utvecklingsplattformar som .NET och Java.

OWASP är främst känt för sina ”topp 10”-listor som beskriver de vanligaste sårbarheterna i olika domäner:

Det är mycket viktigt att vara väl insatt i de vanligaste sårbarheterna i din domän: förvarnad är förberedd.

Säkerhet för utvecklare: det viktigaste

Ta itu med säkerhetsproblem först, skjuta inte upp dem till slutet. Planera och genomför nödvändiga aktiviteter genom varje del av utvecklingen för att hålla dina kunder säkra och ditt rykte intakt.

Jag hoppas att du tycker att den här artikeln är användbar, men kom ihåg att det bara är en enkel lathund. Att bli en kompetent specialist kräver mycket lärande och övning.

Du behöver verkligen investera tid och resurser för att delta i relevanta kurser eller till och med uppnå certifiering i just ditt intresseområde.

av Mykola Mozgovy, Senior Software Developer på Sigma Software

Relaterade Artiklar

Vi använder cookies och andra identifierare för att förbättra din upplevelse. Detta gör att vi kan säkerställa din åtkomst, analysera ditt besök på vår webbplats. Det hjälper oss att erbjuda dig ett personligt anpassat innehåll och smidig åtkomst till användbar information. Klicka på ”Jag godkänner” för att acceptera vår användning av cookies och andra identifierare eller klicka ”Mer information” för att justera dina val. Jag Godkänner Mer Information >>