Vraag Hoe ga ik om met een gecompromitteerde server?


Dit is een Canonical Question over serverbeveiliging - Reageren op brekegebeurtenissen (hacken)
  Zie ook:

Canonieke versie
Ik vermoed dat een of meer van mijn servers is gehackt door een hacker, virus of ander mechanisme:

  • Wat zijn mijn eerste stappen? Wanneer ik op de locatie aankom, moet ik de server loskoppelen, "bewijs" bewaren, zijn er andere eerste overwegingen?
  • Hoe kan ik services weer online krijgen?
  • Hoe voorkom ik dat hetzelfde onmiddellijk weer gebeurt?
  • Zijn er best practices of methodologieën om van dit incident te leren?
  • Als ik een Incident Response Plan samen wilde stellen, waar zou ik dan beginnen? Moet dit onderdeel zijn van mijn Disaster Recovery of Business Continuity Planning?

Originele versie 

2011.01.02 - Ik ben op weg naar mijn werk om 21.30 uur. op een zondag omdat onze server op een of andere manier is gecompromitteerd en resulteerde in een    DOS aanval op onze provider. De servers hebben toegang tot internet   is afgesloten wat betekent dat meer dan 5-600 van onze klantensites nu zijn   naar beneden. Dit kan een FTP-hack zijn of een zwakke plek in de code   ergens. Ik weet het niet zeker tot ik er ben.

Hoe kan ik dit snel opzoeken? We hebben er heel veel zin in   procederen als ik de server niet zo snel mogelijk een back-up kan laten maken. Alle hulp is   gewaardeerd. We gebruiken Open SUSE 11.0.


2011.01.03 - Iedereen bedankt voor je hulp. Gelukkig was ik NIET de enige persoon die verantwoordelijk was voor deze server, alleen de dichtstbijzijnde. We kregen voor elkaar   om dit probleem op te lossen, hoewel het misschien niet van toepassing is op vele anderen in een   verschillende situatie. Ik zal gedetailleerd beschrijven wat we gedaan hebben.

We hebben de server losgekoppeld van het net. Het was aan het presteren (proberen   uitvoeren) een Denial Of Service-aanval op een andere server in Indonesië,   en de schuldige partij was daar ook gevestigd.

We probeerden eerst te achterhalen waar dit vandaan kwam,   aangezien we meer dan 500 sites op de server hebben, hadden we dat verwacht   maanlicht voor enige tijd. Echter, met SSH-toegang nog steeds, hebben we een   opdracht om alle bestanden te vinden die zijn bewerkt of gemaakt in de tijd dat de aanvallen plaatsvonden   begonnen. Gelukkig is het inbreukmakende bestand in de winter gemaakt   vakanties wat betekende dat er niet veel andere bestanden werden aangemaakt op de   server op dat moment.

We konden toen het overtredende bestand identificeren dat zich in de   geüploade afbeeldingen map binnen een ZenCart website.

Na een korte pauze kwamen we tot de conclusie dat dit, vanwege de bestanden   locatie, moet deze zijn geüpload via een faciliteit voor het uploaden van bestanden   was onvoldoende beveiligd. Na enig googlen, vonden we dat dat er was   een beveiligingsprobleem waardoor bestanden konden worden geüpload, binnen de   ZenCart admin panel, voor een foto voor een platenmaatschappij. (Het deel   dat het nooit echt is gebruikt), het plaatsen van dit formulier heeft het zojuist geüpload   bestand, het heeft de extensie van het bestand niet gecontroleerd en deed het niet eens   controleer om te zien of de gebruiker was ingelogd

Dit betekende dat alle bestanden konden worden geüpload, inclusief een PHP-bestand voor   de aanval. We hebben de kwetsbaarheid met ZenCart op de geïnfecteerde beveiligd   site en verwijderde de aanstootgevende bestanden.

De klus was geklaard en ik was om twee uur thuis.


Het moraal   - Gebruik altijd beveiligingspatches voor ZenCart of een ander CMS-systeem. Zoals wanneer beveiligingsupdates worden vrijgegeven, het geheel   wereld wordt bewust gemaakt van de kwetsbaarheid.   - Maak altijd back-ups en maak een back-up van uw back-ups.   - Zet in of zorg voor iemand die er in tijden als deze zal zijn. Om te voorkomen dat iemand op een paniekpost op Server vertrouwt   Fout.


578
2018-01-02 21:31


oorsprong


Ik weet hoe je je voelt - we zijn heel gelukkig geweest met "behulpzame" hackers op deze site, waar ze ons vertellen wat ze hebben gedaan! Ik kijk uit naar geweldige antwoorden op deze vraag, voor het geval we in de toekomst 'niet zo behulpzame' gasten krijgen. - Jarrod Dixon♦
Bel een professional om te helpen! - marcog
Ik wil niet intelligent of onsympathiek klinken (ik ben geen van beiden), en natuurlijk ben ik onwetend van de details van uw situatie, maar als u de enige persoon bent die verantwoordelijk is voor een site-instelling van 500-600, kan er een fundamentele fout zijn in hoe deze server wordt uitgevoerd. Sommige bedrijven gebruiken een toegewijde sysadmin die de rest van de dag niets anders doet dan servers onderhouden - een taak die dat wel is niet automatisch binnen het bereik van een programmeur, ook al lijkt dat misschien zo. Misschien is dat het overwegen waard als de crisis voorbij is. Hoe dan ook, op dit moment, veel succes bij het oplossen van de situatie. - Pekka 웃
Ga er niet noodzakelijk van uit dat je een volledig opgebouwde kernel-rootkit hebt en dat je root-wachtwoord is aangetast. Het is misschien gewoon een stiekem bash / perl-script, en het is mogelijk om het op te schonen zonder te formeren, ondanks waar het koor hier op luidt ... serverfault.com/questions/639699/... - Hayden Thring


antwoorden:


Het is moeilijk om specifiek advies te geven over wat je hier hebt gepost, maar ik heb wel een generiek advies gebaseerd op een bericht dat ik eeuwen geleden schreef toen ik nog steeds de moeite nam om te bloggen.

Geen paniek

Allereerst, er zijn geen "quick fixes" anders dan het herstellen van uw systeem tegen een back-up voorafgaand aan de inbraak, en dit heeft ten minste twee problemen.

  1. Het is moeilijk om vast te stellen wanneer de inbraak heeft plaatsgevonden.
  2. Het helpt je niet om het "gat" te sluiten waardoor ze de vorige keer binnen konden komen, noch om de gevolgen van een "gegevensdiefstal" te behandelen die mogelijk ook heeft plaatsgevonden.

