Virtuele branden Bestrijden: bent u klaar voor een incident?

Waarom het plannen van een worst case scenario uw bedrijf verder zal helpen

Incidentrespons wordt steeds belangrijker in een tijd waarin datalekken en downtime de nachtmerrie van veel bedrijven zijn. Toch is incidentrespons vaak niet zo efficiënt of effectief ingericht als zou moeten. In dit artikel werpen we een licht op de voordelen van een goede incidentresponsstrategie, en geven we enkele tips om u te helpen beginnen.

Bij het denken over incidentrespons moet u per definitie nadenken over wat te doen als er slechte dingen gebeuren. Dit is ongemakkelijk en voelt pessimistisch aan. Vooral kleinere bedrijven houden ervan om optimistisch te zijn en klampen zich vast aan mantra’s als ‘het komt wel goed’ en ‘wij zijn toch geen interessant doel’. In securitykringen is er een belangrijk gezegde: er zijn twee soorten bedrijven: degene die weten dat ze zijn aangevallen en degene die dat niet weten. Met andere woorden: alle bedrijven krijgen vroeg of laat te maken met beveiligingsincidenten. Het is dan ook beter om ervoor te zorgen dat je daar als bedrijf op voorbereid bent. Sommige gebeurtenissen die veel aandacht in de media hebben gekregen, zoals de WannaCry-infectiegolf, zijn een belangrijke herinnering aan dit feit.

In dit stuk zullen we enkele strategische overwegingen over incidentrespons en -bereidheid bespreken.

In de praktijk lijkt de verantwoordelijke voor incidentrespons op een brandweerman die naar een brand wordt geroepen. Die wordt soms gestuurd met minimale informatie ("Er is een brand op adres X.") en wordt verwacht dat in recordtijd op te treden, waardoor er weinig schade aan eigendommen wordt veroorzaakt en er geen slachtoffers vallen. Om dit doel te bereiken, is informatie veruit het belangrijkste om als brandweerman te hebben. Ieder kind leert dat je bij het bellen van de brandweer de volgende vragen aan een nooddienstverlener moeten proberen te beantwoorden:

• "Wat is er gebeurd?"
• "Waar is het gebeurd?" (Op dit moment is de brandweer al onderweg)
• "Wat brandt?" (Dat wil zeggen hout, chemicaliën, kunststoffen, metalen, enz.)
• "Hoeveel gewonden zijn er?"
• "Zijn er nog mensen in het gebouw?"
• "Wie doet de melding?" (Dit is eigenlijk de minst kritische informatie voor de eerste responders)

Risico's en scenario's identificeren

Een cruciale vraag die moet worden beantwoord is: wat ziet de organisatie als een ​​risico en op welke incidenten probeert de organisatie zich dus voor te bereiden? Welke scenario's zou een hypothetische aanvaller (intern of extern) in staat stellen om schade aan de organisatie aan te brengen?

Als u alle mogelijke risico's tegelijkertijd aanpakt, zal het hele project zo schrikwekkend groot lijken dat het waarschijnlijk slechts gedeeltelijk zal worden uitgevoerd, of zelfs volledig op de lange baan zal worden geschoven vanwege de kosten die mogelijk de pan uit zullen rijzen. Om een ​​ietwat extreem voorbeeld te kiezen, als een bedrijf ervoor zou willen zorgen dat zijn datacenter veilig is voor alle door de mens veroorzaakte en natuurlijke rampen en het tegelijkertijd wil beschermen tegen eventuele interne dreigingen, spreken we niet alleen over verschillende projecten die op zichzelf alleen al uitdagend zijn, maar in combinatie met elkaar worden ze zo complex dat de organisatie er niet tegen opgewassen is. De nadruk zou dan ook moeten liggen op die risico's die een onmiddellijke bedreiging vormen voor de gegevens van een organisatie en de mogelijkheid om producten of diensten te leveren. Toegegeven, een aardbeving of meteoriet kan dit effect ook hebben. Afhankelijk van het gebied waar u zich bevindt, kunnen historische gegevens echter aantonen dat de kans daarop verwaarloosbaar is, in vergelijking met de waarschijnlijkheid dat u te maken krijgt met een datalek of een ander beveiligingsincident.

In het algemeen geldt dat we voorbij het punt zijn dat hackers een aanval plegen uit pure nieuwsgierigheid. Het doel van een aanval is meestal het behalen van een strategisch, tactisch of financieel voordeel. De vraag om te stellen is 'cui bono?' - wie profiteert ervan als uw organisatie op een specifieke manier wordt aangevallen?

Kosten en baten

