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…
Will,
Dat het op deze manier in kaart brengen van je landschap een mogelijkheid is zal ik niet ontkennen aangezien ik hier in het verleden al eens wat over geschreven heb. Probleem is alleen dat het zich meestal beperkt tot een klein deel van je architectuur, enkel de infrastructuur welke netwerk enabled is.
Stelling dat het een 100% volledig beeld geeft wil ik wel bestrijden naar aanleiding van ervaringen met firewalls, legacy en nog een heleboel van die andere dingen die telkens weer voor verrassingen zorgen. Zo leveren wij bijvoorbeeld een product dat heet Stealth, je raadt waarschijnlijk al wat er gebeurt als er netwerk verkeer onzichtbaar onder de radar doorvliegt.
Zeker kun je op basis van uit- en ingaand verkeer veel achterhalen maar om te zeggen dat het je alle inzichten verschaft lijkt me met ontwikkelingen op het gebied van IPv6 en SDDC misschien iets te rooskleurig. Het is natuurlijk beter dan niets maar ik zou het verhaal toch nog eens overdenken. SIEM oplossingen vragen tenslotte behoorlijke investeringen in resources als je real-time alle delta’s bij wilt werken, een frequentie van 24-uur lijkt me namelijk niet genoeg.
Wat een prachtig (lees: gruwelijk) voorbeeld hoeveel kosten er nog te besparen zijn in de ICT. Zolang er nog bedrijven en organisaties zijn die zelf niet eens weten (ik citeer): “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”, dan is ICT blijkbaar een zwart gat waar je als directie geld ingooit en hoopt dat het genoeg is. Ongelooflijk!
“Terwijl de L2/L3-plaat geen verdere informatie heeft over deze ip-adressen en het erachter liggende netwerk.”
‘geen’ is hier een typo en moet verwijderd.
Wil de business iets forceren, als uitbesteden of migreren of leverancier wisselen, dan komen die performance problemen juist mooi uit. Je wilt tenslotte “geen zwart gat waar je als directie geld ingooit en hoopt dat het genoeg is”. En dan moet er zeker nog meer bij voor die DPI, LLDP en andere nerd praat, om te onderzoeken hoe en waarom. Dacht ut niet 🙂
@Goos: ooit in een R&D – ICT organisatie gewerkt, waar regelmatig software wordt uitgeprobeerd; waar eigengemaakte software onderdeel vormt van het IT-landschap, waar het een komen en gaan is van testmachines met diverse hard- en software combinaties?
Voor een statische organisatie kan ik me je uitspraak voorstellen, maar in een dynamische organisatie is het IT landschap in hoog tempo aan verandering onderhevig.
Will,
Leuk artikel. Ik ben benieuwd naar de volgende versie van dit artikel over bv 2 jaar wanneer BYOA/SaaS/IT customization/ shadow IT etc de huidige vorm van applicatielandschap veranderd hebben!
Mischien zit ik er naast maar ik krijg bij dit artikel een beetje een DejaVu van amper drie weken geleden.
Aardig stukje schrijfwerk dat ik wel herken uit vorige levens. Wat mij telkens toch weer intrigeert bij dit soort stukjes is het volgende.
Dit soort taken behoren feitelijk niet toe aan een nieuwe leverancier. Waarom niet? Omdat contractueel bepaald behoort te zijn dat de ‘as is state’ van de spullenboel, als standaard, door elke ‘IT leverancier’ van dat moment, maandelijks dient te worden opgeleverd.
Hela, wat zegt u nu? Staat dat niet als vast mandaat in het contract? Na twintig jaar nog steeds niet? Dan zien we hier dus een zakelijk gat in performance en contract. Dit onderdeel dient gewoon een standaard integraal deel uit te maken van het dienstencontract. Waarom? Enig idee wat men graag berekend voor een due dillegence of een ‘as is state’ onderzoek?
Daar is IT niet voor. IT is er wel voor er zorg voor te dragen dat dit soort informatie standaard n geactualiseerd voor handen is.
My 5c.
Will, gewoon goed artikel, met praktische insteek.
Ben wel benieuwd hoe ik dit kan toepassen in mijn vakgebied en bij een organisatie die geen eigen infrastructuur heeft, maar alles ontrekt uit de cloud.
Functioneert dit ook in een VPC? Kunnen we dat een keer uit proberen?
Uiteraard zijn er meerdere manieren op een landschap te tekenen. Met cloud diensten is dit redelijk geautomatiseerd te realiseren 🙂
@NumoQuest
Volgens mij ga je de mist in bij ‘contractueel bepaald….’ als we kijken naar een gemiddeld IT landschap waar de keuzen door de business nog weleens gemaakt worden op basis van een korte termijn annex tunnel visie. Vraag is of je grip wilt houden op IT-landschap of de kosten daarvan, het immer aanwezige dilemma tussen de economische en technische afwegingen die tegenwoordig zo bepalend zijn in de besluitvorming.
@Henri
Als je goed gelezen had zou je gezien hebben dat Will het over ‘sourcing-contract’ heeft, de pragmatische insteek van de 80/20 regel zorgt juist voor de verrassingen welke je met ‘gepaste zorg’ (due dilligence) dus probeert te voorkomen. Schuld is dan ook de nieuwe winst in IT land als ik kijk naar de wet van Wirth die stelt dat software sneller vertraagd dan hardware. Hele feest van virtualisatie is hier op gebouwd en schaalbaarheid het nieuwe toverwoord. Wie maakt zich ook nog druk om servers die spam versturen als bandbreedte goedkoper is, zoals Wirth stelt is een uur computertijd tenslotte goedkoper dan een uur arbeid.
@Ewout:
Met deze uitleg als achtergrond: http://www.unisys.com/offerings/security-solutions/unisys-stealth/Brochure/Unisys-Stealth-Solution-Suite-id-597
De Unisys Stealth functie lijkt data, applications en users “onzichtbaar” te maken op basis van een tunnel. Maar daarmee “verdwijnt” het verkeer toch niet? Of mis ik hier iets?
Ook IP-v6 en SDDC doen hier niets aan af. Anders dan dat de gekozen tools in staat moeten zijn deze te herkennen en te gebruiken. Sterker nog, zonder dit inzicht kan SDDC zijn werk niet eens doen…
In mijn visie is SIEM een mogelijke volgende stap. Het vereist namelijk dat je voor de betreffende SIEM-tool(s) toegang regelt tot een of meerdere devices. Dat kunnen servers zijn maar ook netwerk apparatuur, firewalls en wat al niet meer. Wat feitelijk twee dingen impliceert: (1) – iemand denkt te weten welke hard- en software er allemaal in gebruik is en (2) – waar binnen die combi van hard- en software gegevens terug te vinden zijn die mogelijk een bijdrage kunnen leveren aan het ontdekken van een “bedreiging”.
Ik schat in dat zoiets een grote mate van try-on-error kent en daarmee dus inderdaad een behoorlijke inspanning. Initieel om erachter te komen wat-en-waar; achteraf om zeker te stellen dat dit wat-en-waar nog steeds klopt omdat je anders ineens bronnen “kwijt” bent.
Real-time bijwerken lijkt me niet zozeer een technisch vraagstuk maar eerder een menselijk vraagstuk. Zijn wij als mens (en daarmee als afdeling) in staat deze gegevens ook in dat tempo te verwerken en te vertalen naar bruikbare informatie?
Nog maar even los van het praktisch nut: stort de bedrijfsvoering nou echt in elkaar als dit soort zaken niet 7×24 uur beschikbaar en actueel zijn?