Incidenten rapporteren¶

Dit uitvoeringsboek helpt het Weblateteam om product-beveiligingsrapporten en beveiligingsincidenten af te handelen die invloed hebben op door Weblate uitgevoerde services. Het beleid voor rapporteren en deadlines staan in Kwetsbaarheid en incidentafhandeling. Voor afzondering van service en herstel, gebruik Incident herstelplan (Incident response plan (IRP)) voor Weblate.

Een persoon handelt het incident af, met een beschikbare teamgenoot als back-up. Dezelfde mensen onderzoeken, rapporteren en communiceren waar nodig. Contacttoewijzingen, toegangsdetails en voltooide incidentnotities behoren in private teamrecords.

Het incident opvolgen¶

Wie een betrouwbaar rapport van actieve exploitatie of een ernstig beveiligingsincident ziet, meldt dit aan teamgenoten via Signal. Een beschikbare teamgenoot neemt de verantwoordelijkheid en benoemt een back-up; beantwoording vereist geen instemming van het management. De back-up neemt de taken over als de afhandelaar niet beschikbaar is. Leg de overdracht vast in de incidentnotitie, zodat deadlines en beloofde bijwerkingen zichtbaar blijven.

Begin onmiddellijk een private notitie voor het incident. Leg vast wanneer het team bekend werd met de relevante feiten, gebruik tijdstempels met een tijdzone, bij voorkeur UTC. Maak onderscheid tussen het ontvangen van een initieel rapport voor het bekend worden van actieve exploitatie of een ernstig incident; leg voor beide het bewijs vast. Wacht niet op een reparatie, formele declaratie of volledig onderzoek om de voorbereiding voor de rapportage te beginnen.

Evalueer het rapport¶

Actieve exploitatie betekent betrouwbaar bewijs dat een kwaadaardige acteur een kwetsbaarheid heeft geëxploiteerd zonder toestemming van de eigenaar van het systeem. Een theoretische kwetsbaarheid, een proof of concept, of ontbreken van toestemming alleen maakt nog geen kwaadaardige exploitatie. Onderzoek de verdachte exploitatie snel en leg vast wat bekend is en wat onzeker is. Bekijk CRA Article 3(42).
Beoordeel een product-beveiligingsincident als ernstig als het beveiliging of belangrijke of gevoelige gegevens of functies beschadigt of zou kunnen beschadigen. Of leidt, of zou kunnen leiden, tot het introduceren of uitvoeren van kwaadaardige code in de systemen van het product of van de gebruiker. Dat omvat ook het uitvoeren van al aanwezige kwaadaardige code. Bekijk CRA Article 14(5). Beoordeel beschikbaarheid, authenticiteit, integriteit en vertrouwelijkheid. Alleen operationele uitval bepaalt deze classificatie niet.
Controleer betrokken versies, uitgaveartefacten en meegeleverde afhankelijkheden, inclusief incidenten die werden gerapporteerd door zelfhostende operatoren. Lokale isolatie blijft de verantwoordelijkheid van de operator; productrapportage wordt hier beoordeeld. Een bekendmaking van de bevindingen tijdens runtime onder Weblate dreigingsmodel besluit niet op zichzelf of een incident zou moeten worden gerapporteerd.
Beoordeel beide rapportagesporen wanneer actieve exploitatie ook een ernstig incident veroorzaakt. Leg waar mogelijk afzonderlijke tijdstippen van bekend worden vast en volg beide deadlines voor de uiteindelijke rapporten.
Controleer vroeg op een inbreuk op persoonsgegevens, inclusief per ongeluk of onwettelijke vernietiging, verlies, of wijzigingen, alsook niet-geautoriseerd onthullen of toegang. Beoordeel privacynotificaties zelfs als geen gegevens werden onthuld. Vraag indien nodig advies buitenshuis tijdens het onderzoeken en voorbereiden van de rapportage.

Leg vast of rapportage van de gebeurtenis verplicht is of vrijwillig en waarom. Onzekerheid vereist directe consultatie, geen pauze in voorbereiding of toepasselijke deadlines. Het beleid voor de basisregel bepaalt niet de reglementaire rol van Weblate; bekijk Product- en contactinformatie. Beoordeel de betrokken service voor hosten of te downloaden distributie afzonderlijk, in plaats van aan te nemen dat ze hetzelfde reglementaire bereik hebben.