Deze vraag blijft herhaaldelijk gesteld door de slachtoffers van hackers die inbraken op hun webserver. De antwoorden veranderen zelden, maar mensen blijven de vraag stellen. Ik weet niet zeker waarom. Misschien houden mensen gewoon niet van de antwoorden die ze hebben gezien bij het zoeken naar hulp, of ze kunnen iemand die ze vertrouwen niet vinden om hen advies te geven. Of misschien lezen mensen een antwoord op deze vraag en concentreren ze zich teveel op de 5% waarom hun geval speciaal is en verschillen van de antwoorden die ze online kunnen vinden en missen ze de 95% van de vraag en het antwoord waar hun zaak bijna in de buurt is als degene die ze online lezen.

Dat brengt me bij de eerste belangrijke nugget van informatie. Ik waardeer het echt dat je een speciale unieke sneeuwvlok bent. Ik waardeer dat uw website ook is, omdat het een weerspiegeling is van u en uw bedrijf of op zijn minst uw harde werk voor rekening van een werkgever. Maar als iemand aan de buitenkant kijkt, of een computerbeveiligingsspecialist die naar het probleem kijkt om u te helpen of zelfs de aanvaller zelf, is het zeer waarschijnlijk dat uw probleem minstens 95% identiek is aan elk ander geval dat zij hebben ooit bekeken.

Neem de aanval niet persoonlijk en neem de aanbevelingen die hier volgen of die u persoonlijk van anderen krijgt niet. Als je dit leest nadat je het slachtoffer bent geworden van een website-hack, vind ik het echt jammer en ik hoop echt dat je hier iets nuttigs kunt vinden, maar dit is niet het moment om je ego in de weg te laten zitten van wat je nodig hebt om do.

U hebt net ontdekt dat uw server (s) is gehackt. Wat nu?

Raak niet in paniek. Doe absoluut geen haast en probeer absoluut niet te doen alsof dingen nooit zijn gebeurd en helemaal niet handelen.

Ten eerste: begrijp dat de ramp al is gebeurd. Dit is niet het moment voor ontkenning; het is de tijd om te accepteren wat er is gebeurd, er realistisch over te zijn en stappen te ondernemen om de gevolgen van de impact te beheersen.

Sommige van deze stappen gaan pijn doen, en (tenzij je website een kopie van mijn gegevens bevat), maakt het me echt niet uit als je alle of sommige van deze stappen negeert, dat is aan jou. Maar als je ze op de juiste manier volgt, wordt het uiteindelijk beter. Het medicijn kan vreselijk smaken, maar soms moet je dat over het hoofd zien als je echt wilt dat de kuur werkt.

Zorg dat het probleem niet erger wordt dan het al is:

  1. Het eerste dat u moet doen, is de betreffende systemen loskoppelen van internet. Welke andere problemen u ook hebt, waardoor het systeem verbonden blijft met internet, zorgt ervoor dat de aanval door kan gaan. Ik bedoel dit vrij letterlijk; laat iemand de server fysiek bezoeken en netwerkkabels loskoppelen als dat is wat nodig is, maar koppel het slachtoffer los van de overvallers voordat u iets anders probeert te doen.
  2. Wijzig al uw wachtwoorden voor alle accounts op alle computers die zich in hetzelfde netwerk bevinden als de besmette systemen. Nee echt. Alle accounts. Alle computers. Ja, je hebt gelijk, dit kan overdreven zijn; aan de andere kant, misschien niet. Je weet geen van beide, toch?
  3. Controleer uw andere systemen. Besteed speciale aandacht aan andere op het internet gerichte services en aan die welke financiële of andere commercieel gevoelige gegevens bevatten.
  4. Als het systeem iemands persoonlijke gegevens bevat, informeer dan onmiddellijk de persoon die verantwoordelijk is voor gegevensbescherming (als dat niet het geval u is) en URGE een volledige openbaarmaking. Ik weet dat deze zwaar is. Ik weet dat deze pijn gaat doen. Ik weet dat veel bedrijven dit soort problemen onder het tapijt willen vegen, maar het bedrijf zal ermee te maken krijgen - en moet dit doen met het oog op alle relevante privacywetten.

Hoe geïrriteerd uw klanten ook zijn om u te laten vertellen over een probleem, ze zullen veel meer geïrriteerd zijn als u het ze niet vertelt, en zij ontdekken het pas nadat iemand $ 8.000 aan goederen heeft gerekend met behulp van de creditcardgegevens die zij heeft gestolen van uw site.

Weet je nog wat ik eerder zei? Het slechte is al gebeurd. De enige vraag is nu hoe goed je ermee omgaat.

Begrijp het probleem volledig:

  1. Plaats de betreffende systemen NIET online totdat deze fase volledig is voltooid, tenzij je de persoon wilt zijn wiens bericht het omslagpunt was voor mij, toen ik besloot dit artikel te schrijven. Ik ga geen link naar die post maken, zodat mensen goedkoop kunnen lachen, maar de echte tragedie is wanneer mensen niet leren van hun fouten.
  2. Bestudeer de 'aangevallen' systemen om te begrijpen hoe de aanvallen erin slaagden om uw veiligheid in gevaar te brengen. Doe alles om te achterhalen waar de aanvallen "vandaan kwamen", zodat u begrijpt welke problemen u hebt en moet aanpakken om uw systeem in de toekomst te beveiligen.
  3. Onderzoek de 'aangevallen' systemen opnieuw, deze keer om te begrijpen waar de aanvallen zijn gegaan, zodat je begrijpt welke systemen tijdens de aanval zijn aangetast. Zorg ervoor dat u eventuele aanwijzingen opvolgt die suggereren dat besmette systemen een springplank kunnen worden om uw systemen verder aan te vallen.
  4. Zorg ervoor dat de "gateways" die bij alle aanvallen worden gebruikt, volledig worden begrepen, zodat u ze op de juiste manier kunt sluiten. (bijvoorbeeld als uw systemen zijn aangetast door een SQL-injectieaanval, dan moet u niet alleen de specifieke code met fouten die ze hebben ingesloten, sluiten, u wilt ook al uw code controleren om te zien of hetzelfde soort fout is werd elders gemaakt).
  5. Begrijp dat aanvallen kunnen slagen vanwege meer dan één fout. Vaak slagen aanvallen er niet in één grote bug in een systeem te vinden, maar door verschillende problemen (soms klein en triviaal op zichzelf) samen te brengen om een ​​systeem in gevaar te brengen. Als u bijvoorbeeld SQL-injectie-aanvallen gebruikt om opdrachten naar een databaseserver te verzenden, wordt het ontdekken van de website / applicatie die u aanvalt, uitgevoerd in de context van een administratieve gebruiker en worden de rechten van dat account gebruikt als opstap om andere delen van een systeem. Of zoals hackers het graag noemen: "nog een dag op kantoor om misbruik te maken van veelvoorkomende fouten die mensen maken".

