Hur ofta köper du något spontant, faller för cool reklam, och sedan samlar den här först önskade saken damm i en garderob, skafferi eller garage inför nästa storstädning eller flytt? Som ett resultat, besvikelse på grund av orealistiska förväntningar och bortkastade pengar. Det är mycket värre när detta händer med ett företag. Alltför ofta är marknadsföringsknep så bra att företag köper en dyr lösning utan att se hela bilden av dess tillämpning. Samtidigt hjälper provtestning av systemet att förstå hur man förbereder infrastrukturen för integration, vilken funktionalitet och i vilken utsträckning som bör implementeras. Så du kan undvika ett stort antal problem på grund av valet av produkten "blindt". Dessutom kommer implementering efter en kompetent "pilot" att ge ingenjörer mycket mindre förstörda nervceller och grått hår. Låt oss se varför pilottestning är så viktigt för ett framgångsrikt projekt, med hjälp av exemplet på ett populärt verktyg för att kontrollera åtkomst till ett företagsnätverk - Cisco ISE. Överväg både typiska och helt icke-standardiserade alternativ för att tillämpa den lösning som vi stött på i vår praktik.
Cisco ISE - Radius Server på stereo
Cisco Identity Services Engine (ISE) är en plattform för att skapa ett åtkomstkontrollsystem för en organisations lokala nätverk. I expertgemenskapen fick produkten smeknamnet "Radius-servern på steroider" för sina egenskaper. Varför är det så? I huvudsak är lösningen en Radius-server, till vilken ett stort antal ytterligare tjänster och "chips" är kopplade, vilket gör att du kan ta emot en stor mängd kontextuell information och tillämpa den resulterande uppsättningen av data i åtkomstpolicyer.
Precis som alla andra Radius-servrar interagerar Cisco ISE med nätverksutrustning på åtkomstnivå, samlar in information om alla försök att ansluta till företagets nätverk och, baserat på autentiserings- och auktoriseringspolicyer, tillåter eller tillåter inte användare att komma åt LAN. Möjligheten till profilering, schemaläggning, integration med andra informationssäkerhetslösningar kan dock avsevärt komplicera logiken i behörighetspolicyn och därmed lösa ganska svåra och intressanta uppgifter.
Implementering kan inte testas: varför behöver vi tester?
Värdet med pilottestning är att visa alla funktioner i systemet i en specifik infrastruktur i en specifik organisation. Jag är övertygad om att pilotering av Cisco ISE före implementering är fördelaktigt för alla projektdeltagare, och här är varför.
För integratörer ger detta en tydlig uppfattning om kundens förväntningar och hjälper till att bilda de korrekta referensvillkoren, som innehåller mycket mer detaljer än den vanliga frasen "få allt att gå bra." "Pilot" låter oss känna all smärta hos kunden, att förstå vilka uppgifter som är prioriterade för honom och vilka som är sekundära. För oss är detta ett utmärkt tillfälle att i förväg ta reda på vilken utrustning som används i organisationen, hur implementeringen kommer att ske, på vilka platser, var de finns osv.
Kunder, under pilottestning, se det verkliga systemet i aktion, bekanta sig med dess gränssnitt, kan kontrollera om det är kompatibelt med deras befintliga hårdvara och få en helhetsbild av hur lösningen kommer att fungera efter fullständig implementering. "Piloten" är själva ögonblicket då du kan se alla "fallgropar" som du förmodligen kommer att stöta på under integrationen, och bestämma hur många licenser du behöver köpa.
Vad kan "uppstå" under "piloten"
Så hur förbereder du dig för en Cisco ISE-implementering? Av vår erfarenhet har vi räknat till 4 huvudpunkter som är viktiga att tänka på i processen med att pilottesta systemet.
Formfaktor
Först måste du bestämma i vilken formfaktor systemet ska implementeras: fysisk eller virtuell upline. Varje alternativ har fördelar och nackdelar. Styrkan hos en fysisk upline är till exempel förutsägbar prestanda, men vi får inte glömma att sådana enheter blir föråldrade med tiden. Virtuella uplines är mindre förutsägbara eftersom beror på hårdvaran som virtualiseringsmiljön är utplacerad på, men samtidigt har de ett stort plus: om det finns stöd kan de alltid uppdateras till den senaste versionen.
Är din nätverksutrustning kompatibel med Cisco ISE?
Naturligtvis skulle det idealiska scenariot vara att ansluta all utrustning till systemet på en gång. Detta är dock inte alltid möjligt, eftersom många organisationer fortfarande använder ohanterade switchar eller switchar som inte stöder vissa av de teknologier som Cisco ISE körs på. Det handlar för övrigt inte bara om switchar, det kan även vara trådlösa nätverkskontroller, VPN-koncentratorer och all annan utrustning som användarna ansluter till. I min praktik fanns det fall när kunden, efter att ha demonstrerat systemet för fullständig implementering, uppgraderat nästan hela flottan av åtkomstnivåväxlar till modern Cisco-utrustning. För att undvika obehagliga överraskningar är det värt att i förväg ta reda på andelen utrustning som inte stöds.
Är alla dina enheter generiska?
I alla nätverk finns det typiska enheter som inte borde vara svåra att ansluta: arbetsstationer, IP-telefoner, Wi-Fi-åtkomstpunkter, videokameror och så vidare. Men det händer också att icke-standardiserade enheter måste anslutas till LAN, till exempel RS232 / Ethernet-busssignalomvandlare, avbrottsfri strömförsörjningsgränssnitt, olika teknisk utrustning etc. Det är viktigt att bestämma listan över sådana enheter i förväg så att du redan vid implementeringsstadiet har en förståelse för hur tekniskt de kommer att fungera med Cisco ISE.
Konstruktiv dialog med IT-specialister
Säkerhetsavdelningar fungerar ofta som Cisco ISE-kunder, medan IT-avdelningar vanligtvis ansvarar för att konfigurera åtkomstlagerswitchar och Active Directory. Därför är den produktiva interaktionen mellan säkerhets- och IT-specialister en av de viktiga förutsättningarna för en smärtfri implementering av systemet. Om de senare uppfattar integrationen "med fientlighet", är det värt att förklara för dem hur lösningen kommer att vara användbar för IT-avdelningen.
Topp 5 Cisco ISE Användningsfall
Enligt vår erfarenhet avslöjas den nödvändiga funktionaliteten hos systemet också vid pilottestningsstadiet. Nedan är några av de mest populära och mindre vanliga användningsfallen för lösningen.
Säker LAN-åtkomst över tråden med EAP-TLS
Enligt forskningsresultaten från våra pentestare använder angripare ganska ofta vanliga uttag som skrivare, telefoner, IP-kameror, Wi-Fi-punkter och andra icke-personliga nätverksenheter är anslutna till för att penetrera ett företags nätverk. Därför, även om nätverksåtkomst baseras på dot1x-teknik, men alternativa protokoll används utan användning av användarautentiseringscertifikat, finns det stor sannolikhet för en framgångsrik attack med sessionsavlyssning och brute force med lösenord. I fallet med Cisco ISE kommer det att vara mycket svårare att bruta ett certifikat - för detta kommer hackare att behöva mycket mer datorkraft, så det här fallet är mycket effektivt.
Trådlös Dual-SSID
Kärnan i detta scenario är att använda 2 nätverksidentifierare (SSID). En av dem kan villkorligt kallas "gäst". Genom den kan både gäster och anställda på företaget komma in i det trådlösa nätverket. De senare, när de försöker ansluta, omdirigeras till en speciell portal där provisionering sker. Det vill säga, ett certifikat utfärdas till användaren och hans personliga enhet konfigureras för att automatiskt återansluta till det andra SSID, som redan använder EAP-TLS med alla fördelar i det första fallet.
MAC Authentication Bypass och profilering
Ett annat populärt fall är att automatiskt upptäcka typen av ansluten enhet och tillämpa rätt begränsningar på den. Varför är han intressant? Faktum är att det fortfarande finns en hel del enheter som inte stöder 802.1X-autentisering. Därför måste du släppa in sådana enheter i nätverket med MAC-adress, vilket är ganska lätt att fejka. Det är här Cisco ISE kommer till undsättning: med hjälp av systemet kan du se hur en enhet beter sig i nätverket, skapa en profil för den och associera en grupp andra enheter till den, till exempel en IP-telefon och en arbetsstation. Om en angripare försöker förfalska MAC-adressen och ansluta till nätverket kommer systemet att se att enhetsprofilen har ändrats, signalera misstänkt beteende och hindra den misstänkta användaren från att komma åt nätverket.
EAP-kedja
EAP-Chaining-teknik involverar sekventiell autentisering av arbetsdatorn och användarkontot. Detta fall har blivit utbrett, eftersom. många företag välkomnar fortfarande inte anslutningen av anställdas personliga prylar till företagets LAN. Med den här metoden för autentisering kan du kontrollera om en viss arbetsstation är medlem i en domän, och om resultatet är negativt kommer användaren antingen inte in i nätverket eller kommer in, men med vissa begränsningar.
Ställande
I det här fallet talar vi om att bedöma överensstämmelsen med sammansättningen av arbetsstationsprogramvaran med kraven på informationssäkerhet. Med den här tekniken kan du kontrollera om programvaran är uppdaterad på arbetsstationen, om skyddsverktyg är installerade på den, om värdbrandväggen är konfigurerad, etc. Intressant nog låter den här tekniken dig också utföra andra icke-säkerhetsuppgifter, som att kontrollera om det finns nödvändiga filer eller installera systemomfattande programvara.
Mindre vanliga är också Cisco ISE-användningsfall såsom åtkomstkontroll med end-to-end domänautentisering (Passiv ID), SGT-baserad mikrosegmentering och filtrering, samt integration med mobila enhetshanteringssystem (MDM) och sårbarhetsskannrar ( Vulnerability Scanner).
Icke-standardiserade projekt: varför skulle du annars behöva Cisco ISE, eller 3 sällsynta fall från vår praktik
Styr åtkomst till Linux-baserade servrar
När vi en gång löste ett ganska icke-trivialt fall för en av kunderna som redan hade implementerat Cisco ISE-systemet: vi behövde hitta ett sätt att kontrollera användaråtgärder (främst administratörer) på servrar med Linux installerat. På jakt efter ett svar kom vi på idén att använda gratisprogramvaran PAM Radius Module, som låter dig logga in på servrar som kör Linux med autentisering på en extern radiusserver. Allt i detta avseende skulle vara bra om inte för ett "men": när du skickar ett svar på en autentiseringsbegäran, returnerar radiusservern endast kontonamnet och resultatet - bedömning accepterad eller bedömning avvisad. Under tiden, för auktorisering i Linux, måste du tilldela minst en parameter till - hemkatalog, så att användaren åtminstone kommer någonstans. Vi hittade inget sätt att skicka detta som ett radieattribut, så vi skrev ett speciellt skript för att skapa fjärrkonton på värdar i halvautomatiskt läge. Denna uppgift var ganska genomförbar, eftersom vi hade att göra med administratörskonton, vars antal inte var så stort. Därefter gick användarna till den nödvändiga enheten, varefter de tilldelades nödvändig åtkomst. En rimlig fråga uppstår: är det nödvändigt att använda Cisco ISE i sådana fall? Faktum är att nej - vilken radieserver som helst duger, men eftersom kunden redan hade detta system lade vi helt enkelt till en ny funktion till det.
Hård- och mjukvaruinventering på LAN
En gång arbetade vi med ett projekt för att leverera Cisco ISE till en kund utan en preliminär "pilot". Det fanns inga tydliga krav på lösningen, plus allt vi hade att göra med ett platt, icke-segmenterat nätverk, vilket komplicerade vår uppgift. Under projektets gång konfigurerade vi alla möjliga profileringsmetoder som nätverket stödde: NetFlow, DHCP, SNMP, AD-integration, etc. Som ett resultat konfigurerades MAR-åtkomst med möjligheten att komma in i nätverket om autentiseringen misslyckades. Det vill säga, även om autentiseringen inte lyckades, släppte systemet fortfarande in användaren i nätverket, samlade in information om honom och registrerade den i ISE-databasen. Denna övervakning av nätverket under flera veckor hjälpte oss att isolera anslutna system och icke-personliga enheter och utveckla ett tillvägagångssätt för att segmentera dem. Efter det ställer vi dessutom in post-schering för att installera agenten på arbetsstationer för att samla in information om programvaran som är installerad på dem. Vad är resultatet? Vi lyckades segmentera nätverket och fastställa listan över programvara som behövde tas bort från arbetsstationerna. Jag ska inte dölja de ytterligare uppgifterna med att fördela användare efter domängrupper och avgränsa åtkomsträttigheter tog oss ganska mycket tid, men på så sätt fick vi en komplett bild av vilken hårdvara kunden hade på nätverket. Det var förresten inte svårt på grund av det goda arbetet med att profilera ur lådan. Nåväl, och där profilering inte hjälpte, tittade vi själva och lyfte fram switchporten som utrustningen var ansluten till.
Fjärrinstallation av programvara på arbetsstationer
Det här fallet är ett av de konstigaste i min erfarenhet. När en kund kontaktade oss med ett rop på hjälp - något gick fel under implementeringen av Cisco ISE, allt gick sönder, och ingen annan kunde komma åt nätverket. Vi började förstå och fick reda på följande. Företaget hade 2000 XNUMX datorer som, i avsaknad av en domänkontrollant, hanterades från ett administratörskonto. I schemaläggningssyfte implementerade organisationen Cisco ISE. Det var nödvändigt att på något sätt förstå om ett antivirus var installerat på de befintliga datorerna, om mjukvarumiljön uppdaterades etc. Och eftersom IT-administratörer tog in nätverksutrustning i systemet är det logiskt att de hade tillgång till den. Efter att ha sett hur det fungerar och efterschemalagt sina datorer, kom administratörerna på idén att installera programvara på anställdas arbetsstationer på distans utan personliga besök. Föreställ dig bara hur många steg du kan spara på en dag! Administratörerna utförde flera kontroller av arbetsstationen för närvaron av en viss fil i C: Program Files-katalogen, och om den saknades, startade automatisk åtgärdande med en länk som ledde till fillagringen till .exe-installationsfilen. Detta gjorde det möjligt för vanliga användare att gå till filbollen och ladda ner nödvändig programvara därifrån. Tyvärr kände administratören inte till ISE-systemet väl och skadade post-schering-mekanismerna – han skrev policyn felaktigt, vilket ledde till problemet som vi var med och löste. Personligen är jag uppriktigt förvånad över ett sådant kreativt tillvägagångssätt, eftersom det skulle vara mycket billigare och mindre arbetskrävande att skapa en domänkontrollant. Men som Proof of concept fungerade det.
Läs mer om de tekniska nyanserna som uppstår när du implementerar Cisco ISE i min kollegas artikel .
Artem Bobrikov, designingenjör, informationssäkerhetscenter, Jet Infosystems
efterordet:
Trots att det här inlägget talar om Cisco ISE-systemet är de beskrivna problemen relevanta för hela klassen av NAC-lösningar. Det är inte så viktigt vilken leverantörs lösning som är planerad att implementeras - det mesta av ovanstående kommer att förbli tillämpligt.
Källa: will.com