Säkerhetsåtgärder
Säkerhetsåtgärder upprätthåller och återställer säkerhetsgarantin för systemet när live-angripare angriper det. Säkerhetsaktiviteterna beskrivs väl av NIST Cybersecurity Framework-funktionerna Detect, Respond och Recover.
Upptäcka: Säkerhetsåtgärder måste identifiera förekomsten av angripare i systemet, som i de flesta fall är oanade att hålla sig dolda, eftersom detta gör att de kan uppnå sina mål obehindrat. Exempel på detta är att reagera på en avisering om misstänkt aktivitet eller proaktivt jaga efter avvikande händelser i företagsaktivitetsloggarna.
Svara: Vid identifiering av potentiella angrepp eller kampanjer måste säkerhetsåtgärder snabbt undersöka om det är en faktisk attack (sann positiv identifiering) eller ett falskt larm (falsk positiv identifiering) och sedan räkna upp angriparens omfattning och mål.
Återställa: Slutmålet med säkerhetsåtgärder är att bevara eller återställa säkerhetsgarantin (sekretess, integritet, tillgänglighet) för företagstjänster under och efter en attack.
Den största säkerhetsrisken som de flesta organisationer står inför är från mänskliga angreppsoperatörer (med olika kunskapsnivåer). Detta beror på att risken från automatiserade/upprepade attacker har minimerats avsevärt för de flesta organisationer med signaturer och maskininlärningsbaserade metoder som är inbyggda i skydd mot skadlig kod (även om det finns anmärkningsvärda undantag som Wannacrypt och NotPetya, som gick snabbare än dessa försvar).
Medan mänskliga angreppsoperatörer är svåra att möta på grund av deras anpassningsbarhet (kontra automatiserad/upprepad logik), fungerar de med samma "mänskliga hastighet" som försvar, vilket bidrar till att jämna ut spelplanen.
Säkerhetsåtgärder (kallas ibland för Security Operations Center( SOC) har en viktig roll att spela för att begränsa den tid och åtkomst som en angripare kan få till värdefulla system och data. Varje minut som en angripare har i miljön kan de fortsätta att utföra attackåtgärder och få åtkomst till känsliga/värdefulla system.
Mål och mått
De mått som du mäter har en betydande inverkan på beteenden och resultat av säkerhetsåtgärder. Genom att fokusera på rätt mått kan du öka kontinuerliga förbättringar inom rätt områden som på ett meningsfullt sätt minskar risken.
För att säkerställa att säkerhetsåtgärder effektivt innehåller angripares åtkomst bör målen fokusera på
Att minska tiden för att bekräfta en avisering för att säkerställa att identifierade angripare inte ignoreras medan angripare ägna tid åt att undersöka falska positiva resultat.
Minska tiden för att åtgärda en upptäckt angripare för att minska deras möjlighet att utföra och angripa och nå känsliga system
Prioritera säkerhetsinvesteringar i system som har högt inbyggda värde (sannolika mål/stor inverkan på verksamheten) och åtkomst till många system eller känsliga system (administratörskonton och känsliga användare)
Öka fokus på proaktiv jakt på angripare när programmet mognar och reaktiva incidenter blir under kontroll. Fokusera på att minska den tid som en angripare med högre kompetens kan arbeta i miljön (till exempel tillräckligt kvalificerad för att undvika reaktiva aviseringar).
Mer information om hur Microsofts SOC använder dessa mått finns i https://aka.ms/ITSOC .
Hybrid enterprise-vy
Säkerhetsåtgärder bör se till att deras verktyg, processer och analytikers kompetensuppsättningar ger insyn i hela deras hybrideredskap.
Angripare begränsar inte sina åtgärder till en viss miljö när de riktar in sig på en organisation, de attackerar resurser på valfri plattform med valfri tillgänglig metod. Företagsorganisationer som inför molntjänster som Azure och AWS använder effektivt en hybrid av molntillgångar och lokala tillgångar.
Verktyg och processer för säkerhetsåtgärder bör utformas för attacker på molnbaserade och lokala tillgångar samt för angripare som pivotering mellan molnresurser och lokala resurser med hjälp av identiteter eller andra metoder. Den här företagsomfattande vyn gör det möjligt för säkerhetsteam att snabbt identifiera, reagera och återställa från attacker, vilket minskar organisationens risk.
Använda interna identifieringar och kontroller
Använd om möjligt säkerhetsidentifiering och kontroller som är inbyggda i molnplattformen innan du skapar anpassade identifieringar med hjälp av händelseloggar från molnet.
Molnplattformar utvecklas snabbt med nya funktioner, vilket kan göra det svårt att underhålla identifieringar. Interna kontroller underhålls av molnleverantören och är vanligtvis av hög kvalitet (låg falsk positiv frekvens).
Eftersom många organisationer kan använda flera molnplattformar och behöver en enhetlig vy i hela företaget, bör du se till att dessa interna identifieringar och kontroller matar in ett centraliserat SIEM eller ett annat verktyg. Vi rekommenderar inte att du försöker ersätta generaliserade logganalysverktyg och frågor i stället för interna identifieringar och kontroller. Dessa verktyg kan erbjuda många värden för proaktiva jaktaktiviteter, men för att få en avisering av hög kvalitet med dessa verktyg krävs djupgående expertis och tid som kan användas bättre på jakt och andra aktiviteter.
För att komplettera den breda synligheten för en centraliserad SIEM (som Microsoft Sentinel, Splunk eller QRadar) bör du använda inbyggda identifieringar och kontroller på följande sätt:
Organisationer som använder Azure bör använda Microsoft Defender för molnet för aviseringsgenerering på Azure-plattformen.
Organisationer bör använda inbyggda loggningsfunktioner som Azure Monitor och AWS CloudTrail för att hämta loggar till en central vy.
Organisationer som använder Azure bör använda NSG-funktioner (Network Security Group) för att få insyn i nätverksaktiviteter på Azure-plattformen.
Undersökningsmetoder bör använda inbyggda verktyg med djup kunskap om tillgångstypen, till exempel en lösning för slutpunktsidentifiering och svar (Identifiering och åtgärd på slutpunkt), identitetsverktyg och Microsoft Sentinel.
Prioritera avisering och loggintegrering
Se till att du integrerar kritiska säkerhetsaviseringar och loggar in i SIEM utan att introducera en stor mängd data med lågt värde.
Om du introducerar för mycket data med lågt värde kan du öka SIEM-kostnaden, öka bruset och falska positiva resultat och sänka prestandan.
De data som du samlar in bör fokusera på att stödja en eller flera av dessa åtgärder:
Aviseringar (identifieringar från befintliga verktyg eller data som krävs för att generera anpassade aviseringar)
Undersökning av en incident (till exempel krävs för vanliga frågor)
Proaktiva jaktaktiviteter
Genom att integrera mer data kan du utöka aviseringar med mer kontext som möjliggör snabba svar och åtgärder (filtrering av falska positiva identifieringar, ökning av sanna positiva identifieringar och så vidare), men insamling är inte identifiering. Om du inte har en rimlig förväntan på att data ska ge värde (till exempel en stor mängd brandväggsnekande händelser) kan du nedprioritera integreringen av dessa händelser.