Hoewel het huren van een externe expert kan lijken op een aanzienlijke investering met een onduidelijk rendement, bespaart het de organisatie veel geld op de lange termijn. Het is veel goedkoper om vooraf een consultant in te huren om informatie te consolideren en een plan te formuleren dan deze stappen te moeten zetten wanneer je je middenin incident te bevindt. Afhankelijk van uw locatie zijn er cijfers beschikbaar die de gemiddelde financiële schade weergeven die een organisatie lijdt in de nasleep van een IT-incident. In Duitsland bedraagt ​​de gemiddelde schade per geval in de MKB-sector 41.000 euro. Met dit in het achterhoofd kan de kans om financiering te krijgen voor een incidentgereedheidsproject aanzienlijk worden verhoogd. Om schade te voorkomen is het verstandig om te werken met experts, ook al kosten deze geld. Immers; de beste persoon om te vragen wat voor soort informatie een incidentresponder nodig heeft in een ‘worst case scenario’, is een incidentresponder. Ook kunnen zij mogelijke problemen in de netwerkinstelling detecteren en advies geven om deze te beperken. Tijdens dit proces moeten alle betrokkenen samenkomen en besluiten nemen.

Een starre directie doet er verstandig aan om het concept van een ROI (Return on Investment) los te laten als het gaat om investeringen in beveiliging. In veel opzichten is IT in het algemeen en IT-beveiliging in het bijzonder nog steeds hoofdzakelijk een kostencentrum en dragen geen bijdrage aan de winstgevendheid van een organisatie. De vraag die de directie zichzelf stelt moet dan ook niet zijn: "Hoeveel winst halen we uit die investering?", Maar "Hoeveel winst verliezen we in het geval van een incident als we die investeringen niet doen?". Een toenemend aantal organisaties heeft aan den lijve ondervonden dat zij zonder adequate informatiebeveiliging niet in staat zijn om zaken te doen wanneer een incident zich voordoet. Als het gaat om een ​​gebrek aan informatiebeveiliging, kunnen effecten wel of niet catastrofaal zijn; voorafgaande ramingen zijn moeilijk te maken.

Een ander gevaar dat op de loer ligt op dit gebied is de toenemende verplichting om te voldoen aan bepaalde wettelijke en nalevingsnormen die ook een veiligheidscomponent hebben. Nalevingsrichtlijnen kunnen een beveiligingsbasis bieden, maar ze zijn zelden afdoende. Organisaties komen door compliancy in de verleiding om het minimale te doen dat ze nodig hebben om aan de regelgeving te voldoen, maar niet meer. Datalekken zijn in nagenoeg alle gevallen nog steeds mogelijk, zelfs al wordt aan alle standaarden voldaan.

Tijd voor de controle

De voorbereiding op veiligheidsincidenten is een goede gelegenheid om de netwerkinfrastructuur en enkele van de processen die daarmee verband houden grondig te onderzoeken. Vooral netwerken die over de jaren zijn gegroeid, kunnen zwakke plekke bevatten. Dingen die mogelijk zouden zijn bedoeld als een tijdelijke oplossing voor een probleem dat op een gegeven moment plaatsvond, kunnen nu als vaste inrichting gebruikt worden. Uw worst case scenario heeft hier zelfs geen externe factor nodig om een ​​incident te veroorzaken. Een snelle "hack" kan zich gemakkelijk ontwikkelen tot een volledige ramp. Stelt u zich voor dat een dergelijke oplossing is geïmplementeerd door iemand die het bedrijf al lang geleden heeft verlaten. Het systeem crasht, zonder dat iemand weet waarom. En later blijkt dat een voormalig beheerder een cronjob of script heeft aangemaakt die de service automatisch opnieuw laat herstarten als die crasht. Dus het onderliggende probleem is nooit opgelost, maar om de activiteiten door te laten gaan, is er een snelle oplossing ingebouwd, wat natuurlijk logisch is. En dan houdt de machine waarop dat script draait ermee op. Maak gebruik van de mogelijkheid om uw systeem van deze oude "quick and dirty" fixes te ontdoen. Documentatie is essentieel - zorg ervoor dat -als u niet gemakkelijk van oude hacks kunt ontsnappen- deze in elk geval goed zijn gedocumenteerd. Als u testomgevingen of databases heeft die naar buiten gericht zijn, controleer of ze goed beveiligd zijn. Het zou niet de eerste keer zijn dat onbevoegde personen toegang krijgen tot gegevens in onbeveiligde databases. Een fout hierin kan echt het einde van een bedrijf betekenen. Als de controle toont dat kritieke diensten of vertrouwelijke informatie wordt bewaard op hardware die niet-redundant, webgericht of anderszins in onnodige blootgestelde positie is, overweeg dan om deze componenten te verplaatsen en te consolideren.

Verkrijgen van externe bronnen

Een andere vraag die moet worden beantwoord, betreft de outsourcing van onderdelen van het incidentrespons. Het inhuren van een team van externe specialisten om dit aspect aan te pakken, is zinvol, vooral in kleinere bedrijven. Grotere bedrijven daarentegen zouden hun eigen toegewijde IR-team moeten hebben vanwege de complexiteit van de omgeving en de eis voor zeer korte reactietijden. Toch is het niet onverstandig om daarnaast de mogelijkheid te hebben om extra externe manschappen te kunnen inroepen.