Waarom niet gewoon de exploit of rootkit die u hebt gedetecteerd "repareren" en het systeem weer online zetten?

In dergelijke situaties is het probleem dat u geen controle over dat systeem meer hebt. Het is niet jouw computer meer.

De enige manier om te zijn zeker dat je controle hebt over het systeem is om het systeem opnieuw te bouwen. Hoewel er veel waarde is bij het vinden en herstellen van de exploit die is gebruikt om in te breken in het systeem, kunt u niet zeker weten wat er nog meer aan het systeem is gedaan nadat de indringers de controle hebben gekregen (inderdaad, het is niet ongehoord voor hackers die werven systemen in een botnet om de exploits die ze zelf hebben gebruikt te patchen, om "hun" nieuwe computer te beschermen tegen andere hackers, en om hun rootkit te installeren).

Maak een herstelplan en breng uw website weer online en houd u eraan:

Niemand wil langer offline zijn dan nodig is. Dat is een gegeven. Als deze website een inkomstengenererend mechanisme is, zal de druk om het snel weer online te brengen, groot zijn. Zelfs als het enige dat op het spel staat de reputatie van je / je bedrijf is, gaat dit nog steeds veel druk genereren om dingen snel weer op te bouwen.

Geef echter niet toe aan de verleiding om te snel weer online te gaan. Verplaats in plaats daarvan zo snel mogelijk om te begrijpen waardoor het probleem is veroorzaakt en om het op te lossen voordat je weer online gaat, anders word je bijna zeker het slachtoffer van een inbraak en onthoud je dat "een keer gehackt worden als ongeluk kan worden beschouwd; om daarna weer gehackt te worden, ziet eruit als onvoorzichtigheid "(excuses aan Oscar Wilde).

  1. Ik neem aan dat je alle problemen hebt begrepen die hebben geleid tot de succesvolle inbraak in de eerste plaats voordat je deze sectie zelfs maar start. Ik wil de zaak niet overdrijven, maar als je dat nog niet eerder hebt gedaan, moet je dat echt doen. Sorry.
  2. Betaal nooit chantage / beschermingsgeld. Dit is het teken van een gemakkelijke markering en je wilt niet dat die uitdrukking ooit wordt gebruikt om je te beschrijven.
  3. Laat u niet verleiden om dezelfde server (s) weer online te zetten zonder een volledige herbouw. Het zou veel sneller moeten zijn om een ​​nieuwe doos te bouwen of de server "uit de omloop te halen en een schone installatie uit te voeren" op de oude hardware dan om elke hoek van het oude systeem te controleren om ervoor te zorgen dat het schoon is voordat het terug wordt geplaatst online opnieuw. Als je het daar niet mee eens bent, weet je waarschijnlijk niet wat het werkelijk betekent om ervoor te zorgen dat een systeem volledig wordt schoongemaakt, of de procedures voor de implementatie van je website zijn een onheilspellende puinhoop. U hebt waarschijnlijk back-ups en testimplementaties van uw site die u gewoon kunt gebruiken om de live site te bouwen en als u dat niet doet, is het niet uw grootste probleem om gehackt te worden.
  4. Wees zeer voorzichtig met het hergebruiken van gegevens die op het moment van de hack "live" waren op het systeem. Ik zal niet zeggen "doe het nooit" omdat je me gewoon negeert, maar eerlijk gezegd denk ik dat je de gevolgen van het bijhouden van gegevens moet overdenken als je weet dat je de integriteit ervan niet kunt garanderen. In het ideale geval zou u dit moeten herstellen van een back-up gemaakt voorafgaand aan de inbraak. Als je dat niet kunt of wilt doen, moet je heel voorzichtig zijn met die gegevens omdat het besmet is. U moet vooral op de hoogte zijn van de gevolgen voor anderen als deze gegevens eigendom zijn van klanten of bezoekers van de site in plaats van rechtstreeks aan u.
  5. Controleer het systeem / de systemen zorgvuldig. U moet besluiten dit als een doorlopend proces in de toekomst te doen (meer hieronder), maar u neemt extra inspanningen om waakzaam te zijn gedurende de periode onmiddellijk volgend op uw site die weer online komt. De indringers zullen bijna zeker terugkomen, en als je ze kunt zien proberen opnieuw in te breken, zul je zeker in staat zijn om snel te zien of je echt alle gaten die ze eerder hebben gebruikt plus ze hebben gemaakt voor jezelf, en je zou nuttig kunnen verzamelen informatie die u kunt doorgeven aan uw lokale rechtshandhavingsinstantie.

Het risico in de toekomst verminderen.

Het eerste dat je moet begrijpen, is dat beveiliging een proces is dat je moet toepassen gedurende de hele levenscyclus van het ontwerpen, implementeren en onderhouden van een internetgericht systeem, niet iets dat je achteraf als het ware een paar lagen over je code kunt slaan. verf. Om goed beveiligd te zijn, moeten een dienst en een applicatie vanaf het begin worden ontworpen met dit in gedachten als een van de belangrijkste doelen van het project. Ik realiseer me dat dat saai is en je hebt het allemaal al eerder gehoord en dat ik "de drukte man" niet realiseer om jouw beta web2.0 (bèta) -service in bètastatus op het web te krijgen, maar het feit is dat dit blijft herhaald worden omdat het waar was de eerste keer dat het werd gezegd en het is nog geen leugen geworden.

Je kunt het risico niet elimineren. Je zou zelfs niet moeten proberen dat te doen. Wat u echter wel moet doen, is begrijpen welke veiligheidsrisico's belangrijk voor u zijn en weten hoe u de impact van het risico en de kans dat het risico zich voordoet, kunt beheren en verminderen.

Welke stappen kunt u nemen om de kans te verkleinen dat een aanval succesvol is?

