Hoe u een incident response plan opstelt rond het SANS-incident response proces, voorbeelden om u op weg te helpen, en een kijkje in de automatisering van incident response.
Heeft u een incident response-oplossing nodig? Klik hier voor een incident response demo.
In deze post leert u:
- Wat is een Incident Response Plan en waarom heeft u er een nodig?
- De Incident Response Cyclus
- Waarom is een Incident Response Plan belangrijk?
- Incident Response Plan Vs a Disaster Recovery Plan
- The Six Steps of Incident Response
- Incident Response Plan Template
- Incident Response Plan Examples
- The Next Generation of Incident Response
Wat is een Incident Response Plan en waarom heb je er een nodig?
Een incident response plan is een verzameling tools en procedures die uw beveiligingsteam kan gebruiken om cyberbeveiligingsbedreigingen te identificeren, elimineren en herstellen. Het is ontworpen om uw team te helpen snel en uniform te reageren op elk type externe dreiging.
Responsplannen voor incidenten zorgen ervoor dat de reacties zo effectief mogelijk zijn. Deze plannen zijn nodig om de schade als gevolg van bedreigingen tot een minimum te beperken, met inbegrip van gegevensverlies, misbruik van middelen en het verlies van vertrouwen van klanten.
Een incident response plan vormt de basis van uw incident response cyclus:
Figuur 1: De elementen van een incident response cyclus
Een incident response plan is niet compleet zonder een team dat het plan kan uitvoeren – het Computer Security Incident Response Team (CSIRT). Een incident response team is een groep mensen – hetzij IT-personeel met enige beveiligingsopleiding, hetzij full-time beveiligingspersoneel in grotere organisaties – die informatie van een incident verzamelt, analyseert en ernaar handelt.
Zij zijn het centrale punt van het incident, en zijn verantwoordelijk voor de communicatie met andere belanghebbenden binnen de organisatie, en externe partijen zoals juridische adviseurs, pers, rechtshandhaving, getroffen klanten, enzovoort.
Waarom is een Incident Response Plan belangrijk?
Uit de 2017 Cost of Cyber Crime Study van het Ponemon Institute blijkt dat de gemiddelde organisatie 11,7 miljoen dollar per jaar verliest als gevolg van de schade van cyber qattacks. Een effectief reactieproces kan handelen om deze kosten aanzienlijk te verlagen.
Incident response plannen zijn ook belangrijk om uw gegevens te beschermen. Het beschermen van datamiddelen tijdens het incident response proces omvat veilige back-ups, het gebruik van logs en beveiligingswaarschuwingen om kwaadaardige activiteiten te detecteren, goed identiteits- en toegangsbeheer om insider bedreigingen te voorkomen, en veel aandacht voor patch management.
Ten slotte beschermt incident response planning de reputatie van uw bedrijf. IDC ontdekte dat 80% van de consumenten hun zaken elders zouden brengen als ze direct werden getroffen door een datalek. Als een inbreuk op de beveiliging niet snel wordt aangepakt, loopt het bedrijf het risico zaken te verliezen. Het vertrouwen van investeerders en aandeelhouders kan drastisch afnemen na een openbaar gemaakt datalek.
Een incident response plan (IRP) helpt u zich voor te bereiden op beveiligingsincidenten en deze idealiter te voorkomen. De reacties die een IRP voorschrijft, kunnen ook een aantal minder voor de hand liggende positieve effecten op uw organisatie hebben, waaronder:
- Gegevensbescherming – gegevens- en systeembescherming vormen de kern van een IRP. Bescherming wordt bereikt door het beveiligen van back-ups, het waarborgen van een toereikend identiteits- en toegangsbeheer, en het tijdig patchen van kwetsbaarheden. Deze maatregelen worden ondersteund door een snelle reactie op waarschuwingen en een zorgvuldige analyse van logboeken en eventgegevens.
- Versterkt reputatie-effectieve incidentrespons toont de toewijding van een merk aan beveiliging en privacy. Aanvallen die resulteren in gegevensverlies kunnen ertoe leiden dat klanten twijfelen aan de competentie van een organisatie, wat ertoe kan leiden dat het merk wordt verlaten. Ook aandeelhouders en investeerders kunnen een bedrijf dat het slachtoffer is geworden van een inbreuk in de steek laten. IRP kan deze verliezen voorkomen of minimaliseren.
- Vermindert de kosten – inbreuken zijn duur, vanwege boetes van de toezichthouder, compensatie van klanten, of gewoon de kosten van onderzoek en het herstellen van systemen. Volgens een onderzoek van IBM uit 2019 bedragen de gemiddelde kosten van een inbreuk bijna 4 miljoen dollar. IRP’s kunnen helpen uw risico op een inbreuk te verkleinen en de schade van aanvallen te beperken, waardoor uw kosten beperkt blijven.
Wat is de relatie tussen een Incident Response Plan en een Disaster Recovery Plan?
Een incident response plan moet worden aangevuld met een disaster recovery plan. Dit laatste schrijft voor hoe een organisatie omgaat met een catastrofale gebeurtenis zoals een natuurramp of onbedoeld verlies van gegevens. Terwijl een incident response plan zich richt op het identificeren van een security event en het tot een einde brengen ervan, is disaster recovery gericht op het weer online brengen van systemen, met inachtneming van een Recovery Time Objective (RTO).
Key Considerations for Incident Response Planning
Een incident response plan moet de volgende elementen bevatten om effectief te zijn:
- Steun van het senior management – steun van het management stelt u in staat de meest gekwalificeerde leden voor uw response team te werven en processen en informatiestromen te creëren die u helpen een incident effectief te beheersen.
- Consistent testen – een incident response plan is niet veel waard als het alleen maar op papier staat, het moet worden getest. Het uitvoeren van een geplande (of nog beter, ongeplande) beveiligingsoefening, het doorlopen van het plan en het identificeren van zwakke plekken zal een lange weg gaan om te valideren dat het team klaar is voor een echt incident.
- Balans tussen detail en flexibiliteit-het plan moet specifieke, actiegerichte stappen bevatten die het team snel kan volgen wanneer zich een incident voordoet. Tegelijkertijd leidt het creëren van rigide processen tot complexiteit en een onvermogen om te gaan met onverwachte scenario’s. Maak een gedetailleerd plan, maar zorg voor flexibiliteit om een breed scala aan incidenten te ondersteunen. Het plan regelmatig bijwerken kan ook helpen bij de flexibiliteit – door het plan ongeveer elke zes maanden te herzien, kunt u rekening houden met nieuwe soorten beveiligingsproblemen en aanvallen die van invloed zijn op uw branche.
- Verduidelijk communicatiekanalen – het plan moet duidelijk maken met wie het incidententeam moet communiceren, via welke communicatiekanalen, en welke informatie moet worden overgebracht. Dit is een cruciaal en soms over het hoofd gezien onderdeel van het reactieproces. Er moeten bijvoorbeeld duidelijke richtlijnen zijn over welke mate van detail moet worden gecommuniceerd met het IT-management, het senior management, de betrokken afdelingen, de betrokken klanten en de pers.
- Ken uw stakeholders-wie zijn de belangrijkste rollen binnen de organisatie die zich zorgen moeten maken en betrokken moeten zijn bij een beveiligingsincident? Deze kunnen veranderen, afhankelijk van het type incident en de beoogde organisatorische middelen. Stakeholders zijn bijvoorbeeld afdelingsmanagers, senior management, partners, klanten en juridische zaken.
- Houd het plan eenvoudig-een bekend managementprincipe, “Keep it Simple Stupid” (KISS), moet ook worden toegepast op responsplannen. Een ingewikkeld plan, zelfs als het zeer goed doordacht is, zal waarschijnlijk niet nauwkeurig worden gevolgd in real time. Beperk details, stappen en procedures tot een absoluut minimum, zodat het team ze kan verwerken en toepassen op het incident als ze de “mist van de oorlog” ingaan.
The SANS Institute’s 6 Steps of Incident Response
Volgens het SANS Institute’s Incident Handlers Handbook, zijn er zes stappen die moeten worden genomen door het Incident Response Team, om effectief om te gaan met beveiligingsincidenten. Uw responsplan moet elk van deze stappen behandelen en voorzien van een gestructureerd proces.
1. Voorbereiding
In de voorbereidingsfase moet u het onderliggende beveiligingsbeleid dat de basis vormt voor uw incident response plan herzien en codificeren. Voer een risicobeoordeling uit en prioriteer beveiligingskwesties, identificeer de meest gevoelige bedrijfsmiddelen en, in het verlengde daarvan, de kritieke beveiligingsincidenten waarop het team zich moet concentreren. Maak een communicatieplan, en stel documentatie op waarin de rollen, verantwoordelijkheden en processen duidelijk en beknopt worden beschreven.
Planning is niet genoeg-u moet ook leden voor het CIRT werven, hen trainen, ervoor zorgen dat ze toegang hebben tot alle relevante systemen, en de tools en technologieën die ze nodig hebben om incidenten te identificeren en erop te reageren.
2. Identificatie
Het team moet in staat zijn om effectief afwijkingen van de normale werking in organisatorische systemen te detecteren en te identificeren of deze afwijkingen daadwerkelijke beveiligingsincidenten vertegenwoordigen.
Wanneer een potentieel incident wordt ontdekt, moet het team onmiddellijk aanvullend bewijs verzamelen, beslissen over het type en de ernst van het incident, en alles wat ze doen documenteren. De documentatie moet antwoord geven op de vragen “Wie, Wat, Waar, Waarom en Hoe”, zodat de aanvallers in een later stadium voor de rechter kunnen worden gebracht.
3. Inperking
Als het team een beveiligingsincident identificeert, is het onmiddellijke doel het incident in te dammen en te voorkomen dat verdere schade optreedt. Dit houdt in:
- Beheersing op korte termijn- dit kan zo eenvoudig zijn als het isoleren van een netwerksegment dat wordt aangevallen of het uitschakelen van productieservers die zijn gehackt en het verkeer omleiden naar back-upservers.
- Beheersing op lange termijn-het toepassen van tijdelijke fixes op getroffen systemen zodat ze in productie kunnen worden gebruikt, terwijl schone systemen worden herbouwd, ter voorbereiding om ze online te brengen in de herstelfase.
4. Uitroeiing
Het team moet de hoofdoorzaak van de aanval identificeren, malware of bedreigingen verwijderen, en soortgelijke aanvallen in de toekomst voorkomen. Als bijvoorbeeld een zwak authenticatiemechanisme het startpunt van de aanval was, moet dit worden vervangen door sterke authenticatie; als een kwetsbaarheid is misbruikt, moet deze onmiddellijk worden gepatcht.
5. Herstel
Het team brengt getroffen productiesystemen voorzichtig weer online, om te voorkomen dat er nog een incident plaatsvindt. Belangrijke beslissingen in deze fase zijn vanaf welk tijdstip en welke datum de activiteiten worden hersteld, hoe wordt getest en geverifieerd dat de getroffen systemen weer normaal functioneren, en hoe lang de systemen worden gemonitord om er zeker van te zijn dat de activiteiten weer normaal verlopen.
6. Lessons Learned
Deze fase moet niet later dan twee weken na het einde van het incident worden uitgevoerd, om er zeker van te zijn dat de informatie vers in het geheugen van het team zit. Het doel van deze fase is om documentatie aan te vullen die niet kon worden voorbereid tijdens het response proces en het incident verder te onderzoeken om de volledige omvang ervan te identificeren, hoe het werd ingedamd en uitgeroeid, wat er werd gedaan om de aangevallen systemen te herstellen, gebieden waar het response team effectief was, en gebieden die verbetering behoeven.
Sjabloon voor incidentresponsplan
Hieronder vindt u vier gedetailleerde sjablonen die u kunt gebruiken als start van uw incidentresponsplanning:
Het sjabloon voor het incidentresponsplan vanTechTarget (14 pagina’s) bevat de reikwijdte, planningscenario’s en hersteldoelstellingen; een logische volgorde van gebeurtenissen voor incidentrespons en teamrollen en -verantwoordelijkheden; procedures voor kennisgeving, escalatie en aangifte; en checklists voor incidentrespons.
>> Download de sjabloon
De sjabloon voor incidentenrespons vanThycotic (19 pagina’s) bevat rollen, verantwoordelijkheden en contactinformatie, classificatie van bedreigingen, acties die moeten worden ondernomen tijdens de incidentenrespons, branchespecifieke en geografisch afhankelijke regelgeving, en een responsproces, evenals instructies voor het aanpassen van de sjabloon aan uw specifieke behoeften.
>> Download de sjabloon (registratie vereist)
Sysnets responsplan voor beveiligingsincidenten (11 pagina’s) bevat informatie over het herkennen van een incident, rollen en verantwoordelijkheden, externe contactpersonen, de eerste responsstappen en instructies voor het reageren op verschillende veelvoorkomende incidenttypen, zoals malware en ongeoorloofde draadloze toegang.
>> Download de sjabloon (registratie vereist)
Het incidentbestrijdingsplan van het California Government Department of Technology (4 pagina’s) bevat een checklist van 17 stappen die de leden van het incidententeam moeten volgen, met verwijzingen naar meer gedetailleerde procedures voor specifieke soorten incidenten (die u zelf moet opstellen).
>> Download de sjabloon
Incident Response Plan Examples
Bij het ontwikkelen van een incidentenplan is het waardevol om actuele voorbeelden te bekijken van plannen die door andere organisaties zijn gemaakt. Sommige voorbeelden zullen niet van toepassing zijn op de incidentscenario’s in uw branche, maar kunnen u wel inspiratie bieden.
Zie voorbeelden van plannen van de volgende organisaties:
- Carnegie Mellon University-omvat definities, rollen en verantwoordelijkheden, methodologie, fasen van de incidentrespons, richtlijnen voor insiderbedreigingen en interactie met wetshandhaving, en documentatie.
- Tulane University – inclusief toepassingsgebied, rollen en verantwoordelijkheden, definities van incidenten, escalatieniveaus en responsfasen per kritisch niveau.
- Write State University – inclusief toepassingsgebied, responsstappen, gebruik van beveiligingstools en een checklist voor inbraken.
De volgende generatie van incidentrespons: Security Orchestration and Automation (SOAR)
Er is geen vervanging voor het opstellen van een incident response plan en het toewijzen van toegewijde personen die verantwoordelijk zijn voor dit plan. Maar om de respons op incidenten effectiever te maken en het mogelijk te maken meer beveiligingsincidenten aan te pakken, heeft zich een nieuwe categorie hulpmiddelen ontwikkeld die helpt de respons op beveiligingsincidenten te automatiseren.
Security Orchestration and Automation (SOAR) tools kunnen:
- Integreren met andere beveiligingstools en deze orkestreren om een complexe reactie op een aanval mogelijk te maken
- Automatiseren van reactieprocedures in meerdere stappen met behulp van beveiligingsplaybooks
- Dossierbeheer ondersteunen door alle informatie met betrekking tot een specifiek beveiligingsincident vast te leggen, een volledige tijdlijn van de gebeurtenis te creëren, en analisten te helpen samenwerken en gegevens en inzichten aan het incident toe te voegen
Om een voorbeeld te zien van een geïntegreerde beveiligingsoplossing die zowel SOAR als User Entity Behavioral Analytics (UEBA) en Security Information and Event Management (SIEM) mogelijkheden bevat, zie Exabeam’s Incident Responder.
Wilt u meer weten over Incident Response?
Kijk dan eens naar deze artikelen:
- De drie elementen van Incident Response: Plan, Team, en Tools
- De Complete Gids voor CSIRT Organisatie: How to Build an Incident Response Team
- 10 Best Practices for Creating an Effective Computer Security Incident Response Team (CSIRT)
- Hoe implementeer je snel een effectief Incident Response Policy
- IT Security: Wat u moet weten
- Stappenplan voor incidentenbestrijding: 6 tips voor het reageren op beveiligingsincidenten
- Beat Cyber Threats with Security Automation
- IPS Security: How Active Security Saves Time and Stops Attacks in their Tracks
Heeft u een incident response oplossing nodig? Klik hier voor een incident response demo.