Behoud één privé incidentennotitie¶

Kopieer deze velden naar het privé incidentendocument van het team:

Geval-ID, samenvatting, contactpersoon, back-up en overdragen.
Product, betrokken versies of samenvattingen van artefacten, uitrollen en bekende statussen voor lidstaten waar het betrokken product ook beschikbaar werd gemaakt, met de bron en beperkingen van deze informatie. Leg door het incident geraakte locaties afzonderlijk vast als dat al bekend en relevant is.
Tijdstempels voor bekend worden, ondersteunend bewijs, onbekenden en rationele classificatie, inclusief het besluit om verplicht of vrijwillig te rapporteren.
Deadlines voor rapportage, herinneringen en losstaande privacymeldingstaken.
Tijdlijn onderzoek, impact, motiveringen en wanneer elke correctieve of overwogen maatregel beschikbaar kwam.
Kopieën van ingediende rapporten, tijdstempels voor indienen, platformverwijzingen, ontvangstbewijzen, mislukkingen en gevraagde rapporten voor opvolgen.
Gebruikerswaarschuwingen, links naar ontvangers of publiek advies, beloofde updates en elke vertraagde technische onthulling met zijn reden en datum van beoordelen.
Resterende acties en de uitkomsten van de korte teambeoordeling.

Houd gevoelig bewijs en bijlagen bij het privérecord, met beperkte toegang voor mensen die het incident afhandelen. Sla inloggegevens op in de opslag voor de inloggegevens van het team. Signal is voor coördinatie; kopieer beslissingen en relevante tijdstempels in de duurzame notitie. Gebruik geen publieke problemen voor deze records.

Indienen en opvolgen¶

Gebruik de huidige ENISA Single Reporting Platform guidance om de coördinerende CSIRT, regelingen voor toegang en verplichte of vrijwillige route voor indienen te verifiëren. Een nationaal portaal voor het rapporteren van incidenten is niet noodzakelijkerwijs het CRA-eindpunt. Raadpleeg de coördinator als de route niet duidelijk is.

De afhandelaar dient rapporten in; de back-up neemt dat, indien nodig, over. Vraag een teamgenoot om te beoordelen als dat praktisch is, maar mis geen deadline terwijl wordt gewacht op beoordelen. Gebruik de deadlines in Authoriteitenrapportage en de huidige platformformulieren Dien beschikbare informatie op tijd in, identificeer onbekende en vul het aan als het onderzoek voortduurt.

In beide sporen van de vroege waarschuwing, identificeer de gebeurtenis en, waar bekend, de lidstaten waar het betrokken product beschikbaar werd gemaakt. Dat is distributieinformatie, niet de locaties van individuele gebruikers of alleen de plaatsen waar de exploitatie werd waargenomen. Voor een ernstig incident, neem ook op of aan onwettelijke of kwaadaardige daden wordt gedacht. Beide sporen vragen distributie naar lidstaten onder CRA Article 14(2)(a) and (4)(a).
In een hoofdnotificatie voor een geëxploiteerde kwetsbaarheid, identificeer het betrokken product en beschrijf de algemene vorm van zowel de exploit als de kwetsbaarheid. Neem ook reeds genomen correctieve of overwogen maatregelen op, maatregelen die gebruikers kunnen nemen en de gevoeligheid van de informatie, waar van toepassing, zoals vereist door CRA Article 14(2)(b).
In een hoofdnotificatie voor een ernstig incident, beschrijf de vorm van het incident en geef een initiële beoordeling, inclusief bekende impact. Neem daarin reeds genomen correctieve of overwogen maatregelen op, maatregelen die gebruikers kunnen nemen en, waar nodig, de gevoeligheid van de informatie, zoals vereist door CRA Article 14(4)(b).
In een uiteindelijk rapport voor een geëxploiteerde kwetsbaarheid, beschrijf de kwetsbaarheid, inclusief de ernst en impact ervan. Neem ook eventuele beschikbare informatie over kwaadaardige actoren op die het hebben geëxploiteerd of het nog exploiteren en details van de beveiligingsupdate of andere correctieve maatregelen die beschikbaar zijn gesteld om het te verhelpen, zoals vereist door CRA Article 14(2)(c). Beschikbaarheid van een beperking kan deze deadline starten voordat een uiteindelijke patch gereed is.
In een uiteindelijk rapport voor een ernstig incident, verschaf een gedetailleerde beschrijving van het incident, inclusief ernst en impact ervan, het type dreiging of bronoorzaak die het lijkt te hebben geactiveerd en zowel toegepaste als lopende beperkende maatregelen, zoals vereist door CRA Article 14(4)(c). Benoem expliciet als er geen lopende beperkingen zijn.