Bijvoorbeeld:

  1. Was de fout die mensen toestond om op uw site in te breken een bekende fout in leverancierscode, waarvoor een patch beschikbaar was? Als dat zo is, moet u dan opnieuw nadenken over uw aanpak van het patchen van toepassingen op uw internetservers?
  2. Was de fout die mensen toestond om op uw site in te breken een onbekende fout in leverancierscode, waarvoor een patch niet beschikbaar was? Ik ben zeker niet voorstander van het veranderen van leverancier wanneer iets als dit je bijt omdat ze allemaal hun problemen hebben en je binnen een jaar maximaal geen platforms meer hebt als je deze aanpak kiest. Als een systeem u echter voortdurend in de steek laat, moet u ofwel migreren naar iets robuuster of op zijn minst uw systeem opnieuw ontwerpen, zodat kwetsbare componenten in watten worden gewikkeld en zo ver mogelijk weg van vijandige ogen.
  3. Was de fout een fout in de door u ontwikkelde code (of een aannemer die voor u werkte)? Als dat het geval is, moet u dan opnieuw nadenken over hoe u de code goedkeurt voor implementatie op uw live site? Is de bug gevangen met een verbeterd testsysteem of met wijzigingen in uw coderingsnorm (bijvoorbeeld, terwijl technologie geen wondermiddel is, kunt u de kans op een geslaagde SQL-injectie-aanval verminderen door goed gedocumenteerde coderingstechnieken te gebruiken ).
  4. Was de fout te wijten aan een probleem met de implementatie van de server of toepassingssoftware? Als dat zo is, gebruikt u dan geautomatiseerde procedures om servers te bouwen en waar mogelijk te implementeren? Deze zijn een grote hulp bij het handhaven van een consistente "baseline" -status op al uw servers, waardoor de hoeveelheid aangepast werk die op elke server moet worden gedaan wordt geminimaliseerd en waardoor hopelijk de kans op een fout wordt geminimaliseerd. Hetzelfde geldt voor de inzet van code - als u iets "speciaal" wilt doen om de nieuwste versie van uw web-app te implementeren, probeer dan hard om het te automatiseren en zorg ervoor dat het altijd op een consistente manier gebeurt.
  5. Is de inbraak eerder betrapt met betere bewaking van uw systemen? Natuurlijk is 24-uurs bewaking of een "oproepbaar" -systeem voor uw personeel mogelijk niet rendabel, maar er zijn bedrijven die uw web-gerichte services voor u kunnen controleren en u kunnen waarschuwen als zich een probleem voordoet. Je zou kunnen besluiten dat je dit niet kunt betalen of het niet nodig hebt en dat is prima, neem het gewoon in overweging.
  6. Gebruik waar nodig tools zoals tripwire en nessus - maar gebruik ze niet blindelings, omdat ik het zeg. Neem de tijd om te leren hoe u enkele goede beveiligingshulpmiddelen gebruikt die geschikt zijn voor uw omgeving, houd deze hulpprogramma's bij en gebruik ze regelmatig.
  7. Overweeg beveiligingsdeskundigen in te huren om uw websitebeveiliging regelmatig te 'auditen'. Nogmaals, je zou kunnen beslissen dat je dit niet kunt betalen of het niet nodig hebt en dat is prima, neem het gewoon in overweging.

Welke stappen kunt u nemen om de gevolgen van een geslaagde aanval te verminderen?

Als je besluit dat het "risico" van de benedenverdieping van je woningoverstroming hoog is, maar niet hoog genoeg om bewegen te rechtvaardigen, moet je op zijn minst de onvervangbare familietradities verplaatsen naar boven. Rechts?

  1. Kunt u het aantal services verminderen dat rechtstreeks wordt blootgesteld aan internet? Kun je een kloof overbruggen tussen je interne diensten en je op internet gerichte diensten? Dit zorgt ervoor dat, zelfs als uw externe systemen worden aangetast, de kansen om dit te gebruiken als springplank om uw interne systemen aan te vallen, beperkt zijn.
  2. Bewaart u informatie die u niet hoeft op te slaan? Bewaar je dergelijke informatie 'online' wanneer deze ergens anders kan worden gearchiveerd? Er zijn twee punten aan dit onderdeel; het voor de hand liggende is dat mensen geen informatie van u kunnen stelen die u niet hebt, en het tweede punt is dat hoe minder u opslaat, hoe minder u hoeft te onderhouden en te coderen, en dus er minder kans is dat bugs mislopen uw code of systeemontwerp.
  3. Gebruikt u de "least access" -principes voor uw web-app? Als gebruikers alleen uit een database hoeven te lezen, zorg er dan voor dat het account dat de web-app gebruikt voor service, alleen leestoegang heeft, schrijftoegang niet toestaat en zeker geen toegang op systeemniveau.
  4. Als u niet erg ervaren bent in iets en het niet centraal staat in uw bedrijf, overweeg dan om het uit te besteden. Met andere woorden: als u een kleine website draait over het schrijven van de desktoptoepassingscode en besluit om kleine desktoptoepassingen vanaf de site te verkopen, overweeg dan om uw creditcardbestelsysteem uit te besteden aan iemand als Paypal.
  5. Maak, indien mogelijk, het uitvoeren van herstel van besmette systemen onderdeel van uw Rampenherstelplan. Dit is aantoonbaar gewoon een ander "rampscenario" dat je zou kunnen tegenkomen, gewoon eentje met een eigen reeks problemen en problemen die anders zijn dan de gebruikelijke 'serverruimte gevangen' / 'werd binnengevallen door gigantische server-eat-furbies'.

... En tenslotte

Ik heb waarschijnlijk geen einde gemaakt aan dingen die anderen belangrijk vinden, maar de bovenstaande stappen moeten je op zijn minst helpen om dingen uit te zoeken als je de pech hebt om het slachtoffer te worden van hackers.

Bovenal: geen paniek. Denk na voordat je iets doet. Handel goed nadat u een beslissing hebt genomen en laat een opmerking achter als u iets toe te voegen heeft aan mijn lijst met stappen.


988
2018-01-02 21:46



