I september 2014 träffade en annan bomb, "Shellshock", säkerhetsgemenskapen i form av en uppsättning sårbarheter i "Bash", en komponent i de flesta UNIX-baserade system. Det har potential att orsaka stor skada, och samhället har varit i ett frenesi och försökt fixa alla påverkade system. Redan miljontals försök till attacker har kastats mot nästan alla system på Internet, och vissa angripare har försökt förvandla detta till en självreplikerande "mask". För att anses vara säkra måste leverantörernas nätverk skyddas av flerskiktsbrandväggar och intrångsdetekteringssystem. Dessa nätverk måste också övervakas av ett 24x7x365 Security Operations Center (SOC). Den enda säkerhetsstrategin som består är en "SÄKERHET I DJUP"-strategi, liknande den som följs av LiveOps, med flera överlappande och redundanta skyddslager.
På LiveOps använder vi ett holistiskt förhållningssätt till säkerhet. Från det ögonblick ett projekt föreställs och placeras på ritbordet, genom dess utvecklings- och teststeg tills efter implementeringen, granskar vårt applikationssäkerhetsteam varje steg. Säkerhet måste vara en integrerad del av hur en leverantör designar och bygger sin plattform genom varje steg i mjukvaruutvecklingens livscykel – inte en eftertanke. Dessutom bör säkerhetssystemet testas noggrant för att bevisa att lösningen följer, eller överträffar, branschstandardens säkerhetskrav. Molnbaserade system kräver övervakning dygnet runt för att säkerställa säkerheten och integriteten hos kunddata, för att skydda mot säkerhetshot eller dataintrång och för att förhindra obehörig åtkomst till kunddata.
I samma ögonblick som ett system placeras i våra säkra datacenter övervakas och granskas det, patchas och analyseras. Datan skyddas ända fram till slutet när hårddisken som data sitter på flera år senare möter sin sista viloplats i en industriell dokumentförstörare på en återvinningscentral.
Närhelst en sårbarhet avslöjas, som med Shellshock (eller någon av dussintals mindre synliga sårbarheter som upptäcks varje månad), granskar LiveOps-teamet effekten, beslutar om en åtgärdsplan och implementerar den med lämpligt team.
I fallet med Shellshock bestod vårt tillvägagångssätt av följande sju steg:
- Sök efter alla fall av allmän sårbarhet med hjälp av automatiska genomsökningar från flera leverantörer och manuell testning. (Inga hittades.)
- Uppdatera regler för webbapplikationsbrandvägg och meddela Security Operation Center-teamet.
- Granska IDS-loggar för attackförsök. (Olika försök sågs, men inga lyckades.)
- Rulla ut i full skala av lämpliga lappar med olika iterationer.
- Testa proof-of-concept-koden för att verifiera framgången med patchningen på varje maskin.
- Kör interna sårbarhetssökningar för att verifiera att inga rutor har missats.
- Kör en "white box"-granskning av all produktionskällkod för "bash"-användning.
En del av dessa uppgifter utfördes parallellt och krävde ansträngning från hela teamet, men vi lyckades lösa detta problem snabbt, utan säkerhetsexponering och utan påverkan på produktionsprocesserna.
Vad kan du göra som användare av molnsystem?
Förutom de vanliga bästa praxis för säkerhet (som vi alltid är glada att ge råd till våra kunder), är det enda du kan göra att vara vaksam och se till att du granskar din molnleverantör ordentligt.
Sådana incidenter kommer att hända igen i framtiden. Se till att välja en partner som är redo för dem.
Bild med tillstånd av Stuart Miles på FreeDigitalPhotos.net.
