In mijn dagelijks werk rondom het oplossen van applicatie- en infra-problemen krijg ik meestal de vraag om ook even in kaart te brengen welke applicaties er allemaal gebruikt worden, hoeveel gebruikers ze hebben en waar ze zitten, welke servers daarbij aangesproken worden, waar deze zijn aangesloten en hoe de netwerk infrastructuur eruit ziet. In dit artikel de grote lijnen van mijn aanpak in dergelijke situaties.
Aan de technische kant van de infra, zeg maar de apparatuur kant, maak ik gebruik van SNMP- & WMI-scanners. De SNMP-kant voor bijvoorbeeld netwerk apparatuur, storage apparatuur en Unix-achtige; de WMI kant voor ons aller Windows.
De betere scanners maken gebruik van de topologie informatie die is opgeslagen in de verschillende soorten netwerk-apparatuur. Denk bijvoorbeeld aan Cisco zijn CDP of diens opvolger LLDP om te bepalen wat er allemaal aan elkaar geknoopt is. In dat kader bewijst zelfs good-old spanning tree nog goede diensten doordat het precies aangeeft langs welke paden het data verkeer feitelijk wordt afgehandeld!
Het is juist deze topologie informatie die een SNMP-scanner in staat stelt een zeer gedetailleerde OSI L2 en L3 plaat op te leveren van alle aangesloten ‘apparatuur’; fysiek of virtueel.
Het gebruik van veel verschillende applicatie- & middleware-technieken heeft zo zijn voordelen bij het in kaart brengen van het applicatie landschap. Dat maakt namelijk dat packet trace en DPI-technieken efficiënt en effectief hun werk kunnen doen.
De packet trace-methode gebruik ik om inzicht te krijgen in verkeersstromen en volumes tussen gebruikers en het server park op basis van de gebruikte ip-adressen en tcp-poorten. Langs deze weg krijg ik dan ook inzicht in het soort besturingssysteem wat aan gebruikers- en server-zijde ingezet is; vaak aangevuld met versienummers. Op die manier wordt er meteen een eerste stap gezet bij het in kaart brengen van het gebruik van bijvoorbeeld byod’s en clouddiensten.
De DPI-techniek is feitelijk een aanvulling op de packet trace omdat die onderscheid kan maken tussen applicaties die over eenzelfde (server-site) tcp-poort en ip-adres lopen. Voor wat betreft de herkenning van applicaties werkt DPI ook in combinatie met ssl zonder dat de packet trace component het betreffende server certificaat aan boord heeft. Dit laatste is vooral van belang bij applicatie- en platform-diensten zoals die van Microsoft, Google en Amazone. Enerzijds omdat die over één ip-adres en één tcp-poort vaak meerdere applicaties beschikbaar stellen. Anderzijds omdat het juist niet mijn bedoeling is om mee te gluren met datgene wat een gebruiker allemaal aan het doen is.
Bij elkaar levert de combinatie packet trace en DPI dan ook in een zeer gedetailleerde plaat van de applicaties, de gebruikersgroepen en de servers.
Blinde vlekken
Zelfs met de inzet van meerdere ESX-hosts, honderden vm’s, firewalls, caching/proxy servers, nat-ing en wat-dies-meer-zij blijft deze aanpak overeind! De inzet van dit soort technieken brengt namelijk een bepaald verkeerspatroon van applicaties met zich mee. De kunst bestaat erin om die verkeerspatronen te herkennen om van daaruit dat deel van het it-landschap verder af te pellen en in kaart te brengen.
Om het succes van deze herkenning te maximaliseren maak ik gebruik van de combinatie L2/L3-topologie en de applicatie-topologie. Door die twee over elkaar heen te leggen ontdek ik de blinde vlekken.
De essentie van deze herkenning bestaat eruit dat de applicatiekant verkeersstromen laat zien van en naar bepaalde ip-adressen over bepaalde tcp-poorten (eventueel uitgesplitst naar meerdere applicaties door de DPI-techniek). Terwijl de L2/L3-plaat geen verdere informatie heeft over deze ip-adressen en het erachter liggende netwerk.
Samen zijn ze dan ‘het bewijs’ dat er iets is wat het betreffende netwerkdeel afschermt. Soms stopt het hier. Andere keren helpt een goed gesprek met het beherende team over het nut en noodzaak voor het verder afpellen van deze blinde vlekken.
100 procent volledig
Ik durf de stelling aan dat het systematisch toepassen van deze aanpak een 100 procent volledig beeld oplevert! Beide methodes samen bieden namelijk inzicht in de bekende en minder bekende onderdelen van een it-landschap. Wat al een hele vooruitgang is ten opzichte van een veel voorkomend startpunt: ‘afgezien van een x-jaar oud architectuur document hebben we eigenlijk nauwelijks een idee hoe het it-landschap er op dit moment uitziet’.
Zelfs als gebruikers hun eigen ‘devices’ meebrengen en de business zelfstandig een of meerdere clouddiensten in gebruik hebben genomen worden deze automatisch opgenomen in de applicatieplaat.
Alles bij elkaar worden er ook nog eens een paar belangrijke stukken aangeleverd rondom de invulling van de puzzel die heet governance! Immers, ondanks dat het detailniveau kan variëren is er nu zicht op de dingen die bekend zijn en waar nog wat werk aan de winkel is.
Andere toepassingsmogelijkheden
Een dergelijke aanpak is ook prima in te passen tijdens de due dillegence-fase van een sourcing-contract omdat binnen korte tijd helder is wat er op enig moment staat, wat daarvan gebruikt wordt en in welke mate. Ik durf te wedden dat de gesprekken volgend op deze resultaten veel constructiever zijn dan nu vaak het geval is!
Vervolgstappen in de vorm van andersoortige scans zijn nu ook eenvoudig te realiseren doordat er zicht is op de apparatuur, de applicaties en de onderlinge samenhang. Denk bijvoorbeeld aan een scan op servers en zogenaamde appliances rondom de firmware en softwarecomponenten met bijbehorende versienummers.
Wat ook nog wel eens kan helpen is het automatisch bijwerken van deze twee topologie-platen met een bepaald interval. Hoewel mijn persoonlijke voorkeur uit gaat naar het werken met een lijstje van delta’s dat elke 24 uur wordt bijgewerkt. Dit lijstje wordt dan dagelijks (of tenminste wekelijks!) nagelopen op bijzonderheden zoals gebruikersstations die zich in een keer als server gedragen (serveren van torrents?). Of een gebruikersstation met een stevige toename in het mail volume (rondsturen van spam?).
Op deze manier blijven de beheerteams in ieder geval zicht hebben op datgene wat er zich afspeelt in hun it-landschap; ook als de business de resultaten van de changes in het afgelopen weekend eens een keer niet doorgeeft…
@Goos:
Het heeft vaak te maken met een stukje historie. Bedrijven die een of meerdere overnames hebben gedaan weten vaak nog wel hoe het *ongeveer* zit. Maar doordat ze in het verleden eerst het low-hanging-fruit aangepakt hebben bij het in elkaar schuiven van organisaties ontstaat er steeds meer twijfel over het *ongeveer*. Die twijfel maakt dat het probleem steeds maar groter wordt (gemaakt?).
Aangezien niemand er zijn vingers aan wil branden gebeurd er in eerste instantie niet zo heel veel – anders dan wat window-dressing en pleisters plakken. Totdat het allemaal *krak* zegt. Dan moet iedereen hard gaan rennen…
@Felix:
Interessant perspectief. Vrij vertaald: de directie en diens managers krijgen het niet voor elkaar om hun teams te motiveren tot een zodanige manier van samenwerking dat de zaken (tenminste) redelijk op orde zijn. Na een aantal jaren aanmodderen wordt besloten om e.e.a. dan toch maar uit te besteden danwel van leverancier te wisselen.
Waarbij ik me dan afvraag hoe dat gaat helpen… Immers, als je garbage overdraagt aan een (nieuwe) leverancier, dan gaat er toch ook weer garbage uitkomen? Ook al omdat de management stijl van de directie en diens managers in de tussentijd toch niet wezenlijk veranderd zal zijn – wel?
@Reza:
Mijn inschatting is dat er over twee jaar niet zo veel veranderd is dat deze aanpak dan niet meer interessant is. Hooguit dat er wellicht wat meer hindernissen opgeworpen worden om dit soort inzichten voor elkaar te krijgen. En dat onder het motto “security policy”. Maar dat is nu niet veel anders…
@NumoQuest:
Op zich heb je misschien gelijk. Aan de andere kant verbaas ik me daar wel over. Bij de verkoop van een bedrijfsonderdeel, bijvoorbeeld een productiestraat, is het heel te doen gebruikelijk om een due-dillengence te doen. Bijvoorbeeld om te bepalen hoe het staat met eventueel achterstallig onderhoud en de opgegeven productie capaciteit.
Maar als het gaat om het outsourcen van IT middelen, dan wordt dit op voorhand al vrijwel onmogelijk gemaakt door allerhande blokkades op te werpen zoals hoge tarieven en “security policies”. Hoezo partnership en samenwerking…
@Henri:
Wat zou je willen testen?
Is dat te combineren met de cloud diensten die je in gedachten hebt?
Misschien iets hier off-line op door te gaan?
@Will
Ik ga waarschijnlijk een heel eind off-topic maar of SIEM de eerste of de volgende stap is hangt dus af van waar je prioriteiten liggen aangaande informatiebeveiliging. Als ik me niet vergis is het ook geen vrijblijvende optie meer voor allerlei privacygevoelige gegevens. Zie daar de reden data in beweging te maskeren met bijvoorbeeld een oplossing zoals Stealth. Iets wat ook steeds belangrijker wordt bij SDDC omdat er steeds meer aan dezelfde lijn komt te hangen want het verkeer verdwijnt hier inderdaad niet mee maar wordt wel moeilijker te analyseren met DPI.
Betreffende je vraag over tijd, als je daar geen sluitende dekking in hebt dan is dat dus meestal zorgelijk in meerdere opzichten. Meen me te herinneren dat Henri daar al eens ervaringen mee heeft opgedaan omdat allerlei beheerssystemen dus tijdkritisch zijn en ’time drift’ in gevirtualiseerde omgevingen nog weleens voor verrassingen zorgt. Zelfs AD (kerberos) begint te piepen als timestamps uit de pas gaan lopen om zo maar eens wat te noemen.
Allemaal off-topic natuurlijk maar welke praktisch nut heeft het om je applicatie landschap in kaart te brengen als je de integriteit van alle informatie hierin niet eens kunt garanderen?
Laten we voorop stellen dat het natuurlijk altijd een B keuze is om een applicatielandschap te (her)ontdekken met “discovery” tools. Uiteindelijk is het niet kunnen construeren van een applicatielandschap een regie / governance manco. Daarnaast is het ook een vorm van symptoom bestrijding, al kun je de genoemde tools en techniek natuurlijk voor meer dingen gebruiken.
Ewout, mijn “time drift” was met een SQL Server instance van RDS bij Amazon, die time-drift was overigens mijn eigen schuld door fout gebruik. Vervelend was dat ik het corrigeren van de tijd niet zelf kon doen.
@Ewout:
Als je zo een traject opstart binnen een kader van informatiebeveiliging is er nog steeds een bepaalde volgorde in de uitvoering. Allez – tis te zeggen – ik zie niet zo hoe SIEM een kans van slagen heeft zonder te weten wat de (potentiële) informatiebronnen zijn. Op het moment dat daar stevige twijfel over is zit er niet veel anders op dan een inventarisatie te doen. Waardoor de beschreven aanpak alsnog in beeld komt.
Maar als jij een andere visie (een andere ervaring?) hebt, dan laat ik me graag bijpraten!
De passage over “time drift” begrijp ik niet – althans niet binnen de context van inzicht krijgen in wat er zich afspeelt in je IT landschap. Kan je dat toelichten?
Dan de passage over de integriteit van informatie. Mijn beeld van informatie integriteit is dat informatie juist, volledig en op tijd moet zijn. Dat is precies wat ik beoog met mijn aanpak.
Dat veranderd niet als je er een security sausje overheen gooit. Hooguit worden de drie genoemde aspecten verbijzonderd naar rollen en personen binnen een organisatie. Formeel zal er dan ook iemand benoemd moeten worden die geautoriseerd is om wijzigingen aan te brengen.
Maar dat decimeert de meerwaarde van de aanpak en diens resultaten toch niet?
Een soortgelijke situatie speelt ook rondom het afschermen van netwerk verkeer met behulp van tunnel technologie. De inzet daarvan wordt enkel beoordeelt vanuit een security policy.
Ik ben van mening dat Security Officers best wat meer rekening mogen houden met degene die storingen op moeten lossen. Want anders gaat het al snel richting “Operatie geslaagd – patiënt overleden” => de zaak is goed beveiligd – alleen is het oplossen van connectivity en latency problemen een Mission-Impossible geworden: “nee, onze security policy staat het niet toe om een vorm van packet capturing in te zetten”.
Ook hier – een dergelijke starre houding reduceert de waarde van de aanpak en diens resultaten toch niet in een keer tot nul?
@Henry:
Ik begrijp de redenatie.
Maar je zou jezelf ook af kunnen vragen of dergelijke discovery tools niet een goed instrument zijn om de juistheid, volledigheid en tijdigheid (integriteit?) van je applicatie landschap te borgen.
Versus alles in processen en handwerk vangen waardoor de beoogde integriteit alsnog onder druk komt te staan.
@Will
Klopt, maar mijn reacties zijn ook niet bedoeld om op in in te gaan.
En er is ook geen typo. Als L2/L3 geen verdere info geeft dan is dat juist die blinde vlek in het netwerksegment, die je al dan niet verder wilt onderzoeken.
@Henri
Dat je corrigeren van de tijd niet zelf kon doen lijkt me logisch, als we jouw die rechten gaan geven dan zitten we straks weer in het stenen tijdperk;-)
Afhankelijk van de scheduling is tijd een kritische factor in gedistribueerde systemen en voorkomt synchronisatie hiervan dat er anarchie ontstaat. En dat geldt dus ook voor je informatiesystemen als de integriteit van transacties (timeliness/durability) niet meer te controleren valt. Nieuwste generatie code geeft dan ook meer fouten dan functionaliteiten, zie hier de wens van continuous delivery en een schaalbare infrastructuur welke echter weer geen rekening houdt met de ITSM processen die meestal niet geautomatiseerd zijn. Best wel lomp van je dus om te stellen dat herontdekken van het applicatielandschap een B-keus.
@Will
Even voorop stellen dat ik het niet oneens ben met je opinie of reacties maar heb ondertussen wat bijgeleerd heb. Betreffende je opmerking over rollen en dan met name die van de gedelegeerd verantwoordelijke Security Officer is de weerstand die ze hebben tegen dit soort onderzoeken begrijpelijk. Ik stelde al dat SIEM (als proces) vaak geen optie is maar een verplichting als het bepaalde informatieverwerkingen betreft. Sharepoint, Exchange en nog wat van de algemene kantooroplossingen bieden standaard maar weinig mogelijkheden om de integriteit van de informatie daarin te waarborgen. Voor de volledigheid aangaande integriteit van de informatieverwerking moet het namelijk zijn: rechtmatig, niet te veel of te weinig, op tijd en geautoriseerd.
Blijkbaar heb je het gemist maar over deze onderwerpen heb ik al eens wat geschreven maar zie ik geen reacties van jouw kant dus kaats ik die bal even terug. Want wat is het doel van je exercitie, ben na meer dan 50 assessments (opinies) opgehouden met tellen maar de algehele conclusie is dat je de wereld kunt beschrijven zoals die is of zoals die moet zijn maar je in praktijk altijd ergens daar tussenin terecht komt. Laten we het verwachtingsmanagement noemen en zie daar het business-IT alignment dillema wat naar mijn opinie het gevolg is van praatplaten die meer op ‘Who’s affraid for red, yellow and blue’ lijken omdat vooral gepoogd wordt om complexiteit van IT architectuur terug te brengen tot respectievelijk eenvoudig keuzen zoals zelf doen, laten waaien of uitbesteden omdat het dus vaak de boekhouder is die de scepter zwaait.
Heb naar ik me kan herinneren als eens blauwe en rode zee theorie van INSEAD uitgelegd als het innovatie betreft en ik ben niet als Reza die alleen maar in herhaling valt. Wil best van gedachten wisselen over algoritmen voor de blauwe innovatie die je kunt gebruiken om tussen de regels door te lezen maar ValueBlue leverde daarvoor in elk geval nog de pizza’s. En het doet me deugt dat ze die kennis gratis ter beschikking stellen: http://www.valueblue.nl/bluedolphin
Dear Ewout,
Als je tussen de regels door leest lees je vast wel dat dat een normaal standaard in de clausule moet zijn iets wat het stelselmatig weer niet blijkt te zijn. Gewoon weer een hiaat in iets wat voor mij volkomen standaard handeling is.
@Ewout
Ik denk dat als we het hebben over SIEM onze visie elkaar niet zo heel veel ontloopt. Iets dergelijks moet inderdaad ingeregeld zijn.
Maar bij het inregelen zou wat meer gekeken kunnen worden naar de impact die zoiets heeft op de taken en verantwoordelijkheden van iemand anders.
Security maatregelen lijken zo vaak een doel op zich te zijn. Tenminste – als ik vraag naar het risico wat een bepaalde maatregel moet afdekken krijg ik zelden een antwoord – anders dan “zo is het beleid”.
Dan de volgende twee passages: het zou inderdaad kunnen dat ik je artikelen niet gelezen heb.
Aan de andere kant is daar ook je beeldspraak. Hoewel ik ze op zichzelf meestal erg creatief en leuk vindt, ontgaat me in veel gevallen het punt wat je wil maken. Dat heeft te maken met de manier waarop ik informatie verwerk – ik ben een beelddenker. Even zwart/wit: voor mij zijn de letters p, d en b drie keer dezelfde letter – ze zijn alleen maar gespiegeld of gedraaid.
Dat maakt het voor mij behoorlijk lastig om artikelen en boeken te lezen met alleen maar tekst – laat staan als daar ook nog eens een hoge mate van beeldspraak in zit.
Dan is daar ook angst – de angst dat een (domme?) opmerkingen en (dito?) vragen tegen me gebruikt wordt maakt dat ik dan maar niet meer reageer – ik heb intussen iets te vaak mijn kop gestoten…
Zo ook je laatste reactie. Ik zal vast wel ergens de plank misgeslagen hebben. Maar wat een blauwe dolfijn en pizza’s met innovatie en applicaties te maken hebben zie ik echt niet.
Idem voor de passage over de wereld beschrijven of de complexiteit van IT architectuur.
Wat mij zou helpen is wat minder beeldspraak – kans is groot dat ik je opinies veeeeel beter begrijp en dus ook durf te reageren.
Datzelfde speelt ook hier – ik zie het punt niet wat je met de laatste twee passages wil maken. Dus op het gevaar af een domme vraag te stellen: welke artikelen bedoel je en wat is het punt dat je wil maken?