+1 voor een uitstekende post om bij de hand te hebben om mensen op weg te helpen. Ik weet hoe vaak het is dat beheerders van amateur-servers in de paniekmodus komen als ze de eerste keer dat ze een 'hack' tegenkomen. Het is een reusachtig fout om op die plek te zijn, maar het gebeurt. De hoop zou zijn dat dit niet tweemaal met dezelfde persoon zou gebeuren. - Andrew Barber
+1 "... maar dit is niet het moment om je ego in de weg te laten zitten van wat je moet doen." Dit is belangrijk voor Sys Admins om het soms te begrijpen. Het maakt niet uit hoe goed je bent, er zijn altijd die (soms kwaadwillende) die beter geïnformeerd of slim zijn dan jij. - Grahamux
Goed antwoord. Ik weet niet zeker waarom iedereen de "call law enforcement" -stap als optioneel beschouwt. Als u verantwoordelijk bent voor de gegevens van andere mensen (en u zich zorgen maakt over geschillen), moet dit een van de eerste dingen zijn die u op de lijst met dingen moet doen. - wds
Zeer goed geschreven, maar één ding is - "maak een volledige en openhartige onthulling aan iedereen die mogelijk in één keer wordt getroffen." Eervol, maar niet altijd correct. Als u een compromis wilt aangaan, moet u wellicht enkele hoeken van het beheer doorbreken en uw bedrijf zal u over het algemeen wat speling bezorgen, maar ... openbaarmaking of niet, met name wanneer er gevolgen zijn voor de gegevensbescherming, kan dit een kwestie zijn die hoger is dan uw salarisklasse en kan juridische implicaties hebben. Het is misschien beter om te suggereren dat u de persoon die verantwoordelijk is voor gegevensbescherming onmiddellijk op de hoogte stelt (als u dat niet bent) en URGE een volledige openbaarmaking. - TheoJones
@GilesRoberts-hosts voor virtuele machines hebben meestal een configuratiescherm waarmee u de instellingen van hun gasten kunt bewerken en zelfs op afstand kunt bedienen zonder gebruik te maken van RDP of SSH om u daadwerkelijk bij de gast aan te melden. Je zou in staat moeten zijn om de gast te isoleren met behulp van de knoppen van de host om dit te doen en dan de remote viewing tools gebruiken om de gast op je gemak te onderzoeken. - Rob Moir


Het klinkt alsof er iets boven je hoofd staat; dat is geen probleem. Bel je baas en begin te onderhandelen over een budget voor noodveiligheid. $ 10.000 is misschien een goed beginpunt. Dan moet je iemand (een PFY, een collega, een manager) krijgen om bedrijven te gaan noemen die zijn gespecialiseerd in het reageren op veiligheidsincidenten. Velen kunnen binnen 24 uur reageren en soms zelfs sneller als ze een kantoor in uw stad hebben.

Je hebt ook iemand nodig om klanten te triage; Ongetwijfeld is dat al zo. Iemand moet met hen telefoneren om uit te leggen wat er aan de hand is, wat er wordt gedaan om de situatie aan te pakken en om hun vragen te beantwoorden.

Dan moet je ...

  1. Blijf kalm. Als u verantwoordelijk bent voor het reageren op incidenten, moet u nu blijk geven van de grootst mogelijke professionaliteit en leiderschap. Documenteer alles wat u doet en houd uw leidinggevende en uitvoerende team op de hoogte van de belangrijkste acties die u onderneemt; dit omvat het werken met een reactieteam, het uitschakelen van servers, het maken van back-ups van gegevens en het weer online brengen van dingen. Ze hebben geen bloederige details nodig, maar ze zouden om de 30 minuten iets van je moeten horen.

  2. Wees realistisch. U bent geen beveiligingsprofessional en er zijn dingen die u niet weet. Dat is geen probleem. Wanneer u zich aanmeldt bij servers en gegevens bekijkt, moet u uw limieten kennen. Loop voorzichtig. Zorg er tijdens je onderzoek voor dat je niet stapt op vitale informatie of iets verandert dat later misschien nodig is. Als je je ongemakkelijk voelt of dat je vermoedt, is dat een goede plek om te stoppen en een ervaren professional te laten overnemen.

  3. Download een schone USB-stick en reserve harde schijven. Je verzamelt bewijsmateriaal hier. Maak back-ups van alles waarvan u denkt dat het relevant is; communicatie met uw ISP, netwerkstortingen, enz. Zelfs als politie en justitie niet betrokken raken, wilt u in dit geval bewijzen dat uw bedrijf het veiligheidsincident op een professionele en gepaste manier heeft afgehandeld.

  4. Het belangrijkste is om het verlies te stoppen. Identificeer en verbreek de toegang tot gecompromitteerde services, gegevens en machines. Bij voorkeur moet u aan hun netwerkkabel trekken; als je het niet kunt, trek dan aan de macht.

  5. Vervolgens moet je de aanvaller verwijderen en de hole (s) sluiten. Vermoedelijk heeft de aanvaller geen interactieve toegang meer omdat je het netwerk hebt getrokken. U moet nu identificeren, documenteren (met back-ups, schermafbeeldingen en uw eigen persoonlijke waarnemingsnotities, of bij voorkeur zelfs door de schijven van de getroffen servers te verwijderen en een volledige kopie van de schijfkopie te maken) en vervolgens alle code en processen verwijderen die hij heeft achtergelaten . Dit volgende deel zal zuigen als je geen back-ups hebt; Je kunt proberen de aanvaller met de hand uit het systeem te ontwarren, maar je zult nooit zeker zijn dat je alles wat hij achterliet hebt. Rootkits zijn wreed en niet allemaal detecteerbaar. Het beste antwoord is om de kwetsbaarheid te identificeren waarmee hij binnenkwam, afbeeldingskopieën van de getroffen schijven te maken en vervolgens de betreffende systemen te wissen en opnieuw te laden vanaf een bekende goede back-up. Vertrouw niet blind op uw back-up; verifieer het! Herstel of sluit het beveiligingslek voordat de nieuwe host weer verbinding maakt met het netwerk en breng het vervolgens online.

  6. Organiseer al uw gegevens in een rapport. Op dit punt is de kwetsbaarheid gesloten en heb je wat tijd om te ademen. Laat je niet verleiden om deze stap over te slaan; het is zelfs belangrijker dan de rest van het proces. In het rapport moet u vaststellen wat er mis is gegaan, hoe uw team heeft gereageerd en welke stappen u onderneemt om te voorkomen dat dit incident zich opnieuw voordoet. Wees zo gedetailleerd als je kunt; dit is niet alleen voor u, maar ook voor uw management en als verdediging in een mogelijk proces.

Dat is een hoogstaande beoordeling van wat te doen; het grootste deel van het werk bestaat gewoon uit documentatie en back-upverwerking. Geen paniek, je kunt dat spul doen. ik sterk raad aan om professionele beveiligingshulp te krijgen. Zelfs als je aankan wat er aan de hand is, is hun hulp van onschatbare waarde en ze komen meestal met apparatuur om het proces gemakkelijker en sneller te maken. Als je baas kost wat het kost, herinner hem eraan dat het erg klein is in vergelijking met het afhandelen van een rechtszaak.

