Heading

Op zoek naar het Campus Incident Response Plan? Ga dan naar Informatie Beveiligings Documenten. De onderstaande Incident Response Planning Guideline heeft betrekking op systemen en applicaties die moeten voldoen aan het Campus MSSEI beleid.

UC Berkeley beveiligingsbeleid stelt naleving van de Minimum Beveiligingsstandaard voor Elektronische Informatie verplicht voor apparaten die onder de richtlijn vallende gegevens verwerken. De onderstaande aanbevelingen zijn bedoeld als optionele leidraad voor de vereisten op het gebied van incidentenrespons.

Eis

Elke systeembeheerder moet ten minste jaarlijks een incidentenresponsplan op systeemniveau ontwikkelen en herzien dat het volgende bevat:

• Namen en contactgegevens voor het lokale incidentenresponsteam, waaronder:
  • Contactpersoon voor de beveiliging en alternatieve contactpersoon of contactpersonen die beschikken over systeembeheerkwalificaties, technische kennis van het systeem, en kennis van de locatie van het incidentenresponsplan.
  • Een lokale autoriteit/besluitvormer voor het systeem die de zakelijke gevolgen van het systeem en de onbeschikbaarheid ervan begrijpt.

Systeemdetails, of verwijzing naar de locatie van dergelijke informatie, met inbegrip van:

• Data Flow Diagrammen
• Netwerk Diagrammen
• Systeem hardware inventaris (zoals vereist door de Jaarlijkse Registratie controle)
• Logging informatie (zoals vereist door de Audit Logging controle)

Procedures voor het melden en afhandelen van een vermoedelijk incident, gedefinieerd per rol: Sys Admin, Bulk Access User, Eindgebruiker, bijv.

• Wie te contacteren
• Hoe NIET te knoeien met potentieel bewijsmateriaal (d.w.z., geen forensische pogingen te ondernemen zonder daartoe geautoriseerd te zijn)

Beschrijving van het risico

Als gebruikers en systeembeheerders niet op de hoogte zijn van de incident response procedures, zal de reactie worden vertraagd en kan bewijsmateriaal worden beschadigd of verloren gaan, waardoor de potentiële impact van een incident sterk toeneemt.

Aanbevelingen

Om ervoor te zorgen dat informatiebeveiligingsgebeurtenissen en zwakke plekken in verband met gedekte kernsystemen zodanig worden gecommuniceerd dat tijdig corrigerende maatregelen kunnen worden genomen, moeten de procedures voor het melden en escaleren van incidenten worden gedocumenteerd in een formeel Incident Response Plan. De procedures voor de respons op incidenten kunnen in de volgende fasen worden ingedeeld:

• Opsporing – Eerste beoordeling en triage van beveiligingsincidenten op gedekte kernsystemen, waaronder escalatie naar het Informatiebeveiligingsbureau (ISO) en toekenning van een prioriteitsniveau aan incidenten.

• Analyse – Uitvoering van een gedetailleerde impactanalyse om de juiste prioriteit toe te kennen aan aanvullende responsactiviteiten die nodig zijn voor inbreuken met een grote impact. Begin met het conserveren en insluiten van bewijsmateriaal en met het eerste herstel.

• Herstel – Afhankelijk van de ernst van het incident moet de impact van het incident worden beperkt door de activiteiten voor het indammen en uitroeien van het bewijsmateriaal af te ronden en uiteindelijk het herstel te voltooien. Tijdens deze fase wordt vaak teruggegrepen naar detectie en analyse, bijvoorbeeld om te zien of er tijdens het uitroeien van een malware-incident nog meer hosts met malware zijn geïnfecteerd.

• Post-Incident – Nadat het incident naar behoren is afgehandeld, stelt u een rapport op met een gedetailleerde beschrijving van de hoofdoorzaak en de totale kosten van het incident, samen met de stappen die de organisatie moet nemen om toekomstige incidenten te voorkomen.

Alle medewerkers, contractanten en externe gebruikers van de campus moeten op de hoogte worden gesteld van de procedures voor het melden van de verschillende soorten gebeurtenissen die van invloed kunnen zijn op de beveiliging van gedekte apparaten. Zij moeten worden verplicht elk informatiebeveiligingsincident zo snel mogelijk te melden bij het aangewezen contactpunt.

Wat is een beveiligingsincident?

Een beveiligingsincident in de context van deze MSSEI-eis is een gebeurtenis die de werking van gedekte kernsystemen of

