Hvor ofte køber du noget spontant, grebet af fantastisk reklame, og så ligger den oprindeligt ønskede ting bare og samler støv i skabet, i kælderen eller i garagen, indtil der er en stor oprydning eller flytning? Resultatet er skuffelse over urealistiske forventninger og spildte penge. Det er meget værre, når det samme sker i erhvervslivet. Ofte er marketingtricks så gode, at virksomheder køber dyre løsninger uden at se det fulde billede af deres anvendelse. Et prøveforløb kan dog hjælpe med at forstå, hvordan man forbereder infrastrukturen til integration, hvilken funktionalitet og i hvilket omfang man bør implementere. På den måde kan man undgå et hav af problemer ved at vælge en 'blind' produkt. Desuden vil implementering efter et velkoordineret 'pilotprojekt' give ingeniørerne langt færre ødelagte nerveceller og grå hår. Lad os se på, hvorfor pilot-testing er så vigtigt for et vellykket projekt, ved hjælp af et populært værktøj til kontrol af adgang til virksomhedens netværk — Cisco ISE. Vi vil se på både typiske og helt usædvanlige anvendelsesmuligheder, som vi har mødt i vores praksis.
Cisco ISE — "Radius-server på steroider"
Cisco Identity Services Engine (ISE) er en platform til at opbygge et kontrolsystem for adgang til den lokale netværksinfrastruktur i en organisation. I ekspertmiljøet er produktet blevet kaldt "Radius-serveren på steroider" på grund af dets egenskaber. Hvorfor? Grundlæggende er løsningen en Radius-server, der har fået tilføjet et væld af ekstra tjenester og 'features', der muliggør indsamling af store mængder kontekstuel information og anvendelse af denne samlede data i adgangspolitikker.
Som enhver anden Radius-server interagerer Cisco ISE med netværksudstyr på adgangsniveau, indsamler information om alle forsøg på at oprette forbindelse til virksomhedens netværk og baserer på autentificerings- og autoriseringspolitikker, om brugere får adgang til det lokale netværk eller ej. Men muligheden for profilering, polling og integration med andre IT-sikkerhedsløsninger gør det muligt at komplicere logikken i autorisationspolitikken betydeligt og dermed løse nogle ret svære og interessante opgaver.
Implementering forbudt: hvorfor er testning nødvendig?
Værdien af pilot-testning ligger i at demonstrere systemets fulde muligheder i en konkret institutions infrastruktur. Jeg er overbevist om, at pilotprojektet med Cisco ISE før implementeringen er gavnligt for alle deltagere i projektet, og det er derfor.
For integratorer giver det en klar forståelse af kundens forventninger og hjælper med at udarbejde et korrekt teknisk specifikationsdokument, som indeholder langt flere detaljer end den gængse sætning "lav det så det fungerer godt". "Piloten" giver os mulighed for at føle hele kundens smerte, forstå hvilke opgaver, der er prioriterede for dem, og hvilke der er sekundære. Det er en fremragende mulighed for os at finde ud af på forhånd, hvilket udstyr der bruges i organisationen, hvordan implementeringen vil foregå, på hvilke lokationer, og hvor de er placeret osv.
Kunderne ser under pilot-testningen et reelt system i aktion, bliver bekendt med dets grænseflade, kan kontrollere, om det er kompatibelt med deres eksisterende hardware, og får et sammenhængende indtryk af, hvordan løsningen vil fungere efter den fulde implementering. "Piloten" er det øjeblik, hvor man kan se alle de "skjulte udfordringer", der helt sikkert vil komme under integrationen, og beslutte, hvor mange licenser der skal købes.
Hvad kan 'poppe op' under 'piloten'
Hvordan skal man forberede sig korrekt til implementeringen af Cisco ISE? Fra vores erfaring har vi identificeret 4 hovedpunkter, der er vigtige at overveje under pilot-testningen af systemet.
Formfaktor
For det første skal man beslutte, hvilken formfaktor systemet vil blive implementeret i: fysisk eller virtuel appliance. Hver variant har sine fordele og ulemper. For eksempel er en styrke ved den fysiske appliance forudsigelig ydeevne, men man må ikke glemme, at sådanne enheder efterhånden bliver forældede. Virtuelle appliances er mindre forudsigelige, da de afhænger af det udstyr, som virtualiseringsmiljøet er implementeret på, men de har også en væsentlig fordel: med tilstrækkelig support kan de altid opdateres til den nyeste version.
Er dit netværksudstyr kompatibelt med Cisco ISE?
Naturligvis ville det ideelle scenarie være at tilslutte alt udstyr til systemet på én gang. Alligevel er det ikke altid muligt, da mange organisationer stadig bruger ikke-administrerede switches eller switches, der ikke understøtter nogle af de teknologier, som Cisco ISE fungerer med. For at nævne noget, gælder det ikke kun switches; det kan også være trådløse netværkscontrollere, VPN-koncentratorer og alt muligt andet udstyr, som brugerne tilsluttes. I min erfaring har der været tilfælde, hvor kunden opdaterede stort set hele sit adgangsswitch-udstyr til moderne Cisco-udstyr efter en systemdemo for en fuld implementering. For at undgå ubehagelige overraskelser er det værd at finde ud af, hvor stor en del af udstyret der ikke understøttes på forhånd.
Er alle dine enheder standardiserede?
I ethvert netværk findes der standardiserede enheder, som ikke bør give problemer med tilslutning: automatiserede arbejdspladser, IP-telefoner, Wi-Fi-adgangspunkter, videokameraer osv. Men der kan også være situationer, hvor der skal tilsluttes ikke-standardiserede enheder til LAN, for eksempel RS232/Ethernet signalomformere, grænseflader til UPS-enheder, forskellige teknologiske apparater osv. Det er vigtigt at identificere en liste over sådanne enheder på forhånd, så man allerede ved implementeringstidspunktet har en forståelse af, hvordan de teknisk vil fungere med Cisco ISE.
Konstruktiv dialog med IT-folk
Ofte er det sikkerhedsafdelingerne, der er kunder af Cisco ISE, mens IT-afdelingerne normalt har ansvaret for konfigurationen af adgangsswitches og Active Directory. Derfor er det et af de vigtige betingelser for en problemfri implementering af systemet, at der er produktiv interaktion mellem sikkerhedsfolkene og IT-folkene. Hvis sidstnævnte ser integrationen som et problem, er det værd at forklare dem, hvordan løsningen vil være gavnlig for IT-afdelingen.
Top 5 brugssager for Cisco ISE
Efter vores erfaring afsløres det nødvendige systemfunktionalitet også i pilot-testfasen. Nedenfor præsenteres nogle af de mest populære og mindre almindelige anvendelsessager for løsningen.
Sikker adgang til LAN via kabel med EAP-TLS
Som forskningsresultaterne fra vores pentestere viser, bruger ondsindede aktører ofte almindelige stikkontakter til at få adgang til virksomhedens netværk. Disse stikkontakter kan være tilsluttet printere, telefoner, IP-kameraer, Wi-Fi-access points og andre ikke-personlige netværksenheder. Derfor, selvom adgangen til netværket sker via dot1x-teknologi, og der bruges alternative protokoller uden brug af autentificeringcertifikater, er der en stor risiko for en succesfuld angreb med session hijacking og brute force hacking af passwords. I tilfælde af Cisco ISE vil det være betydeligt sværere at brute force et certifikat — hackere vil kræve meget større beregningskraft, så denne tilgang er meget effektiv.
Trådløs adgang Dual-SSID
Essensen af dette scenarie er brugen af 2 netværksidentifikatorer (SSID). En af dem kan betragtes som 'gæsteadgang'. Gennem denne kan både gæster og virksomhedens ansatte tilslutte sig det trådløse netværk. De ansatte bliver ved forsøg på tilslutning omdirigeret til en særlig portal, hvor provisioning finder sted. Det vil sige, at brugeren får udstedt et certifikat og indstilles sit personlige udstyr til automatisk at genoprette forbindelsen til det andet SSID, hvor EAP-TLS anvendes med alle fordelene fra det første scenarie.
MAC Authentication Bypass og profilering
Endnu et populært scenarie involverer automatisk bestemmelse af typen af det tilsluttede udstyr og anvendelse af de rette begrænsninger. Hvad gør det interessant? Der findes stadig mange enheder, der ikke understøtter autentificering via protokollen 802.1X. Derfor må sådanne enheder få adgang til netværket baseret på MAC-adressen, hvilket er ret nemt at forfalske. Her kommer Cisco ISE i spil: systemet kan overvåge, hvordan enheden opfører sig i netværket, danne en profil og tildele den til en gruppe af andre enheder, f.eks. IP-telefoner og arbejdsstationer. Hvis en ondsindet aktør forsøger at spoofe MAC-adressen og tilslutte sig netværket, vil systemet opdage, at enhedens profil er ændret, sende et signal om mistænkelig adfærd og forhindre den mistænkelige bruger i at få adgang til netværket.
EAP-Chaining
EAP-Chaining teknologien indebærer sekventiel autentificering af arbejds-PC'en og brugerens konto. Denne tilgang er blevet udbredt, da mange virksomheder stadig ikke tillader tilkobling af ansattes personlige enheder til det virksomhedsnetværk. Med denne autentificeringsmetode kan man kontrollere, om en specifik arbejdsstation er medlem af domænet, og ved et negativt resultat vil brugeren enten ikke få adgang til netværket eller få adgang med visse begrænsninger.
Posturing
I denne sammenhæng drejer det sig om vurdering af, om softwarekomponenterne på arbejdsstationen opfylder kravene til informationssikkerhed. Med denne teknologi kan man kontrollere, om softwaren på arbejdsstationen er opdateret, om der er installeret sikkerhedsværktøjer, og om den lokale firewall er konfigureret osv. Interessant nok gør denne teknologi det også muligt at løse andre opgaver, der ikke er relateret til sikkerhed, som for eksempel at kontrollere tilstedeværelsen af nødvendige filer eller installation af systemsoftware.
Mindre almindelige anvendelsesscenarier for Cisco ISE inkluderer kontrol af adgang med gennemgående domæneautentificering (Passive ID), SGT-baseret mikrosementering og filtrering samt integration med mobile enhedsadministrationssystemer (MDM) og sårbarhedsscannere (Vulnerability Scanner).
Usædvanlige projekter: hvorfor Cisco ISE ellers kan være nyttigt, eller 3 sjældne tilfælde fra vores praksis
Adgangskontrol til Linux-servere
Engang stod vi over for en ret kompleks sag for en af vores kunder, der allerede havde implementeret Cisco ISE. Vi havde brug for at finde en måde at kontrollere brugeraktiviteter (primært administratorer) på servere med Linux OS installeret. I vores søgen efter en løsning fik vi idéen om at bruge det gratis software PAM Radius Module, som tillader login på Linux-servere med autentificering på en ekstern radius-server. Alt det ville være fint, hvis det ikke var for én ting: radius-serveren sender kun kontoens navn og resultatet af autentifikationen - assess accepted eller assess rejected. For autorisation i Linux skal man dog tildele mindst én parameter mere - home directory, så brugeren kan få adgang til et sted. Vi fandt ikke en måde at returnere dette som radius-attribut, så vi skrev et specielt script til fjernoprettelse af brugerkonti på værter i et semi-automatiseret miljø. Denne opgave var helt muligt, da vi havde med administratorer at gøre, og antallet af dem ikke var så stort. Derefter loggede brugerne ind på den nødvendige enhed, hvorefter de fik tildelt den nødvendige adgang. Der opstår et rimeligt spørgsmål: er det nødvendigt at bruge Cisco ISE i sådanne tilfælde? Faktisk nej - enhver radius-server vil gøre, men da kunden allerede havde dette system, tilføjede vi blot en ny funktion til det.
Inventar af hardware og software i LAN
Engang arbejdede vi på et projekt for levering af Cisco ISE til en kunde uden en forudgående "pilot". Der var ikke klare krav til løsningen, og desuden arbejdede vi med et fladt, ikke-segmenteret netværk, hvilket gjorde opgaven mere udfordrende. I løbet af projektet opsatte vi alle de mulige profileringmetoder, som netværket understøttede: NetFlow, DHCP, SNMP, integration med AD osv. I sidste ende blev der opsat adgang via MAR, hvilket gav mulighed for at få adgang til netværket, selv ved mislykket autentificering. Det vil sige, at selv hvis autentificeringen ikke var succesfuld, tillod systemet stadig brugeren at komme ind i netværket, indsamlede information om vedkommende og gemte den i ISE-databasen. Denne netværksmonitorering i flere uger hjalp os med at identificere tilsluttede systemer og ikke-personlige enheder samt udvikle en tilgang til deres segmentering. Herefter opsatte vi yderligere post-sharing for installation af agenten på arbejdsstationerne med det formål at indsamle oplysninger om den software, der var installeret på dem. Hvad blev resultatet? Vi formåede at segmentere netværket og bestemme listen over software, der skulle fjernes fra arbejdsstationerne. Jeg vil ikke skjule, at de efterfølgende opgaver med at fordele brugerne i domænegrupper og afgrænse adgangen tog en del tid, men på den måde fik vi et fuldstændigt billede af, hvilket "hardware" der var i kundens netværk. Forresten var det ikke svært takket være det gode profileringarbejde "ud af boksen". Men der, hvor profileringen ikke hjalp, kiggede vi selv, idet vi fremhævede porten på switchen, som det tilsluttede udstyr var tilsluttet.
Fjerninstallation af software på arbejdsstationer
Denne sag er en af de mest mærkværdige i min praksis. En gang henvendte en kunde sig til os med et råb om hjælp — under implementeringen af Cisco ISE gik noget galt, alt brød sammen, og ingen kunne længere få adgang til netværket. Vi begyndte at undersøge sagen og fandt ud af følgende. Virksomheden havde 2000 computere, hvis styring, på grund af manglen på en domænecontroller, foregik under administratorens konto. For at kunne udføre netværksadministration blev Cisco ISE implementeret i organisationen. Det var nødvendigt at finde ud af, om antivirusprogrammet var installeret på de eksisterende pc'er, om den softwaremiljøet var opdateret osv. Da det var IT-administratorerne, der trak netværksudstyret ind i systemet, var det logisk, at de havde adgang til det. Efter at have set, hvordan det fungerer, og efter at have udført udregning af deres pc'ere, kom administratorerne på den idé at installere software på medarbejdernes arbejdsstationer eksternt uden personligt besøg. Bare tænk på, hvor mange skridt der kan spares i løbet af en dag! Administratorerne udførte flere tjek af arbejdsstationerne for at finde en bestemt fil i mappen C:Program Files, og ved dens fravær blev en automatisk remediationsproces startet, som førte til et link til et filopbevaringssted til installationsfilen .exe. Dette gjorde det muligt for almindelige brugere at få adgang til det fælles dokument og downloade den nødvendige software derfra. Desværre havde administratoren begrænset kendskab til ISE-systemet og beskadigede udregningsmekanismen — han skrev politikken forkert, hvilket førte til det problem, som fik os involveret. Personligt er jeg oprigtigt overrasket over en så kreativ tilgang, da det ville være både billigere og mindre tidskrævende at oprette en domænecontroller. Men som proof of concept fungerede det.
Læs mere om de tekniske nuancer, der opstår ved implementeringen af Cisco ISE, i min kollegas artikel. .
Artem Bobrikov, designingeniør i Informationssikkerhedscentret hos «Infosystemer Jet»
Efterord:
Selvom dette indlæg handler om Cisco ISE-systemet, er den beskrevne problematik relevant for hele klassen af NAC-løsninger. Det er ikke så vigtigt, hvilken leverandørs løsning der planlægges implementeret — det meste af det, der er sagt, vil forblive anvendeligt.
Kilde: habr.com