Je hebt mijn troost voor je situatie. Succes.


199
2018-01-02 22:16



+1 Geweldig antwoord. Het lijkt erop dat het OP geen vooraf gedefinieerde "noodrespons" heeft en dat je bericht, naast andere goede dingen, hen moet wijzen op het instellen daarvan. - Rob Moir


CERT heeft een document Stappen voor het herstellen van een UNIX- of NT-systeemcompromis dat is goed. De specifieke technische details van dit document zijn enigszins verouderd, maar veel van het algemene advies is nog steeds direct van toepassing.

Een snel overzicht van de basisstappen is dit.

  • Raadpleeg uw beveiligingsbeleid of beheer.
  • Krijg controle (neem de computer offline)
  • Analyseer het binnendringen, krijg logs, stel vast wat er mis ging
  • Repareer spullen
    • Installeer een schone versie van uw besturingssysteem !!! Als het systeem is aangetast, kun je het niet vertrouwen, punt.
  • Update systemen zodat dit niet opnieuw kan gebeuren
  • Bewerkingen hervatten
  • Werk uw beleid voor de toekomst bij en documenteer

Ik zou u specifiek willen wijzen op deel E.1.

E.1.   Houd er rekening mee dat als een machine is   gecompromitteerd, alles op dat systeem   had kunnen worden gewijzigd, inclusief   de kernel, binaries, datafiles,   lopende processen en geheugen. In   algemeen, de enige manier om te vertrouwen dat een   machine is vrij van backdoors en   indringer wijzigingen is om opnieuw te installeren   de bediening

Als u niet beschikt over een systeem dat al op zijn plaats is, zoals tripwire, is er geen manier om 100% zeker te zijn dat u het systeem hebt opgeruimd.


105
2018-05-08 09:02



Zelfs dan kan tripwire voor de gek gehouden worden met kernelmodules en dergelijke. Installeer. - reconbot
De gerelateerde vraag over hoe te reageren in een crisis kan ook hier handig zijn. - Zoredache


  1. Identificeren het probleem. Lees de logs.
  2. Bevatten. Je hebt de server losgekoppeld, dus dat is klaar.
  3. uitroeien. Installeer het getroffen systeem waarschijnlijk opnieuw. Wis de harde schijf van de gehackte echter niet, gebruik een nieuwe. Het is veiliger en je hebt misschien de oude nodig om lelijke hacks te herstellen waarvan geen back-up is gemaakt en om forensics te doen om erachter te komen wat er is gebeurd.
  4. Herstellen. Installeer alles wat nodig is en herstel back-ups om uw klanten online te krijgen.
  5. Opvolgen. Zoek uit wat het probleem was en voorkom dat dit opnieuw gebeurt.

64
2018-01-02 21:49





Robert's 'bittere pil'-antwoord is duidelijk, maar volledig generiek (nou ja, zoals je vraag was). Het lijkt erop dat u een beheerprobleem hebt en dringend een fulltime sysadmin nodig hebt als u één server en 600 clients hebt, maar dat helpt u nu niet.

Ik run een hostingbedrijf dat in deze situatie een handje vasthoudt, dus ik werk met veel gecompromitteerde machines, maar we handelen ook in de beste praktijken voor de onze. We vertellen onze gecompromitteerde klanten altijd om opnieuw te bouwen, tenzij ze niet helemaal zeker zijn van de aard van een compromis. Er is op de lange termijn geen andere verantwoordelijke route.

Je bent echter vrijwel zeker het slachtoffer van een scriptkiddy die een lanceerplatform wilde voor DoS-aanvallen of IRC-bouncers, of iets dat totaal niets te maken had met de sites en gegevens van je klanten. Daarom is het een tijdelijke maatregel om tijdens het opnieuw opbouwen een zware uitgaande firewall op uw doos te plaatsen. Als u alle uitgaande UDP- en TCP-verbindingen kunt blokkeren die niet absoluut noodzakelijk zijn voor het functioneren van uw sites, kunt u uw gecompromitteerde box eenvoudig nutteloos maken voor degene die het van u leent, en het effect op het netwerk van uw provider tot nul terugbrengen.

Dit proces kan enkele uren duren als u dit nog niet eerder hebt gedaan en u nog nooit een firewall hebt overwogen, maar u wellicht kunt helpen de service van uw klanten te herstellen. met het risico de aanvaller toegang te blijven geven tot de gegevens van uw klant. Aangezien u zegt dat u honderden clients op één computer hebt, vermoed ik dat u kleine brochure-websites voor kleine bedrijven host, en niet 600 ecommerce-systemen vol met creditcardnummers. Als dat het geval is, kan dit een acceptabel risico voor u zijn en uw systeem sneller weer online krijgen dan 600 sites controleren op beveiligingsproblemen voor je brengt iets terug. Maar u zult weten welke gegevens er zijn en hoe comfortabel u die beslissing zou nemen.

Dit is absoluut niet de beste manier van werken, maar als dat niet is wat er tot nu toe bij uw werkgever is gebeurd, is het uw schuld (zij het niet gerechtvaardigd!) Dat u met uw vinger naar hen tuurt en tienduizenden ponden vraagt ​​voor een SWAT-team voor iets dat zij kunnen voelen. ) klinkt niet als de praktische optie.

De hulp van uw ISP hier zal behoorlijk cruciaal zijn - sommige ISP's een consoleserver en netwerkopstartomgeving bieden (plug, maar je weet tenminste wat voor faciliteit je moet zoeken) waarmee je de server kunt beheren terwijl je bent losgekoppeld van het netwerk. Als dit al een optie is, vraag ernaar en gebruik het.

Maar op de lange termijn moet u een systeemreconstructie plannen op basis van het bericht van Robert en een audit van elke site en de installatie ervan. Als u een sysadmin niet aan uw team kunt toevoegen, zoek dan een managed hosting deal waar u uw ISP betaalt voor hulp bij systeembehoud en 24-uurs respons voor dit soort dingen. Succes :)


49
2018-01-03 13:48





U moet opnieuw installeren. Bespaar wat je echt nodig hebt. Maar houd er rekening mee dat al uw uitvoerbare bestanden mogelijk zijn geïnfecteerd en gemanipuleerd. Ik schreef het volgende in python: http://frw.se/monty.py die MD5-sumbs van al je bestanden in een bepaalde map maakt en de volgende keer dat je het uitvoert, controleert het of er iets is gewijzigd en vervolgens wordt uitgevoerd welke bestanden zijn gewijzigd en wat er in de bestanden is gewijzigd.