• vertrouwelijkheid of integriteit van gedekte gegevensactiva in gevaar brengt of kan brengen:
  • de werking van gedekte kernsystemen of
  • vertrouwelijkheid of integriteit van gedekte gegevensactiva

  Een beveiligingsincident kan betrekking hebben op een of meer van de volgende zaken:

  • een schending van het beleid en de normen voor computerbeveiliging van de campus
  • ongeautoriseerde toegang tot computer of gegevens
  • aanwezigheid van een kwaadaardige toepassing, zoals een virus
  • aanwezigheid van onverwachte/ongebruikelijke programma’s
  • een denial of service-conditie tegen gegevens, netwerk of computer
  • misbruik van dienst, systemen of informatie
  • fysieke of logische schade aan systemen
  • diefstal van een computer

  Componenten van een Incident Response Plan voor individuele systemen en diensten

  Bronneneigenaren en -beheerders moeten ervoor zorgen dat hun Incident Response Plan de volgende componenten bevat. Wij bieden dit TEMPLATE voor incident response plannen voor individuele systemen en diensten.

  • Namen, contactinformatie en verantwoordelijkheden van het lokale incident response team, inclusief:
    • Incident Handler: Contactpersoon beveiliging en plaatsvervanger(s) die beschikken over systeembeheerdersrechten, technische kennis van het systeem en kennis van de locatie van het incident response plan.
    • Resource Manager: Een lokale autoriteit/beslisser voor het systeem die de zakelijke impact van het systeem en de onbeschikbaarheid ervan begrijpt. De eigenaar van de bron moet de verantwoordelijkheden van de bronbeheerder op zich nemen of een campusmedewerker voor deze rol aanwijzen.
  • Systeemdetails, of een verwijzing naar de locatie van dergelijke informatie, met inbegrip van:
    • Data Flow Diagrams
    • Network Diagrams
    • System hardware inventory (as required by the Annual Registration control)
    • Logging information (as required by the Audit Logging control)
  • Procedures voor het melden en afhandelen van een vermoedelijk incident, waaronder:
    • Volledig een incident intakelapport, dat de volgende informatie moet bevatten:
      • Naam en telefoonnummer van de contactpersoon
      • IP-adres, hostnaam en fysieke locatie van het geschonden systeem
      • Naam van het gedekte systeem (zoals deze in NetReg wordt weergegeven)
      • Welke typen gedekte gegevens waren beschikbaar op/van de geschonden host?
        • Volledige naam
        • Social Security Number
        • Rijbewijsnummer of California Identification Card-nummer
        • Kredietnummer of nummer van financiële rekening (inclusief PIN of vervaldatum)
        • Bankrekeningnummer (inclusief PIN of andere toegangsinformatie)
        • Medische informatie of informatie over de ziektekostenverzekering
        • Ander
      • Voor elk bestand met persoonlijke informatie specificeren:
        • Naam van het bestand
        • Grootte van het bestand
        • Locatie van (volledig pad naar) het bestand
      • Waren de gegevens versleuteld, en zo ja, hoe?
      • Beschrijf de impact van het incident (bijv. het aantal gecompromitteerde gegevensrecords of het aantal gebruikers dat is getroffen door een niet-beschikbaar systeem)
      • Beschrijf het beveiligingsincident, met inbegrip van de tijdlijn van activiteiten, hoe het incident is ontdekt, de impact (zakelijk en technisch) van het incident, details van de getroffen mitigerende maatregelen, zoals welk data-encryptiemechanisme is gebruikt.
      • Documenteer welke actie wordt ondernomen met betrekking tot het geschonden systeem (wat is de status van het systeem nu, enz.)
    • Meld het beveiligingsincident bij ISO (e-mail [email protected]*) en voeg het intakelapport toe. Wij zullen een beveiligingsanalist toewijzen om eventuele vervolgactiviteiten in verband met incidenten te coördineren.
      • Nadat een beveiligingsincident aan ISO is gemeld, mag de verbinding met of het inloggen op het gehackte systeem niet worden verbroken totdat de beveiligingsanalist van ISO hiertoe opdracht heeft gegeven.
      • Serviceonderbreking die niet het gevolg is van kwaadaardige activiteiten moet worden gemeld aan het juiste IT-ondersteuningspersoneel. Aanvullende informatie over het melden van verschillende soorten incidenten is te vinden op de beveiligingswebsite. Voor de meeste bedrijfsapplicaties op de campus moet een onderbreking van de dienstverlening bijvoorbeeld worden gemeld aan Campus Shared Services IT.

    • Respondeer tijdig op het beveiligingsincident aan de hand van de richtlijn voor het prioriteren van incidenten.

    *Note: het e-mailadres [email protected] mag alleen worden gebruikt voor het melden van beveiligingsincidenten die onder MSSEI vallen. Beveiligingsincidenten die niet onder MSSEI vallen, moeten worden gemeld via [email protected].

    Prioritering van beveiligingsincidenten

    Om prioriteiten te kunnen stellen ten aanzien van de timing en de middelen die nodig zijn om corrigerende maatregelen te treffen, moeten eigenaren en beheerders van bronnen de impact van een beveiligingsincident beoordelen op basis van de volgende factoren:

    • Hoe het incident de bestaande functionaliteit van de getroffen systemen zal beïnvloeden
    • Of het incident de vertrouwelijkheid of integriteit van gedekte gegevens UC P4 (voorheen UCB PL2) of niet-gedekte gegevens schendt
    • Hoeveel van de gebruikerspopulatie wordt getroffen door het beveiligingsincident
    • Wat is de reputatie/financiële impact voor de campus

    Met de hierboven genoemde factoren als startpunt, moeten beveiligingsincidenten worden beoordeeld en een hoge of lage prioriteit krijgen van de aangewezen Incident Handler en Resource Manager. Factoren waarmee rekening moet worden gehouden zijn niet alleen de huidige impact van het incident, maar ook de waarschijnlijke toekomstige impact van het incident als het niet onmiddellijk wordt verholpen. Alle incidenten met een hoge prioriteit moeten onmiddellijk aan ISO worden gemeld volgens de procedures voor incidentafhandeling. Zodra een beveiligingsincident aan de ISO-analist is gemeld, zal de prioriteitscategorie worden bevestigd of herzien na aanvullende analyse van de gebeurtenis.

    Voorbeelden van een beveiligingsincident met hoge prioriteit zijn onder meer een gebeurtenis die leidt tot het verlies van kritieke functies voor een campus- of afdelingsbrede gebruikerspopulatie. Ook een schending van de vertrouwelijkheid van gedekte gegevens door meer dan 500 gebruikers moet een hoge prioriteit krijgen. Het prioriteitsniveau van een incident kan in latere fasen van het incidentenbestrijdingsproces worden herzien, nadat door analyse van aanvullend bewijsmateriaal een nauwkeuriger inzicht is verkregen in de impact van het incident. Elke bijstelling van het prioriteitsniveau moet worden beoordeeld door leden van het lokale incident response team en een ISO-analist.

    De volgende tabel biedt aanvullende richtlijnen voor de tijdsbesteding van de leden van het incident response team in het geval van een beveiligingsincident (ISO-analist, Incident Handler, Resource Manager):

    Incident Response Phases	Erg incident met hoge prioriteit	Erg incident met lage prioriteit
    Opsporing	Immediate	8 uur
    Analyse	Resource Manager en incidentbehandelaar toegewezen om samen te werken met ISO Analyst* op dedicated, doorlopende basis.	Incidentbehandelaar toegewezen en speciaal ingezet om tijdens normale kantooruren met ISO-analist aan zaak te werken.
    Recovery	Resource Manager en incidentbehandelaar toegewezen om samen te werken met de ISO-analist* op een speciale, doorlopende basis.	Incidentbehandelaar toegewezen om samen met de ISO-analist aan een zaak te werken wanneer er tijd/middelen beschikbaar zijn.
    Post-Incident	Incidentbehandelaar toegewezen om met ISO-analist aan zaak te werken als tijd/middelen beschikbaar zijn.	Incidentbehandelaar toegewezen om met ISO-analist aan zaak te werken als tijd/middelen beschikbaar zijn.

    * Bij zaken met een hoge prioriteit kunnen andere belanghebbenden op de campus betrokken zijn, waaronder vertegenwoordigers van het IT-beleid, de campusraad en andere leidinggevenden op de campus.

    definities van de responsfase voor incidenten:

    • Detectie – Dit specificeert de maximale hoeveelheid tijd die moet verstrijken vanaf het moment waarop de verdachte gebeurtenis wordt gedetecteerd tot het moment waarop de volgende acties naar verwachting zijn voltooid:

      • Initiële beoordeling en triage
      • Bepaal initieel prioriteitsniveau op basis van intakelapport
      • Meld Incident aan ISO
      • ISO-analist wordt toegewezen om samen te werken met Incident Handler en Resource Manager
      • Invoeren incident in ISO ticketing systeem
    • Analyse – De periode in de levensloop van het geval. De periode in de levenscyclus van een case waarin actief moet worden gereageerd op een incident om ervoor te zorgen dat de case met succes wordt opgelost. Meestal gaat het om systeem- of serviceonderbrekingen en/of het dringend bewaren van bewijsmateriaal. Ook wordt geverifieerd of het incident legitiem is, wordt de prioritering bevestigd en wordt de juiste escalatie gemaakt op basis van de impact van het incident. Typische activiteiten zijn:

      • Beoordeling, triage, indamming, bewaring van bewijsmateriaal, eerste herstel

    • Recovery – De periode in de levenscyclus van een zaak waarin actieve incidentrespons niet nodig is om de zaak succesvol op te lossen. Typische activiteiten zijn:

      • Verzameling van bewijsmateriaal, analyse en onderzoek, forensisch onderzoek, herstel, volledig herstel, post-mortem.

    • Post-Incident – Nadat het incident naar behoren is afgehandeld, stelt het incident response team een rapport op waarin de oorzaak en de kosten van het incident in detail worden beschreven, evenals de stappen die de organisatie moet nemen om toekomstige incidenten te voorkomen.

    De definities zijn afkomstig van http://www.first.org/_assets/resources/guides/csirt_case_classification….

    Aanvullende bronnen

    • NIST Computer Security Incident Handling Guide, http://csrc.nist.gov/publications/nistpubs/800-61rev2/SP800-61rev2.pdf

    • Software Engineering Institute Handbook for Computer Security Incident Response Teams (CSIRTs),http://www.sei.cmu.edu/library/abstracts/reports/03hb002.cfm

    • Incident Response Plan TEMPLATE voor afzonderlijke systemen en diensten

    • Campus Incident Response Plan