Beleid voor reactie op incidenten

1. Plan & overzicht

1.1 Definities

Dit document biedt richtlijnen voor medewerkers of incident responders die menen een beveiligingsincident te hebben ontdekt of daarop te reageren. Bij het reageren op een incident bepalen we eerst de blootstelling van de informatie en de bron van het beveiligingsprobleem, indien mogelijk. We communiceren terug naar de klant (en andere getroffen klanten) via e-mail of telefoon. We verstrekken periodieke updates indien nodig. Onze CEO beoordeelt alle beveiligingsgerelateerde incidenten en we coördineren met getroffen klanten via de meest geschikte middelen.

1.2 Doelstelling

Dit Beveiligingsincident Respons Plan is gedocumenteerd om een goed gedefinieerde, georganiseerde aanpak te bieden voor het omgaan met potentiële bedreigingen voor computers en gegevens, alsmede voor het nemen van passende maatregelen wanneer de bron van een inbraak of incident bij een derde partij wordt herleid tot het privénetwerk. Dit plan identificeert en beschrijft de rollen en verantwoordelijkheden van het Beveiligingsincident Respons Team.

1.3 Onze aanpak voor het omgaan met beveiligingsincidenten

Recruit CRM heeft uitgebreide beveiligingsmaatregelen om klantgegevens te beschermen en de meest betrouwbare en veilige diensten te bieden. We erkennen echter dat beveiligingsincidenten nog steeds kunnen plaatsvinden, en het is even belangrijk om effectieve methoden te hebben om deze te behandelen.

Daarom hebben we een duidelijk gedefinieerde aanpak voor het reageren op beveiligingsincidenten die onze diensten of infrastructuur beïnvloeden. Onze aanpak omvat uitgebreide logging en monitoring van onze producten en infrastructuur voor snelle detectie van potentiële incidenten, ondersteund door zorgvuldig gedefinieerde processen.

1.4 Beveiligingsincident Respons Team

Het team bestaat uit sleuteltechnische en ondersteuningsteamleden van Workforce Cloud Tech, Inc. die zijn getraind in het bieden van een snelle, effectieve en ordelijke reactie op bedreigingen zoals hackpogingen, serviceonderbrekingen, schending van persoonsgegevens en andere gebeurtenissen met ernstige gegevensbeveiligingsimplicaties.

Voor directe hulp bij een beveiligingsincident, e-mail: contact@recruitcrm.io - 24 uur per dag / 7 dagen per week

Het team is gemachtigd om de noodzakelijke stappen te ondernemen om een beveiligingsincident van computers te bevatten, te mitigeren of op te lossen. Het team is verantwoordelijk voor het onderzoeken van vermoedelijke inbraakpogingen of andere beveiligingsincidenten op een tijdige, kosteneffectieve manier en het rapporteren aan de bevoegde autoriteiten indien nodig.

Leden van het Beveiligingsincident Respons Team

Chief Executive Office
Head of Engineering
Head of Platform
Senior Developers/Testers

1.5 Verantwoordelijkheden bij beveiligingsincidenten

Net als elke clouddienstverlener doen we ons best om te zorgen dat klanten geen uitval of beveiligingsincident ervaren. We begrijpen echter dat een beveiligingsincident waarschijnlijk kan plaatsvinden. Het is belangrijk voor ons dat klanten begrijpen hoe ze passen in ons proces en welke verantwoordelijkheden zij hebben tijdens een incident.

Rollen

Elk incident wordt beheerd door een van onze ervaren senior engineers (SE). SE's nemen typisch beveiligingsgerelateerde beslissingen, houden toezicht op het reactieproces en wijzen taken intern toe. Ze worden ondersteund door incidentanalisten en andere rollen. In gevallen met impact over meerdere locaties worden vaak twee SE's toegewezen om continue verantwoordelijkheid te waarborgen.

Verantwoordelijkheden

Verantwoordelijk - De partij die het werk uitvoert om de taak te volbrengen.
Accountable - De partij die uiteindelijk verantwoordelijk is voor de correcte en grondige voltooiing van de activiteit.
Geraadpleegd - De partij wiens mening wordt gevraagd en met wie tweewegscommunicatie plaatsvindt.
Geïnformeerd - De partij die op de hoogte wordt gehouden van de voortgang, met eenrichtingscommunicatie.

2. Fasen van reactie op incidenten

Er zijn vele soorten computerincidenten die activering van het team kunnen vereisen. Enkele voorbeelden:

Schending van persoonsgegevens
Denial of service / Gedistribueerde denial of service
Firewall-schending / Virusuitbraak

Definitie van een beveiligingsschending