Dit kan handig zijn voor u om te zien of vreemde bestanden regelmatig worden gewijzigd.

Maar het enige dat u nu zou moeten doen, is uw computer van internet verwijderen.


38
2018-05-08 08:02



Dus ... je hebt tripwire geïmplementeerd. - womble♦
Ja, daar is iets mis mee? - Filip Ekberg
+1 voor ontkoppelen, analyseren (zorg ervoor dat iemand echte forensisch onderzoek doet) en wis - Oskar Duveborn
Gegeven de keuze tussen een anoniem Python-script en een gedocumenteerde (enigszins) ondersteunde, goed begrepen standaardoplossing, hoop je dat ze het eerste zullen kiezen? - tripleee


NOTITIE: Dit is geen aanbeveling. Mijn specifiek Incident Response protocol waarschijnlijk niet is niet ongewijzigd van toepassing op de zaak van Unwin.

In onze academische faciliteiten hebben we ongeveer 300 onderzoekers die alleen computeren. Je hebt 600 klanten met websites, dus je protocol zal waarschijnlijk anders zijn.

De eerste stappen in onze Wanneer een server een beschadigd protocol krijgt is:

  1. Identificeer dat de aanvaller in staat was om root te verkrijgen (verhoogde privileges)
  2. Ontkoppel de betreffende server (s). Netwerk of kracht? Alsjeblieft zie een afzonderlijke discussie.
  3. Controleer alle andere systemen
  4. Start de getroffen server (s) op vanaf een live-cd
  5. (Optioneel) Pak de afbeeldingen van alle systeemstations vast met dd
  6. Begin met het post-mortem forensisch onderzoek. Kijk naar logs, zoek uit hoe laat het is en vind bestanden die in die tijd zijn aangepast. Probeer de Hoe? vraag.

    • Parallel, plan en voer je herstel uit.
    • Reset alle root- en gebruikerswachtwoorden voordat u de service hervat

Zelfs als "alle backdoors en rootkits opgeschoond worden", vertrouw dat systeem dan niet - installeer alles opnieuw.


34
2018-05-18 22:36



-1 Koppel de server los van de voeding? Je hebt zojuist de helft van je forensische gegevens verloren! - Josh Brower
@Josh, ik heb mijn antwoord aangepast - nu is het neutraal over de vraag Wat los te maken. - Aleksandr Levchuk
RAM-forensisch onderzoek (bijvoorbeeld / dev / shm) kan nuttig zijn. Ik geef de voorkeur aan het loskoppelen van de voedingskabel (maar probeer in te loggen en rsync / proc vlak voor). We kunnen ook frequente VM-snapshots introduceren, zodat RAM-forensisch onderzoek mogelijk zou zijn. De redenen om voor de stroomkabel te gaan zijn (1) wanneer je in een gehackt systeem forensics doet, "sta je overal op de plaats delict"; (2) De rootkit blijft actief - niet zo moeilijk voor kwaadwillenden om iets uit te voeren (bijvoorbeeld systeemuitveging) op Network Link Down evenement. Kyle Rankin in zijn mooie Intro to Forensics-gesprek (goo.gl/g21Ok) aanbevolen om aan de voedingskabel te trekken. - Aleksandr Levchuk
Er is geen one-size-fits-all IR-protocol - Sommige orgs moeten het gecompromitteerde systeem mogelijk nog een tijdje online houden, om welke reden dan ook. (RAM & temp log forensics, interactie met de indringers, enz.) Mijn punt is dat het beter zou zijn om een ​​generiek IR-protocol aan te bevelen (zoals Jakob Borgs hierboven) in plaats van een die begint met "Trek aan de stekker van de besmette server. " - Josh Brower


In mijn beperkte ervaring zijn systeemcompromissen op Linux vaak 'meeromvattend' dan op Windows. Het is waarschijnlijker dat de rootkits ook bestaan ​​uit het vervangen van systeem-binaries door aangepaste code om de malware te verbergen, en de drempel om de kernel hot-patching te geven is iets lager. Bovendien is dit het thuis-besturingssysteem voor veel malware-auteurs. De algemene leidraad is altijd om de betreffende server vanaf nul opnieuw op te bouwen, en het is de algemene richtlijn om een ​​reden.

Formatteer die puppy.

Maar als je niet kunt herbouwen (of de machthebbers in de toekomst zullen je niet laten herbouwen tegen je inspannende aandrang dat het het nodig heeft), waar kijk je dan naar?

Aangezien het lijkt alsof het een tijdje geleden is dat de inbraak werd ontdekt en er een systeemherstel is uitgevoerd, is het zeer waarschijnlijk dat de sporen van hoe ze zijn binnengekomen in de stormloop zijn omgegooid om de service te herstellen. Ongelukkige.

Ongebruikelijk netwerkverkeer is waarschijnlijk het gemakkelijkst te vinden, omdat er dan niets op de doos hoeft te worden uitgevoerd en dit kan worden gedaan terwijl de server actief is en alles doet. Aangenomen dat je netwerkuitrusting natuurlijk poortoverspannend is. Wat je vindt kan wel of niet diagnostisch zijn, maar het is tenminste informatie. Ongebruikelijk verkeer krijgen, is een sterk bewijs dat het systeem nog steeds wordt gehackt en moet worden afgevlakt. Het is misschien goed genoeg om TPTB ervan te overtuigen dat een herformulering echt, echt, de downtime waard is.

Als dat niet lukt, neemt u een kopie van uw systeempartities en koppelt u ze aan een andere box. Begin de inhoud te vergelijken met een server op hetzelfde patchniveau als de besmette. Het zou je moeten helpen identificeren wat er anders uitziet (die md5sums opnieuw) en kan wijzen naar over het hoofd gezien gebieden op de gecompromitteerde server. Dit is VEEL van het doorzoeken van mappen en binaries, en zal nogal arbeidsintensief zijn. Het kan zelfs meer arbeidsintensief zijn dan een herformattering / heropbouw zou zijn, en misschien een ander ding om TPTB over te slaan over het feitelijk doen van de herformulering die het echt nodig heeft.


28
2018-01-03 14:31



'Formaat die puppy.' - +1, wijze advies. Zie ook: "Haal het uit een baan, het is de enige manier om er zeker van te zijn." - Avery Payne


Ik zou zeggen @Robert Moir, @Aleksandr Levchuk, @blueben en @Matthew Bloch zijn allemaal behoorlijk goed in hun antwoorden.