Voor informatie over de distributie, gebruik bestaande klant- of distributierecords, zoals de landen van bekende betalende klanten. Benoem de beperkingen van deze records: locaties van andere gebruikers zouden onbekend kunnen zijn. Leid geen distributie in elke lidstaat af uit algemene beschikbaarheid binnen de EU. Deze procedure vereist niet het volgen van locaties van individuele gebruikers of het verzamelen van nieuwe locatiegegevens. Rapporteer wat bekend is, zonder het indienen te laten vertragen om andere locaties op te sporen, en werk waar nodig de informatie bij. Bekijk de veld voor de beschikbaarheid van het product in de ENISA SRP-woordenlijst.

Sla ontvangstbewijzen en rapportverwijzingen op. Volg aanvragen voor tussenliggende rapporten en werk eerdere indieningen bij als feiten veranderen. Voor een gebeurtenis die beide sporen activeert, koppel de records en zorg ervoor dat beide sets van vereisten voor de rapporten worden afgedekt; een uiteindelijk rapport moet niet stilletjes het andere vervangen.

Als het platform niet beschikbaar is, leg mislukte pogingen en tijdstempels vast, neem contact op met de coördinator via zijn gepubliceerde noodkanalen, en volg de instructies daarin. Voltooi het indienen voor het platform als de toegang weer mogelijk is. Alternatief contact is niet automatisch bewijs dat aan een wettelijke verplichting tot rapportage is voldaan.

Gebruikers waarschuwen en opvolgen¶

Verzend beschermend advies zonder te wachten op een reparatie of volledige technische bekendmaking, gebruik de e-mail en publieke kanalen voor advies in Kwetsbaarheid en incidentafhandeling. Benoem betrokken versies, bekende impact, beschikbare acties en resterende onzekerheid. Leg vast wat werd gecommuniceerd en volg beloofde updates op.

Rapporteren aan autoriteiten, waarschuwen van gebruikers en gedetailleerde bekendmaking kunnen op verschillende tijdstippen gebeuren. Leg beveiligingsredenen vast voor het vertragen van technische details en bezoek de beslissing opnieuw op de vastgelegde beoordelingsdatum.

Na herstel, controleer resterende deadlines voor rapportage, gevraagde updates en beslissingen voor bekendmaking. Houd een korte teambeoordeling, leg verbeteringen vast en sluit de incidentnotitie als nog openstaande acties zijn voltooid of expliciet zijn overgedragen aan een nieuwe eigenaar met een verloopdatum.

Voorbereidingschecklist¶

Dit zijn te voltooien taken voor instellingen en privé vastgelegd. Publiceren van dit uitvoeringsboek stelt geen toegang of oefeningen in die al op hun plaats zijn.

Kies het normale contact voor rapporteren en back-up en stem af hoe teamgenoten elkaar alarmeren als iemand niet beschikbaar is.
Verifieer toegang voor rapporteren, herstelregelingen, het coördinerende CSIRT en gepubliceerde noodcontacten met ENISA Single Reporting Platform guidance. Houd accountdetails privé.
Kies een toegankelijke private locatie voor de afhandelaar en back-up voor incidentnotities, en gebruik bestaande teamprogramma’s voor herinneringen voor deadline en overdracht.
Controleer toegang tot contactlijsten van klanten en GitHub beveiligingsadviezen.
Voer een korte offline tafeloefening uit die een exploitatierapport voor een vrijdagavond behandelt, een ernstig incident zonder een bekende kwetsbaarheid, een zelfgehost of meegeleverd-afhankelijkheidsrapport, en een gebeurtenis die beide sporen activeert. Neem een niet beschikbare afhandelaar op, uitval van een platform, onvolledige informatie en een beschikbare beperking voor de uiteindelijke patch. Controleer de deadlines voor verlopen uren en deadlines voor kalendermaanden voor februari. Leg gaten en opvolgacties vast zonder oefeningrapporten te verzenden naar echte ontvangers.