Welke dingen kunnen worden gedaan om te voorkomen dat plotselinge malafide insiders een negatieve invloed hebben op essentiële infrastructuur met behulp van technieken die ze mogen gebruiken?

In de praktijk heel weinig . Maar om uit te leggen waarom, laat me het hebben over wat u kunt doen.

Het probleem hier is dat de gebruiker "geprivilegieerd" is - ze hebben de macht legitiem gekregen.

Er zijn enkele dingen die kunnen worden gedaan om de macht die aan legitieme gebruikers wordt gegeven te beperken, zelfs aan bevoorrechte beheerders:

• Controle over beschikbare commando's met zoiets als sudo of PowerBroker.
• Dubbele controle (de "twee-man regel" @ paj28 beschrijft
• Workflow-controles (wat vaak een vorm van dubbele controle is)

Nu worden deze controles veel minder gebruikt dan ze zouden kunnen zijn. Waarom? Omdat bevoorrechte gebruikers per definitie worden vertrouwd . Dus ik zeg heel weinig , niet omdat er geen controles zijn, maar omdat de kosten-batenverhouding van dergelijke controles bij toepassing op vertrouwd personeel niet voldoende is om het te rechtvaardigen.

Merk ook op dat de aanvalsvector hier 'in het sanitair' was - als Citibank dubbele bediening heeft, zijn ze waarschijnlijk concentreerde zich op zaken als overboekingen, terwijl deze aanval op de knieën kwam en het onderliggende netwerk gewoon platlegde. Deze essentiële maar stille systemen hebben vaak kleinere kringen van bevoorrechte gebruikers en minder buitensporige controles.

De echte mislukking hier was niet dat er geen technische controles waren, maar dat de personeelscontrole jammerlijk faalde. Het is standaardpraktijk om de toegang van bevoorrechte werknemers in te trekken voordat ze worden beëindigd. Degene die besloot dat een dergelijke voorzorgsmaatregel niet nodig was bij het introduceren van een conflict met een bevoorrechte werknemer, gebruikte een slecht beoordelingsvermogen.

(Het bedrijf paste ook bestraffende controles toe - de aanvaller is nu veroordeeld tot bijna 2 jaar gevangenisstraf en moet bijna $ 80.000 betalen. Zoals het artikel aangeeft, lossen die dingen dit allemaal niet op.)

Twee-man regel - configureer uw systemen zodat voor alle geprivilegieerde toegang twee mensen nodig zijn.

Dit kan een fysieke controle zijn - geprivilegieerde toegang kan alleen komen van het NOC, en binnen het NOC handhaven mensen de regel fysiek.

Praktischer zou een scriptsysteem zijn. Sys-admins hebben niet rechtstreeks root-toegang, maar ze kunnen scripts indienen om als root te worden uitgevoerd. Ze worden alleen uitgevoerd nadat een afzonderlijke persoon het script heeft beoordeeld en goedgekeurd. Er zou nog steeds een methode moeten zijn voor SSH-toegang in geval van nood - en de tweemansregel zou in dat geval kunnen worden gehandhaafd met behulp van fysieke controles.

De NSA heeft dit geïmplementeerd na de Snowden lekt. Ik heb nog nooit een volledig tweemansysteem gezien in een van de commerciële of overheidssystemen die ik heb gecontroleerd - hoewel ik verschillende deelpogingen heb gezien.

Update - er is meer informatie over hoe u dit kunt implementeren op een afzonderlijke vraag.

Een van de manieren is om te accepteren dat malafide acties niet kunnen worden voorkomen en ervoor te zorgen dat de schade kan worden hersteld. Zorg er bijvoorbeeld voor dat de routers een apart besturingsvlak hebben waarmee ze weer online kunnen worden gebracht. Zorg ervoor dat je alleen-lezen back-ups hebt (bijv. Off-site tapes), dus als iemand alle harde schijven wist, kun je de gegevens herstellen. Zorg ervoor dat gegevens en code snel kunnen worden teruggedraaid naar een bekende goede staat.

Deze voorzorgsmaatregelen zullen ook veel helpen in het geval van onopzettelijke fouten.

Audit. In het bijzonder netwerkverkeer en uitgevoerde acties / bewerkingen op bepaalde machines. U wilt wie deed wat , wanneer ze het deden en van waar . Hoewel dit een aanval niet zal voorkomen, zal het helpen om dergelijke acties af te schrikken als de insider denkt dat ze zullen worden geïdentificeerd en gepakt.

Dan moet je ingaan op de kwestie van fraudebestendige controlemechanismen.

De kwestie van het beschermen van een systeem of netwerk tegen een insider, in het bijzonder tegen de mensen wiens eigen taakomschrijving het creëren en beheren van een dergelijk systeem omvat, is altijd een lastige geweest.

Ten eerste, wat je moet begrijpen is dat het uiteindelijk volledig onmogelijk is om alle soorten aanvallen op een infrastructuur van binnenuit te voorkomen, omdat dat zou betekenen dat elk contact met de infrastructuur wordt beperkt, waardoor het bijzonder nutteloos wordt.

Er zijn echter manieren waarop we schade aan het systeem kunnen voorkomen en minimaliseren. Persoonlijk erken ik voor dit proces dat er drie fasen zijn:

1. De tweemansregel
2. De verantwoordingsregel
3. Arbeidsverdeling

Deze processen vullen elkaar aan om elk systeem te beschermen tegen indringers die van binnenuit werken.

The Two-Man Rule

Laten we beginnen met de meest voor de hand liggende regel, de tweemansregel. Een belangrijk onderdeel van IT- en infrastructuurbeveiliging is ervoor te zorgen dat al het gedrag binnen het systeem identificeerbaar en gewenst is. Dit impliceert dat elke actie die binnen het systeem wordt ondernomen trusted is.

Als ik een voorbeeld hiervan laat zien, is mijn favoriete manier van uitleggen het Git-systeem van Forking and Pulling. In Git kan iedereen met toegang tot de repository (in dit geval The Infrastructure) een kopie maken. Vervolgens kunnen mensen met toegang een verzoek indienen om hun code in de repository op te halen. Om dit echter te laten gebeuren, moet de getrokken code worden geanalyseerd, gemarkeerd als compatibel en vervolgens geautoriseerd door iemand anders.

Hetzelfde kan worden gezegd en gedaan voor een beveiligde infrastructuur. Alle managementpersoneel kan de code wijzigen, maar om de wijzigingen in productie te laten gaan, moeten ze worden goedgekeurd door een of meer personeelsleden.

The Accountability Rule

Een ander veelvoorkomend probleem met bepaalde typen systemen en netwerken is dat er één beheeraccount is waarvan het wachtwoord bekend is bij alle leden met toegang. Het eerste probleem met verantwoording wordt hier aan de orde gesteld. Veel bedrijven vertrouwen in situaties waarin malafide leden ongeautoriseerde wijzigingen in de server aanbrengen, op primitieve methoden, zoals het controleren van het IP-adres van de machine, om te achterhalen wie mogelijk wijzigingen in het systeem heeft gepubliceerd. Dit kan eenvoudig worden opgelost door ervoor te zorgen dat iedereen zijn eigen account heeft en hen ervan bewust te maken dat hun wijzigingen worden gelogd.

Zoals vermeld in de laatste paragraaf, is loggen het tweede probleem. In dit geval komt de kwestie van vertrouwen weer aan de oppervlakte. Aangezien het lid vertrouwd is om bepaalde wijzigingen aan het systeem aan te brengen, registreert het systeem in de meeste gevallen de acties van de gebruiker niet goed.

Deze situatie is het perfecte punt om actie-verantwoording te implementeren . De beheergebruiker moet zich ervan bewust zijn dat niet alleen zijn / haar acties te allen tijde worden gevolgd tijdens het aanpassen van de infrastructuur, maar dat ze ook contractgebonden verantwoordelijkheden en sancties zullen hebben voor opzettelijke acties.

Arbeidsverdeling

Dit is een ander over het hoofd gezien concept in de meeste managementfuncties voor IT-infrastructuur. IT-teams hebben de neiging om hun taken te verdelen, maar het is niet ongebruikelijk dat de meeste gebruikers toegang hebben om elke taak uit te voeren.

De beste manier om dit te voorkomen is door specifieke systeembeheertaken toegewezen aan slechts twee personen (om gevallen te voorkomen waarin één persoon niet beschikbaar is). Terwijl andere gebruikers nog steeds wijzigingen kunnen verifiëren en goedkeuren, met behulp van de tweemansregel , kan slechts een handvol gebruikers die wijzigingen daadwerkelijk starten.

Persoonlijke suggestie

Een persoonlijke favoriete manier om systeembrede beveiliging te implementeren, vooral in grote zakelijke omgevingen, is het gebruik van 3 serversets. Alpha, Beta en Production, de eerste twee zijn een kloon van de laatste. Iedereen kan wijzigingen naar Alpha verplaatsen, we gebruiken dit systeem om te testen hoe het zou reageren in Productie. Beta is voor wijzigingen die zijn getest en klaar zijn om te worden geïmplementeerd. Om dit stadium te bereiken, moeten verschillende leden (~ 5) van de IT-afdeling de wijziging goedkeuren. In deze fase documenteert de IT-afdeling ook de wijzigingen en stuurt deze naar het management en als memo naar IT. Om Production te bereiken, moeten 3 vooraanstaande managementleden de wijziging goedkeuren met hun eigen accounts, die niet toegankelijk zijn voor de IT-afdeling.

Laatste opmerking

Zoals je misschien hebt opgemerkt, is dit geen gemakkelijk proces. Het implementeren van veel van deze ideeën zal de productie vertragen. Dit is een van de wezenlijke vragen van beveiliging. Hoe veiliger een systeem is, hoe moeilijker het wordt om te veranderen en aan te passen. Om uw bedrijf productief te maken, moet u een balans vinden tussen Beveiliging en Vertrouwen .

Door ervoor te zorgen dat commando's die de infrastructuur op zo'n manier negatief beïnvloeden, niet op afstand kunnen worden benaderd, kunnen alleen lokaal worden uitgevoerd.

Dit kan op meerdere manieren worden bereikt. Bijvoorbeeld de opdracht afsluiten niet toestaan. Een andere manier is om een ​​watchdog te hebben (hardwareapparaat dat verandering in beschikbaarheid detecteert) die de genoemde infrastructuur herstart of een herstelprocedure uitvoert als de infrastructuur onbereikbaar wordt.

Een derde manier is om externe toegang te verzekeren, door bijvoorbeeld bijvoorbeeld door KVM-Over-IP-oplossingen te gebruiken en deze bronnen vervolgens te koppelen aan besturingselementen die alleen ter plaatse kunnen worden gemanipuleerd. Dus als de infrastructuur plat ligt, kan deze gemakkelijk op afstand worden hersteld.

Natuurlijk is het belangrijk om back-ups te hebben van configuratiebestanden, belangrijke systemen en dergelijke. Aangezien configuratiebestanden zelden worden gewijzigd, zou ik zeggen dat een back-up van configuratiebestanden goed zou zijn om te doen na elke configuratiewijziging waarvan wordt besloten dat deze moet worden vastgelegd.

In het geval dat de infrastructuur moet worden losgekoppeld vanwege kritieke beveiligingsgebeurtenissen kan een noodsysteem worden gebruikt, dat de infrastructuur op een zodanige manier ontkoppelt dat het gemakkelijk door het management kan worden hersteld, zonder dat een bezoek ter plaatse nodig is.

Het probleem hier was echt niet die malafide medewerker. Wat als die werknemer precies hetzelfde deed, maar dan als een fout. Laten we zeggen dat het zijn bedoeling was om een ​​defect netwerkapparaat te repareren, zich niet realiserend dat de apparatuur offline zal worden gehaald na het wissen van een configuratie, en doet dat specifieke code &-commando dat in de vraag wordt genoemd, met de bedoeling om het configuratiebestand opnieuw te maken nadat het is gewist. gewist, maar na het uitvoeren van het commando, realiserend "oeps, kan geen verbinding meer maken met het apparaat".

En dus dezelfde soort schade veroorzaakt? Geloof me, ik heb dezelfde fout gemaakt, meestal met mijn eigen systemen, waarvoor ik toen de fysieke locatie van de apparatuur moest bezoeken. (maar in dat geval waren de dingen niet kritiek, maar als de systemen kritiek zijn, zou je er iets aan moeten doen)

Daarom moeten er beveiligingen bestaan, dus het is onmogelijk om dat soort schade op afstand te veroorzaken , opzettelijk of niet.

Veel goede antwoorden hier, maar een die lijkt te ontbreken, is het Principle of Least Privilege (PoLP) omarmen. Als er geen legitiem gebruik is om de configuratiebestanden van de router te wissen, geef dan niemand toegang om dat te doen. Als er een legitieme use-case is, maar deze niet relevant is voor de dagelijkse activiteiten, moet u een goedkeuringsproces vereisen (en controleren) om dat privilege te verkrijgen (dit is in feite een variatie op de twee-man-regel die alleen van toepassing is op vooral gevoelige operaties).

Er zijn ook back-ups en fail-safes. Om het oorspronkelijke voorbeeld te nemen: als de configuratie van een router wordt gewist, moet deze terugkeren naar een niet-verwijderbare, failsafe-configuratie (en alarm slaan). Dit moet ook gebeuren als het een interne gezondheidscontrole niet doorstaat. Als alternatief, als u gezondheidscontroles heeft, kunt u het systeem laten terugkeren naar een "laatst bekende goede" -configuratie, in wezen zichzelf herstellen vanaf een back-up als er iets misgaat. Schrijftoegang tot deze failsafe / back-ups / gezondheidscontroles moet onder extreem strenge beveiliging staan ​​- niemand zou dagelijkse privileges voor hen moeten hebben, of dergelijke privileges gemakkelijk kunnen krijgen - zodat zelfs de meesten zeer vertrouwde insider kan ze niet eenzijdig omzeilen of overschrijven.

Uiteraard zullen al deze oplossingen kosten met zich meebrengen. Er is bijna altijd een afweging tussen beveiliging en het besteden van middelen (meestal omschreven als "gemak", maar de middelen kunnen ook tijd en / of geld zijn). Echt goede PoLP betekent dat niemand echte root (god-level) toegang krijgt tot iets, bijvoorbeeld, wat dingen vertraagt ​​voor mensen die waarschijnlijk kunnen worden vertrouwd met zoveel toegang (je kunt nooit echt weten ). Failsafe-code is moeilijker te schrijven dan code die alleen maar vertrouwt op alle commando's die worden ingevoerd vanuit een "betrouwbare" bron, zelfs als dat commando HCF is. Paranoia heeft zijn prijs ... maar die prijs kan wel eens lager zijn dan wat hij kost als je 90% van je netwerkconnectiviteit verliest.

Een enkele werknemer mag nooit de macht hebben om dergelijke wijdverspreide schade aan te richten. Dergelijke administratieve handelingen moeten altijd authenticatie door twee of meer afzonderlijke beheerders vereisen, waarbij het authenticatiesysteem alleen kan worden uitgeschakeld door de beheerders op het hoogste niveau.

In het geval dat het al is gebeurd, zou de werkgever elk recht om de werknemer te ontslaan.

In elk bedrijf dat ik heb gezien, waren er ook zeer strikte interne beveiligingsregels. We konden niets zien van andere projecten, alleen onze eigenlijke taken.

Als we tussen projecten / afdelingen verhuisden, werden onze rechten altijd nauwkeurig afgesteld.

Slechts een beperkt aantal van de sysadmins hadden toegang tot grote delen van de infrastructuur, ze werkten daar allemaal minimaal 5-10 jaar. Waarschijnlijk had niemand toegang tot het hele netwerk.

iets verbinden met het bedrijfsnetwerk zonder expliciete toestemming (het was zelfs hopeloos om dat te vragen) was altijd strikt verboden. Nadat ik mijn smartphone op de usb-poort had aangesloten (alleen om hem te laden), werd ik binnen 5 minuten door mijn collega gevraagd wat ik aan het doen was.

Onze computers / laptops werden aan ons gegeven, vooraf geïnstalleerd met de bedrijfscertificaten. Nadat we het bedrijf hadden verlaten, hebben we ze teruggegeven.

Er waren regelmatig veiligheidscontroles, deze werden gedaan door een extern bedrijf (-> niemand wist wat en hoe ze het deden). Ook onze software die we produceerden, werd door hen onderzocht.

Wat we hebben gedaan op het bedrijfsnetwerk, werd waarschijnlijk geregistreerd en geback-upt tot de etherniteit.

Als we dat hadden gedaan twijfelachtig, wisten we niet, hoe zullen logboeken worden opgeslagen en onderzocht. Nadat we het bedrijf hadden verlaten, werden onze computers ook op veiligheid gecontroleerd door het externe bedrijf, en waarschijnlijk werd er een back-up op sectorniveau gemaakt voor het geval van een later opkomend "probleem", om als bewijs te dienen.