De antwoorden van verschillende posters verschillen echter, sommige liggen meer op een hoog niveau en vertellen welke procedures u moet hebben (in het algemeen).

Ik zou dit liever in verschillende afzonderlijke delen opdelen 1) Triage, AKA Hoe om te gaan met de klanten en de juridische implicaties, en bepalen waar je naartoe gaat (zeer goed vermeld door Robert en @blueben 2) Beperking van impact 3) Incidentantwoord 4) Post-mortem forensisch onderzoek 5) Remediation-items en architectuurwijzigingen

(Insert boilerplate SANS GSC gecertificeerde antwoord verklaring hier) Op basis van ervaringen uit het verleden, zou ik het volgende zeggen:

Ongeacht hoe u reageert op de reacties van klanten, meldingen, juridische en toekomstige plannen, zou ik me het liefst concentreren op het hoofdthema. De oorspronkelijke vraag van het OP komt eigenlijk alleen rechtstreeks overeen met # 2 en # 3, in feite, hoe de aanval te stoppen, klanten zo snel mogelijk online te krijgen in hun oorspronkelijke staat, wat goed is weergegeven in de antwoorden.

De rest van de reacties is geweldig en behandelt een groot aantal geïdentificeerde best-practices en manieren om zowel te voorkomen dat het in de toekomst gebeurt als om er beter op te reageren.

Het hangt echt af van het budget van het OP en in welke bedrijfstak ze zitten, wat hun gewenste oplossing is, enz.

Misschien moeten ze een speciale onsite SA inhuren. Misschien hebben ze een beveiligingsmedewerker nodig. Of misschien hebben ze een volledig beheerde oplossing nodig, zoals Firehost of Rackspace Managed, Softlayer, ServePath etc.

Het hangt echt af van wat voor hun bedrijf werkt. Misschien is hun kerncompetentie niet in serverbeheer en het is niet logisch dat ze dat proberen te ontwikkelen. Of misschien zijn ze al een behoorlijk technische organisatie en kunnen ze de juiste beslissingen nemen en fulltime een toegewijd team aantrekken.


28
2018-01-04 02:21



Ja, het hangt ervan af, we weten het. Zeggen dat helpt niet echt veel. - DOK


Nadat we aan de slag waren gegaan en een kijkje hadden kunnen nemen bij de server, zijn we erin geslaagd om het probleem te achterhalen. Gelukkig zijn de aanstootgevende bestanden op zondag naar het systeem geüpload, wanneer het kantoor gesloten is en er geen bestanden mogen worden gemaakt, behalve logboeken en cachebestanden. Met een eenvoudige shell-opdracht om uit te vinden welke bestanden op die dag zijn gemaakt, hebben we ze gevonden.

Alle aanstootgevende bestanden lijken zich in de map / images / op sommige van onze oudere zencart-sites te bevinden. Het lijkt erop dat er een beveiligingskwetsbaarheid was die het mogelijk maakte (met behulp van krullen) elke idioot om niet-afbeeldingen te uploaden naar de sectie voor het uploaden van afbeeldingen in de admin sectie. We hebben de beledigende .php-bestanden verwijderd en de uploadscripts gerepareerd om bestandsuploads die geen afbeeldingen zijn, niet toe te staan.

Achteraf gezien was het vrij simpel en ik heb deze vraag op mijn iPhone naar voren gebracht op weg naar mijn werk. Bedankt voor al je hulp jongens.

Voor de referentie van iedereen die deze post in de toekomst bezoekt. ik zou niet raad aan de stekker uit het stopcontact te trekken.


24
2017-12-05 12:52



Grant, ik ben blij dat het voor jou heel soepel verliep. Het was iets kleins - veel minder serieus dan velen van ons dachten. Deze discussie leerde mij een les over communiceren, gaf veel goede tips en stof tot nadenken over onfatsoenlijke reacties. - Aleksandr Levchuk
Bedankt dat je terug bent gekomen en ons hebt laten weten hoe je het hebt gedaan. Zoals je ziet, heeft je vraag nogal wat discussie gegenereerd. Ik ben blij dat je hier niet te zwaar door geraakt lijkt te zijn en dat je oplossing uiteindelijk heel simpel was. - Rob Moir
Dit moet een opmerking zijn (of als tekst in uw vraag worden opgenomen), geen antwoord op uw vraag. - Techboy
@Techboy: Het lijkt erop dat hij zijn SO- en SF-accounts nog niet heeft gekoppeld, dus hij kan zijn vraag niet bewerken. @Grant: u kunt uw accounts koppelen via het paneel 'Accounts' op uw gebruikerspagina. - Hippo
zonder een basislijnconfiguratie, hoe weet u of u geen rootkit hebt uitgevoerd? - The Unix Janitor


Ik heb weinig om bij te dragen aan de uitgebreide technische antwoorden, maar let ook op enkele hiervan:

Niet-technische acties:

  • Meld het incident intern.
    Als u nog geen plan voor incidentenrespons heeft dat mogelijk een CYA-techniek lijkt, maar de IT-afdeling is niet de enige en vaak zelfs niet de beste plaats om de zakelijke impact van een gecompromitteerde server.
    Zakelijke vereisten kunnen uw technische zorgen overtroeven. Zeg niet "Ik heb het je gezegd" en dat de prioriteit van zakelijke zorgen de reden is dat je deze gecompromitteerde server in de eerste plaats hebt. ("Verlaat dat voor het vervolgverslag.")

  • Het afdekken van een veiligheidsincident is geen optie.

  • Rapportage aan lokale autoriteiten.
    ServerFault is NIET de plaats voor juridisch advies, maar dit is iets dat moet worden opgenomen in een incidentresponsenplan.
    In sommige plaatsen en / of gereguleerde industrieën is het verplicht om (bepaalde) veiligheidsincidenten te rapporteren aan lokale wetshandhavingsinstanties, regelgevende instanties of om getroffen klanten / gebruikers te informeren.
    Hoe dan ook, noch de beslissing om te rapporteren, noch het eigenlijke rapport wordt uitsluitend op de IT-afdeling gemaakt. Verwacht betrokkenheid van het management en de afdelingen juridische en zakelijke communicatie (marketing).
    Je moet waarschijnlijk niet te veel verwachten, internet is een grote plaats waar grenzen weinig betekenis hebben, maar de cybercrime-afdelingen die op veel politiediensten bestaan, lossen digitale misdaden op en brengen de schuldigen voor de rechter.


15
2017-09-11 06:50