Het toestemming krijgen voor het inschakelen van externe hulp is in sommige organisaties een delicaat onderwerp. Het kan interne IT-personeelsleden het idee geven dat de gehele IT zal worden uitbesteed. Er kan dan ook een bepaalde mate van weerstand tegen het plan optreden. Dit project gaat echter niet over een specifiek persoon of diens individuele prestatie in het verleden - het gaat erom om het bedrijf te laten voortbestaan na het worst case scenario. Incidentrespons is immers niet een dagelijkse vereiste. Het beste incidentresponsplan is nog steeds datgene dat nooit in actie hoeft te worden gebracht. Toch, als personeelsleden bang zijn voor negatieve reacties op foutjes of gemakkelijke fixes die zij in het verleden hebben gemaakt, kunnen ze in de verleiding komen om een ​​gefilterde versie van de realiteit te verschaffen. Dit zou later voor grote problemen kunnen zorgen.

De eerste stap in het hele proces van het opzetten van een duurzame mate van incidentenbereidheid zal je geen arm kosten: praat met mensen en kom in contact met deskundigen die je meer inzichten kunnen bieden dan je momenteel hebt.

Pijnpunten & achteruitgang

Tijdens dit initiële proces is het nodig om een aantal factoren te definiëren, waaronder de Maximaal Toelaatbare Downtime (MTD) van een bepaalde dienst. Dit concept, afkomstig uit het risicomanagement, vertegenwoordigt cijfers die een directe invloed hebben op een incidentresponsstrategie. In een medische faciliteit is de maximaal toelaatbare downtime voor het lab bijna nul, omdat de afdelingen zoals het traumacenter meestal in een fractie van minuten bepaalde laboratoriumresultaten nodig hebben. Daarom heeft het lab voorrang tijdens een incidentreactie. Labs die de afdeling oncologie bedienen, zouden daarentegen een paar dagen vertraging kunnen tolereren. MTD kan ook worden gedefinieerd door andere factoren, b.v. Hoe lang kan een bepaalde dienst niet werken voordat het de verkoopcijfers beïnvloedt? Dit hangt weer af van het bedrijf; een niet werkenede webshop kan beperkte schade aanrichten als het een paar uur op een dinsdagavond in juli gebeurt, maar een veel grotere schade midden in het kerstseizoen. Met dit in gedachten kan een strategie worden geformuleerd. Een organisatie moet ook een overzicht krijgen van belangrijke activa en de infrastructuur van de organisatie. Deze initiële planningsfase bestaat waarschijnlijk uit veel vraagtekens. Sommige vragen kunnen ongemakkelijk lijken omdat het de indruk kan geven dat de IT nalatig is geweest, hoewel dit in werkelijkheid misschien absoluut niet zo is. Echter, zonder te weten welke diensten en welke machines als kritiek worden beschouwd en dus welke onderdelen van het netwerk speciale aandacht behoeven, wordt het plan onnuttig en onuitvoerbaar.

Een ransomware-infectie resulteert vaak in een mate van chaos en verwarring tijdens de dagelijkse werkzaamheden. In veel moderne omgevingen bestaan ​​er nauwelijks terugvalprocedures die niet gebaseerd zijn op computergebaseerde technologie. Sommige delen van een organisatie hebben de mogelijkheid om terug te gaan naar het gebruik van pen en papier om hun meest essentiële diensten te laten draaien, zij het in een lager tempo. Dit overkwam een 911 verzendcentrum in Ohio dat zijn systemen door een ransomware-infectie niet kon gebruiken - dit wierp de operaties ongeveer 25 jaar terug in de tijd. Er zijn gevallen waarin pen en papier een oplossing zijn, in andere gevallen niet (bijv. een distributiecentrum met chaotische opslag). Het ontwikkelen van terugvalstrategieën is iets dat zeker in overweging moet worden genomen bij het ontwikkelen van een incidentresponsplan.

In een notendop: hoe te beginnen

• Identificeer het type incident waarop de organisatie zich wil voorbereiden
• Zorg ervoor dat de directie het plan ondersteunt. Ondersteuning is meestal gemakkelijker te verkrijgen als er in het recente verleden een incident is geweest.
• Beoordeel of er bestaande beveiligingsconcepten zijn en controleer of ze kunnen worden aangepast
• Als bestaande systemen of processen in uw huidige plan kunnen worden gebruikt, kunnen deze kosten besparen. Let wel, dat "pappen en nathouden" alleen ter wille van het besparen op budget misschien niet duurzaam is op de lange termijn.
• Wees kritisch op de gegevens die u tijdens het proces ontvangt en, maak duidelijk dat het ontwikkelen van dit plan geen prestatiebeoordeling is
• Vraag offertes aan van bedrijven die zich specialiseren in Incident Response and Handling, zoals G DATA Advanced Analytics. Bouw een relatie op met die partner - dat bespaart veel tijd op de lange termijn.

Tim Berghoff is Security Evangelist bij G DATA