Een beveiligingsschending wordt gedefinieerd als de onbevoegde verkrijging van gegevens die de beveiliging, vertrouwelijkheid of integriteit van door de klant beheerde persoonsgegevens compromitteert. Goedgelovige verkrijging door een werknemer of agent van de leverancier voor zakelijke doeleinden is geen schending, mits de gegevens niet worden gebruikt of onderworpen zijn aan verdere onbevoegde openbaarmaking.

1. Identificatie

In deze fase voeren we controles uit om te bepalen of de gerapporteerde afwijking een incident is. Indien bevestigd, verzamelen we logboeken, communiceren met het betreffende team en nemen corrigerende maatregelen. Alle meldingen worden geclassificeerd als ernst 1/2/3 risico.

1.1 Ernst 1

Definitie: De functionaliteit van de softwaredienst is aangetast of sommige gebruikers hebben geen toegang tot bepaalde functionaliteiten.
Voorbeeld: Onbevoegde systeemtoegang.

Workforce Cloud Tech, Inc. reageert uiterlijk twee (2) uur na uw melding of onze detectie. Onze senior engineers werken aan de correctie tijdens kantooruren. Indien een acceptabele workaround wordt geboden, bieden we een permanente fix uiterlijk dertig (30) dagen na uw melding.

1.2 Ernst 2

Definitie: Incidenten met potentieel monumentale impact op gebruik of functionaliteit.
Voorbeeld: Wachtwoordkraakpoging.

Workforce Cloud Tech, Inc. reageert binnen vier (4) uur tijdens uw reguliere kantooruren (of de volgende werkdag indien gemeld buiten kantooruren).

1.3 Ernst 3

Definitie: Laag impact voor gebruikers van de softwaredienst.
Voorbeeld: Firewall-scanning.

Workforce Cloud Tech reageert binnen zes (6) uur tijdens kantooruren (of de volgende werkdag).

1.4 Classificatie

Het SIRT-team kent ernst en kritikaliteit toe aan elk incident. De onderstaande matrix beschrijft de prioriteitsscore voor elke classificatie.

De onderstaande matrix beschrijft de prioriteitsscore voor elke classificatie.

Ernstniveau	Score
Informatief	0
Actie-item	1
Ongunstig evenement	2
Basisincident	3
Matig incident	4
Groot incident	5

Kritikaliteitsniveau	Score
Onbekend	1
Laag	2
Gemiddeld	3
Hoog	4
Kritisch	5

2. Inperking

Zodra een potentieel incident is gemeld, voert het team het eerste onderzoek uit. De volgende checklist faciliteert de classificatie:

Verzameling en beoordeling van logbestanden
Beoordeling van geïnstalleerde of lopende bevoegde programma's
Inspectie op manipulatie van systeembestanden
Rapporten van netwerkmonitoringsprogramma's
Detectie van onbevoegde services op systemen
Beoordeling van systeem- en netwerkconfiguraties
Detectie van ongebruikelijke bestanden
Onderzoek van andere hosts

2.1 Notitie over afsluiten

Bij het reageren op een gemeld incident kan het verstandig zijn om alle of sommige systemen af te sluiten om een aanval in realtime te stoppen en/of potentieel forensisch bewijsmateriaal te bewaren.

3. Declaratie

Zodra de SIRT-coördinator een incident vaststelt, declareert deze het incident en roept het SIRT-plan in. Vervolgens bepaalt hij welke rollen noodzakelijk zijn voor het team en wijst deze toe.

4. Uitroeiing

Het incident wordt altijd gemeld aan het betreffende team met voldoende documentatie. Na beoordeling van de documentatie en code ondergaat het uitroeiingsproces talrijke tests om te zorgen dat het incident niet meer in het systeem zit en in de toekomst niet opnieuw zal optreden.

5. Escalatie

Op elk moment tijdens het proces: als een lid van het SIRT binnen 30 minuten na een contactpoging niet bereikbaar is, wordt het potentieel incident geëscaleerd naar de senior SIRT-coördinator. Indien niet bereikbaar, gaat de escalatie verder tot de CEO. De SIRT-coördinator bepaalt ook of externe partijen op de hoogte moeten worden gesteld.

6. Herstel

Na een beveiligingsincident begint de remedia- en herstelfase. Systemen worden gereinigd van kwaadaardige of andere illegale content. Afhankelijk van de organisatie en het incidenttype worden de volgende gebieden overwogen:

Patchen en verharden van systeemimages
Herimageren van systemen
Implementatie van wachtwoordwijzigingen
Verbetering van monitoring en verdediging

7. Geleerde lessen

Na elk incident voeren we uitgebreide documentatie uit. De lessen worden besproken in evaluatievergaderingen en er worden bepaalde standaarden vastgesteld. Dit helpt de organisatie om herhaalde incidenten te voorkomen en de systemen te beveiligen tegen incidenten uit het verleden.