Hvor ofte kjøper du noe spontant, bukker under for en kul reklame, og så samler denne opprinnelig ønskede varen støv i et skap, pantry eller garasje til neste vårrengjøring eller flytting? Resultatet er skuffelse på grunn av uberettigede forventninger og bortkastede penger. Det er mye verre når dette skjer med en bedrift. Svært ofte er markedsføringsgimmicker så gode at bedrifter kjøper en dyr løsning uten å se hele bildet av dens bruk. I mellomtiden hjelper prøvetesting av systemet til å forstå hvordan man forbereder infrastrukturen for integrasjon, hvilken funksjonalitet og i hvilken grad som bør implementeres. På denne måten kan du unngå et stort antall problemer på grunn av å velge et produkt "blindt". I tillegg vil implementering etter en kompetent "pilot" gi ingeniører mye mindre ødelagte nerveceller og grått hår. La oss finne ut hvorfor pilottesting er så viktig for et vellykket prosjekt, ved å bruke eksempelet på et populært verktøy for å kontrollere tilgangen til et bedriftsnettverk - Cisco ISE. La oss vurdere både standard og helt ikke-standard alternativer for å bruke løsningen som vi møtte i vår praksis.
Cisco ISE - "Radius-server på steroider"
Cisco Identity Services Engine (ISE) er en plattform for å lage et tilgangskontrollsystem for en organisasjons lokale nettverk. I ekspertmiljøet fikk produktet kallenavnet "Radius-server på steroider" for sine egenskaper. Hvorfor det? I hovedsak er løsningen en Radius-server, som et stort antall tilleggstjenester og "triks" er knyttet til, slik at du kan motta en stor mengde kontekstuell informasjon og bruke det resulterende settet med data i tilgangspolicyer.
Som enhver annen Radius-server samhandler Cisco ISE med nettverksutstyr på tilgangsnivå, samler inn informasjon om alle forsøk på å koble til bedriftsnettverket og, basert på autentiserings- og autorisasjonspolicyer, tillater eller nekter brukere LAN. Imidlertid gjør muligheten for profilering, publisering og integrasjon med andre informasjonssikkerhetsløsninger det mulig å komplisere logikken i autorisasjonspolitikken betydelig og dermed løse ganske vanskelige og interessante problemer.
Implementering kan ikke piloteres: hvorfor trenger du testing?
Verdien av pilottesting er å demonstrere alle egenskapene til systemet i den spesifikke infrastrukturen til en spesifikk organisasjon. Jeg tror at pilotering av Cisco ISE før implementering gagner alle som er involvert i prosjektet, og her er hvorfor.
Dette gir integratorer en klar ide om kundens forventninger og bidrar til å lage en korrekt teknisk spesifikasjon som inneholder mye mer detaljer enn den vanlige setningen "sørg for at alt er bra." "Pilot" lar oss føle all smerten til kunden, for å forstå hvilke oppgaver som er en prioritet for ham og hvilke som er sekundære. For oss er dette en utmerket mulighet til å finne ut på forhånd hvilket utstyr som brukes i organisasjonen, hvordan implementeringen vil foregå, på hvilke steder, hvor de befinner seg, og så videre.
Under pilottesting ser kundene det virkelige systemet i aksjon, blir kjent med grensesnittet, kan sjekke om det er kompatibelt med deres eksisterende maskinvare, og få en helhetlig forståelse av hvordan løsningen vil fungere etter full implementering. "Pilot" er selve øyeblikket da du kan se alle fallgruvene du sannsynligvis vil møte under integrasjonen, og bestemme hvor mange lisenser du trenger å kjøpe.
Hva kan "dukke opp" under "piloten"
Så hvordan forbereder du deg på å implementere Cisco ISE? Fra vår erfaring har vi telt opp 4 hovedpunkter som er viktige å vurdere under pilottestingen av systemet.
Formfaktor
Først må du bestemme i hvilken formfaktor systemet skal implementeres: fysisk eller virtuell upline. Hvert alternativ har fordeler og ulemper. Styrken til en fysisk upline er for eksempel dens forutsigbare ytelse, men vi må ikke glemme at slike enheter blir foreldet over tid. Virtuelle uplines er mindre forutsigbare fordi... avhenger av maskinvaren som virtualiseringsmiljøet er distribuert på, men de har en alvorlig fordel: hvis støtte er tilgjengelig, kan de alltid oppdateres til den nyeste versjonen.
Er nettverksutstyret ditt kompatibelt med Cisco ISE?
Selvfølgelig ville det ideelle scenariet være å koble alt utstyr til systemet på en gang. Dette er imidlertid ikke alltid mulig ettersom mange organisasjoner fortsatt bruker uadministrerte svitsjer eller svitsjer som ikke støtter noen av teknologiene som kjører Cisco ISE. Vi snakker forresten ikke bare om brytere, det kan også være trådløse nettverkskontrollere, VPN-konsentratorer og eventuelt annet utstyr som brukerne kobler seg til. I min praksis har det vært tilfeller der kunden, etter å ha demonstrert systemet for full implementering, oppgraderte nesten hele flåten av tilgangsnivåbrytere til moderne Cisco-utstyr. For å unngå ubehagelige overraskelser, er det verdt å finne ut på forhånd hvor mye utstyr som ikke støttes.
Er alle enhetene dine standard?
Ethvert nettverk har typiske enheter som ikke bør være vanskelige å koble til: arbeidsstasjoner, IP-telefoner, Wi-Fi-tilgangspunkter, videokameraer og så videre. Men det hender også at ikke-standard enheter må kobles til LAN, for eksempel RS232/Ethernet buss signalomformere, avbruddsfri strømforsyningsgrensesnitt, diverse teknologisk utstyr, etc. Det er viktig å bestemme listen over slike enheter på forhånd , slik at du allerede på implementeringsstadiet har en forståelse av hvordan de teknisk sett vil fungere med Cisco ISE.
Konstruktiv dialog med IT-spesialister
Cisco ISE-kunder er ofte sikkerhetsavdelinger, mens IT-avdelinger vanligvis er ansvarlige for å konfigurere aksesssvitsjer og Active Directory. Derfor er produktiv samhandling mellom sikkerhetsspesialister og IT-spesialister en av de viktige betingelsene for smertefri implementering av systemet. Hvis sistnevnte oppfatter integrasjon med fiendtlighet, er det verdt å forklare dem hvordan løsningen vil være nyttig for IT-avdelingen.
Topp 5 Cisco ISE-brukssaker
Vår erfaring er at den nødvendige funksjonaliteten til systemet også identifiseres på pilotteststadiet. Nedenfor er noen av de mest populære og mindre vanlige brukstilfellene for løsningen.
Sikre LAN-tilgang over en ledning med EAP-TLS
Som resultatene av våre pentesters undersøkelser viser, bruker angripere ganske ofte vanlige stikkontakter som skrivere, telefoner, IP-kameraer, Wi-Fi-punkter og andre ikke-personlige nettverksenheter er koblet til for å penetrere et selskaps nettverk. Derfor, selv om nettverkstilgang er basert på dot1x-teknologi, men alternative protokoller brukes uten bruk av brukerautentiseringssertifikater, er det stor sannsynlighet for et vellykket angrep med øktavlytting og brute-force-passord. I tilfellet med Cisco ISE vil det være mye vanskeligere å stjele et sertifikat - for dette vil hackere trenge mye mer datakraft, så denne saken er veldig effektiv.
Dual-SSID trådløs tilgang
Essensen av dette scenariet er å bruke 2 nettverksidentifikatorer (SSID). En av dem kan betinget kalles "gjest". Gjennom den kan både gjester og bedriftsansatte få tilgang til det trådløse nettverket. Når de prøver å koble seg på, blir de sistnevnte omdirigert til en spesiell portal der klargjøring finner sted. Det vil si at brukeren får utstedt et sertifikat og hans personlige enhet er konfigurert til automatisk å koble til den andre SSID-en, som allerede bruker EAP-TLS med alle fordelene til det første tilfellet.
MAC-autentiseringsomgåelse og profilering
En annen populær brukssak er å automatisk oppdage typen enhet som kobles til og bruke de riktige begrensningene på den. Hvorfor er han interessant? Faktum er at det fortsatt er ganske mange enheter som ikke støtter autentisering ved hjelp av 802.1X-protokollen. Derfor må slike enheter tillates på nettverket ved å bruke en MAC-adresse, som er ganske lett å forfalske. Det er her Cisco ISE kommer til unnsetning: ved hjelp av systemet kan du se hvordan en enhet oppfører seg på nettverket, opprette profilen og tilordne den til en gruppe andre enheter, for eksempel en IP-telefon og en arbeidsstasjon . Hvis en angriper prøver å forfalske en MAC-adresse og koble til nettverket, vil systemet se at enhetsprofilen er endret, vil signalisere mistenkelig oppførsel og vil ikke tillate den mistenkelige brukeren inn i nettverket.
EAP-kjede
EAP-kjedeteknologi innebærer sekvensiell autentisering av den fungerende PC-en og brukerkontoen. Denne saken har blitt utbredt fordi... Mange bedrifter oppfordrer fortsatt ikke til å koble ansattes personlige dingser til bedriftens LAN. Ved å bruke denne tilnærmingen til autentisering er det mulig å sjekke om en bestemt arbeidsstasjon er medlem av domenet, og hvis resultatet er negativt, vil brukeren enten ikke få adgang til nettverket, eller vil kunne gå inn, men med visse begrensninger.
Stilling
Denne saken handler om å vurdere om arbeidsstasjonsprogramvaren er i samsvar med krav til informasjonssikkerhet. Ved å bruke denne teknologien kan du sjekke om programvaren på arbeidsstasjonen er oppdatert, om sikkerhetstiltak er installert på den, om vertsbrannmuren er konfigurert osv. Interessant nok lar denne teknologien deg også løse andre oppgaver som ikke er relatert til sikkerhet, for eksempel å sjekke tilstedeværelsen av nødvendige filer eller installere systemomfattende programvare.
Mindre vanlige brukstilfeller for Cisco ISE inkluderer tilgangskontroll med ende-til-ende domeneautentisering (passiv ID), SGT-basert mikrosegmentering og filtrering, samt integrasjon med systemer for mobilenhetsadministrasjon (MDM) og sårbarhetsskannere.
Ikke-standardprosjekter: hvorfor ellers kan du trenge Cisco ISE, eller 3 sjeldne tilfeller fra vår praksis
Tilgangskontroll til Linux-baserte servere
En gang løste vi en ganske ikke-triviell sak for en av kundene som allerede hadde implementert Cisco ISE-systemet: vi trengte å finne en måte å kontrollere brukerhandlinger (for det meste administratorer) på servere med Linux installert. På jakt etter et svar kom vi på ideen om å bruke den gratis programvaren PAM Radius Module, som lar deg logge på servere som kjører Linux med autentisering på en ekstern radiusserver. Alt i denne forbindelse ville være bra, hvis ikke for ett "men": radiusserveren, som sender et svar på autentiseringsforespørselen, gir bare kontonavnet og resultatet - vurder akseptert eller vurder avvist. I mellomtiden, for autorisasjon i Linux, må du tilordne minst én parameter til - hjemmekatalog, slik at brukeren i det minste kommer et sted. Vi fant ikke en måte å gi dette som en radiusattributt, så vi skrev et spesielt skript for eksternt å opprette kontoer på verter i en halvautomatisk modus. Denne oppgaven var ganske gjennomførbar, siden vi hadde å gjøre med administratorkontoer, hvor antallet ikke var så stort. Deretter logget brukere på den nødvendige enheten, hvoretter de ble tildelt nødvendig tilgang. Et rimelig spørsmål oppstår: er det nødvendig å bruke Cisco ISE i slike tilfeller? Faktisk, nei - enhver radiusserver vil gjøre det, men siden kunden allerede hadde dette systemet, la vi ganske enkelt til en ny funksjon til det.
Inventar over maskinvare og programvare på LAN
Vi jobbet en gang med et prosjekt for å levere Cisco ISE til én kunde uten en foreløpig "pilot". Det var ingen klare krav til løsningen, pluss at vi hadde å gjøre med et flatt, ikke-segmentert nettverk, noe som kompliserte oppgaven vår. I løpet av prosjektet konfigurerte vi alle mulige profileringsmetoder som nettverket støttet: NetFlow, DHCP, SNMP, AD-integrasjon, etc. Som et resultat ble MAR-tilgang konfigurert med muligheten til å logge på nettverket hvis autentisering mislyktes. Det vil si at selv om autentiseringen ikke var vellykket, ville systemet fortsatt tillate brukeren inn i nettverket, samle informasjon om ham og registrere den i ISE-databasen. Denne nettverksovervåkingen over flere uker hjalp oss med å identifisere tilkoblede systemer og ikke-personlige enheter og utvikle en tilnærming for å segmentere dem. Etter dette konfigurerte vi i tillegg posting for å installere agenten på arbeidsstasjoner for å samle inn informasjon om programvaren installert på dem. Hva er resultatet? Vi var i stand til å segmentere nettverket og bestemme listen over programvare som måtte fjernes fra arbeidsstasjonene. Jeg skal ikke legge skjul på at ytterligere oppgaver med å distribuere brukere inn i domenegrupper og avgrense tilgangsrettigheter tok oss ganske mye tid, men på denne måten fikk vi et komplett bilde av hvilken maskinvare kunden hadde på nettverket. Dette var forresten ikke vanskelig på grunn av det gode arbeidet med å profilere ut av boksen. Vel, der profilering ikke hjalp, så vi selv, og fremhevet bryterporten som utstyret var koblet til.
Fjerninstallasjon av programvare på arbeidsstasjoner
Denne saken er en av de merkeligste i min praksis. En dag kom en kunde til oss med et rop om hjelp - noe gikk galt under implementeringen av Cisco ISE, alt gikk i stykker, og ingen andre fikk tilgang til nettverket. Vi begynte å se på det og fant ut følgende. Selskapet hadde 2000 datamaskiner, som, i mangel av en domenekontroller, ble administrert under en administratorkonto. For formålet med peering, implementerte organisasjonen Cisco ISE. Det var nødvendig å på en eller annen måte forstå om et antivirus var installert på eksisterende PC-er, om programvaremiljøet ble oppdatert, etc. Og siden IT-administratorer installerte nettverksutstyr i systemet, er det logisk at de hadde tilgang til det. Etter å ha sett hvordan det fungerer og posheret PC-ene deres, kom administratorene på ideen om å installere programvaren på ansattes arbeidsstasjoner eksternt uten personlige besøk. Tenk deg hvor mange skritt du kan spare per dag på denne måten! Administratorene utførte flere kontroller av arbeidsstasjonen for tilstedeværelsen av en bestemt fil i C:Program Files-katalogen, og hvis den var fraværende, ble automatisk utbedring startet ved å følge en lenke som førte til fillagringen til installasjons-.exe-filen. Dette tillot vanlige brukere å gå til en fildeling og laste ned nødvendig programvare derfra. Dessverre kjente ikke administratoren ISE-systemet godt og skadet posteringsmekanismene - han skrev policyen feil, noe som førte til et problem som vi var med på å løse. Personlig er jeg oppriktig overrasket over en så kreativ tilnærming, fordi det ville vært mye billigere og mindre arbeidskrevende å lage en domenekontroller. Men som Proof of concept fungerte det.
Les mer om de tekniske nyansene som oppstår ved implementering av Cisco ISE i min kollegas artikkel .
Artem Bobrikov, designingeniør ved informasjonssikkerhetssenteret ved Jet Infosystems
etterord:
Til tross for at dette innlegget snakker om Cisco ISE-systemet, er problemene som beskrives relevante for hele klassen av NAC-løsninger. Det er ikke så viktig hvilken leverandørs løsning som er planlagt for implementering - det meste av det ovennevnte vil fortsatt gjelde.
Kilde: www.habr.com