Begin met het logboek, niet met vermoedens
Wanneer er iets aan je GitHub-account anders lijkt, is de nuttige eerste stap een registratie ophalen die je zelf beheert, in plaats van gebeurtenissen uit je geheugen te reconstrueren. GitHub’s persoonlijke beveiligingslogboek is die registratie.
GitHub’s persoonlijke beveiligingslogboek bevat acties van de afgelopen 90 dagen. Bron
Omdat het logboek beperkt is tot een recent venster, moet je vroeg exporteren. Gebeurtenissen die buiten het venster vallen, verschijnen later niet meer, en je kunt ze niet terugkrijgen door te wachten.
Waar het logboek staat en wat je kunt filteren
Het logboek is beschikbaar in de accountinstellingen onder Archieven, Beveiligingslogboek en ondersteunt filters zoals actor, repository en actie. Bron
De filters zijn belangrijker dan het ruwe volume. Door te filteren op actor, repository of actie kun je de periode en het oppervlak isoleren die je belangrijk vindt, in plaats van door irrelevante routinematige activiteit te scrollen.
Exporteer een privékopie voordat je analyseert
Het menu Exporteren downloadt JSON of CSV; ondersteunde filters kunnen de export verfijnen. Bron
Behandel het geëxporteerde bestand als gevoelig. Het bevat een registratie van accountactiviteit, inclusief actoren en acties, en kan persoonlijke of organisatorische context onthullen. Bewaar het op een privéplek, deel het alleen met mensen die je direct helpen bij het onderzoek, en vermijd het plakken in openbare threads of issue-trackers. Als je later een kopie aan een supportteam van een platform moet geven, deel dan de nauwst gefilterde export die hun vraag beantwoordt.
Bouw een werkblad voor de incidenttijdlijn
Een logboekexport is een lijst met gebeurtenissen, geen verhaal. Zet het om in een werkblad zodat waarnemingen, interpretaties en open vragen gescheiden blijven. Een eenvoudige structuur werkt:
| Kolom | Wat erin gaat | Waarom het belangrijk is |
|---|---|---|
| Gebeurtenis | Een korte aanduiding van wat er gebeurde | Maakt de rij later scanbaar |
| Tijd | De tijdstempel zoals geregistreerd, met vermelding van de tijdzone | Voorkomt volgordefouten |
| Actor | Het account of de identificatie die als handelend is geregistreerd | Identificeert de geregistreerde bron, niet een persoon |
| Actie | Wat het logboek zegt dat er is gedaan | Houdt de rij feitelijk |
| Zekerheid | Hoe zeker je bent dat deze rij relevant en correct gelezen is | Scheidt sterke rijen van speculatieve |
| Open vraag | Wat je nog moet controleren | Voorkomt dat aannames verharden tot feiten |
Vul het werkblad vanuit de export, één rij per gebeurtenis die je relevant acht. Gebruik de zekerheidskolom eerlijk: een rij die je direct uit de export hebt gelezen is sterker dan een rij die je hebt afgeleid uit een wijziging die je opmerkte. Waar je een wijziging opmerkte maar geen bijbehorende gebeurtenis kunt vinden, noteer dat als een open vraag in plaats van een conclusie.
Scheid waargenomen acties van bewijs van wie ze heeft uitgevoerd
Dit is het deel waar de meeste tijdlijnen de fout ingaan. Een vermelding in het logboek vertelt je wat de registratie zegt dat er is gebeurd en welke actor-identificatie eraan is gekoppeld. Het stelt op zichzelf niet vast welke menselijke persoon achter het toetsenbord zat. Gedeelde apparaten, hergebruikte sessies, gecompromitteerde inloggegevens en legitieme automatisering kunnen allemaal vermeldingen opleveren die lijken op een handelend persoon.
Houd tijdens het beoordelen twee denkwijzen in je hoofd gescheiden:
- Waargenomen: de gebeurtenis, tijd, actor en actie zoals geregistreerd.
- Niet vastgesteld: wie het fysiek heeft uitgevoerd, waarom, en of de actor-identificatie overeenkomt met de persoon die je veronderstelt.
Schrijf conclusies alleen in de tweede categorie wanneer je onafhankelijk bewijs hebt. Tot dan horen ze in de kolom met open vragen.
Lees een ontbrekende gebeurtenis niet als bewijs dat er niets is gebeurd
Een lege plek in de export is geen bewijs van inactiviteit. Het logboek beslaat een gedefinieerd recent venster, en een export weerspiegelt de filters die je hebt toegepast. Als je op een repository hebt gefilterd, verschijnen gebeurtenissen in andere repositories niet. Als de wijziging waar je je zorgen over maakt buiten het venster viel, staat die er niet in. Noteer afwezigheden als hiaten om te onderzoeken, niet als geruststelling.
Als je de toegang bent kwijtgeraakt
Als je helemaal niet kunt inloggen om het logboek te bereiken, stop dan met proberen gebeurtenissen van buitenaf te reconstrueren en gebruik GitHub’s officiële accountherstelproces. Herstel is de weg die je vermogen om het account te beoordelen herstelt. Vraag derden niet om namens jou toegang te krijgen tot het account, en beschouw een wachtwoordreset alleen niet als een afgerond onderzoek; zodra de toegang terug is, exporteer je het logboek en bouw je de tijdlijn voor de periode rond de wijziging.
Een korte checklist
- Exporteer het beveiligingslogboek voordat het venster van 90 dagen verder schuift.
- Bewaar de export privé en noteer de datum en tijdzone van de export.
- Pas filters toe om de periode en het oppervlak te isoleren die je belangrijk vindt, en exporteer de gefilterde weergave als dat helpt.
- Bouw het werkblad met kolommen voor gebeurtenis, tijd, actor, actie en zekerheid.
- Markeer elke rij als waargenomen of afgeleid, en houd open vragen apart.
- Noteer ontbrekende gebeurtenissen als hiaten, niet als bewijs dat er niets is gebeurd.
- Als de toegang verloren is, gebruik eerst officieel herstel en ga dan terug naar stap 1.
Een nuttige volgende stap
Zodra je een tijdlijn hebt, is de volgende vraag vaak welke andere accounts aan dezelfde naam of identificaties zijn gekoppeld. Dat is een andere taak dan het lezen van een beveiligingslogboek, en die heeft zijn eigen methode: zie hoe je alle accounts vindt die aan een naam zijn gekoppeld. Houd de twee onderzoeken gescheiden, zodat bevindingen uit het ene niet worden aangezien voor bewijs in het andere.