Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

Hoe grip te houden op een IT-landschap

 

Computable Expert

Will Moonen
Managing consultant, IT-visibility. Expert van Computable voor de topics Management, Outsourcing en Cloud Computing.

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…

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/5152862). © Jaarbeurs IT Media.

?


Lees meer over


 

Reacties

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 7x24 uur beschikbaar en actueel zijn?

@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?

@Will
Dat doel - niet de visie - weinig van elkaar verschillen zal ik niet ontkennen maar we stappen wel in op verschillende haltes om dat te bereiken. Want wat is behalve de blonde kuif en grote bek het verschil tussen PVV en VVD als je toch dyslectie hebt aangaande mijn reacties?

Het zou misschien schelen als je wat minder aan marketing doet want kennis verkopen of delen maakt dus wel degelijk een verschil uit, je argumentatie dat iemand niet het beleid uit kan leggen aangaande de risico's raakt tenslotte de kern van het probleem. Mijn eerste opinie (november 2010) hier bij Computable ging dus over een verstandig gebruik van de informatiespoorweg, bewustzijn is namelijk niet erg hoog. Euvel kunnen we oplossen met het verkopen van meer technologie en opstellen van onbegrijpelijk beleid zoals jij dus blijkbaar als doel hebt gesteld hebt of door het delen van ervaringen om zodoende te leren van de gemaakte fouten om deze niet eindelooos te blijven herhalen.

Sorry Will, maar als jij niet het verschil tussen een dolfijn en een haai in de blauwe oceaan van innovatie begrijpt dan hoef ik je ook niet het doel van open source uit te leggen. Want het gaat hierbij meestal dus niet om de code maar de bron, Computable is door alle content marketing wat dat betreft nogal vervuild. Om de gevraagde leeswijzer welke tot de gesprekken leidde met Valueblue te geven, de opinie Release of relatiemanagement (mei 2011) gaat grotendeels in op de uitdagingen die je ondervindt als je kiest voor de weg van de minste weerstand.

Kijkend naar politiek opportunsisme van participatiemaatschappij zul je eerst moeten leren vissen omdat je anders Crap Gemini projecten krijgt die een onwelriekende stank veroorzaken omdat kennis aangaande de materie buiten de deur is gezet. Ik weet dat ik nog lang niet alles weet en om even in te haken op je meerjarige academische studie ben ik benieuwd welke definitie je geeft aan begrip organisatie en hoe je de veranderingen daarin waarneemt. SIEM gaat tenslotte om event management welke niet alleen de 'exceptions' vanuit de infrastructuur mee moet nemen als ik mooie verhalen over de beloften van Big Data mag geloven.

@Ewout:

Ik heb een van mijn tekortkomingen aangehaald (en toegelicht met een voorbeeld) waardoor het voor mij lang niet altijd duidelijk is wat je bedoeld. Vandaar de vraag om een toelichting. Maar daar stopt het dan ook - meer zat er niet achter.
Dat je zoiets vervolgens inzet voor een aanval op mij als persoon door mijn tekortkoming over een kam te scheren met het geschreeuw van een blonde PVV-er... Ewout – dat valt me vies tegen... :-(
Nog maar los van het feite dat je, afgaande op de rest van je reactie, het blijkbaar beneden je stand vindt om ook maar iets van een toelichting te geven als er iemand langskomt met vragen – hoe dom dan ook (allez – vanuit jouw belevingswereld dan toch).

Tot slot nog twee keer terug naar de bron.

Als eerste dit artikel - hiermee heb ik een stukje kennis en ervaring willen delen met op het eind, onder het kopje met “toepassingsmogelijkheden”, een paar doelen die met deze aanpak gediend zijn. En ja, ondanks dat het niet genoemd is, het inregelen van zoiets als SIEM (of in ieder geval het proces) hoort daar ook bij.
Uiteraard zijn er veel organisatorische en technische aspecten die een rol spelen bij een succesvolle uitvoering met dito resultaat - daar ben ik me terdege van bewust! Inclusief het menselijk aspect om bijvoorbeeld dingen te camoufleren (window-dressing en pleisters plakken) in een poging er zelf beter van te worden - of toch in ieder geval niet slechter.
Maar om die kennisdeling dan te veroordelen tot “onbegrijpelijk beleid” met als (soort van) onderbouwing dat mensen rare dingen doen gaandeweg een proces… Hey, kom op kerel – we zijn hier toch om elkaar te helpen... kom dan op zijn minst met alternatieven! Dus even met de eerder genoemde doelen als uitgangspunt: hoe zou jij zoiets dan aanpakken?

Als tweede mijn studie – dat is het resultaat van een zoektocht naar een voor mij passende route om ook op een wat langere termijn zelf voor een inkomen te kunnen zorgen en tegelijkertijd een positieve bijdrage te kunnen leveren aan de ontwikkelingen onze maatschappij. Althans voor zover deze ontwikkelingen gedreven worden door de inzet van IT middelen en binnen mijn mogelijkheden liggen.
Die zoektocht ging o.a. gepaard met het sparren met anderen, een stuk zelfreflectie en het samenkomen van een paar ingrijpende gebeurtenissen. De essentie daarvan heb ik gedeeld in een artikel zodat anderen er hun voordeel mee kunnen doen. En dat met het idee dat er tussen die anderen vrijwel zeker zijn die met een vergelijkbare zoektocht bezig zijn. Dat is het - en ook hier - meer zat en zit er niet achter!
Natuurlijk kan je dit zien als een kansloze missie... prima! Maar nogmaals, als je al tot zo een oordeel komt, kom dan ook met alternatieven! Dat schiet beter op dan een uiteenzetting waarom het eigenlijk allemaal maar niks is – ook voor anderen!

:-)

@Will
Je argumentum ad populum dat ik niet met alternatieven kom is precies van dezelfde orde als gedoogconstructies van kabinet met bevriende oppositie, wat je niet benoemd hoeft ook niet opgelost te worden. Dat blond gekuifde politicus niet zo eloquent is wil echter nog niet zeggen dat er soms een kern van waarheid zit in zijn woorden.

Met mijn reacties probeer ik ook het licht in het kippenhok aan te doen want bij de opinie 'Oud maar nog niet vervangen' reageerde je dus dat ik gehinderd ben door teveel ter zake doende kennis. Aangaande de in voorgaande reactie genoemde halte, veel applicaties werden niet ontwikkeld met beheerbaarheid in het achterhoofd. Zie daar de reden dat ik stelde dat je geen 100% inzichtelijkheid gaat verkrijgen in IT landschap.

Benieuwd trouwens of je in reactie genoemde truc hier wilt delen want inzichtelijkheid tot op de transactie nauwkeurig door de gehele keten voor business processen is de 'steen der wijzen' als we het over schaalbaarheid van de workload als geheel in plaats de IT hebben.

Als jij koketteert met academische studie over organisatorische veranderingen dan moet je niet mij jouw domheid verwijten als je de INSEAD theorie van innovatie niet begrijpt. Het is ook nogal vooringenomen om te stellen dat ik visies en ervaringen niet deel, redelijk wat opinies geschreven en presentaties gedeeld. Neem bijvoorbeeld de presentatie over het sourcing dillemma:

http://www.slideshare.net/edekkinga/get-your-house-on-order

Sommigen klagen hier over mijn communicatie welke 'to-the-point' is en dus confronterend maar gesprekken met CTO's van de grote Amerikaanse technologie leveranciers zijn hierdoor wel heel verhelderend. Lees de 8-punten die ik opsom in 'Interessante presentaties CIO's en CTO's' aangaande de wereld schetsen zoals deze is (feiten) en zoals je wilt dat deze eruit ziet (hoop) als het gaat om stippen aan de horizon schetsen.

Een vrij simpel alternatief dat ik heb is gewoon gaan praten met de mensen die elke dag in de praktijk staan. Aangezien steeds meer IT-afdelingen open source oplossingen gebruiken voor wat jij beschrijft omdat business niet wil investeren stelde ik dat je achteruit een vorm van SIEM inricht. Zeker wanneer ik in een rapport van onderzoeksraad lees dat risicobewustzijn alleen aanwezig is bij de ICT-afdeling en niet of nauwelijks bij de top. En dus is er een simpele verklaring te geven voor verwijten naar security officers als deze controleur op de loonlijst staat van degene die hij/zij moet controleren.

Denk dat we dus vooral een cultuur probleem hebben in de IT, culturele antropologen zullen het een complot noemen maar je verhaal rammelt op een paar punten en gezien je reacties lijkt me empirisch bewezen dat boodschapper dan de sjaak is. Dat maakt me huiverig om ervaringen met je te delen, je lijkt me te selectief en hebt de vooringenomenheid van een verkoper.

Laten we ook niet vergeten dat een groot deel van de 'shadow IT' door business managers geaccordeerde oplossingen zijn, controleer eerst de boekhouding voordat je gaat investeren in technologie. Een overweging voor de andere lezers van deze discussie (Schaken in de cloud) is wat er zal gaan gebeuren met de adoptie van BYOD als gebruikers weten dat Big Brother de eigen werkgever is?

@Ewout:

Bedankt voor je toelichting - top! :-)

Over INSEAD en blauwe/rode oceanen: in een van je eerdere reacties noemde je dit in één adem met het betalen van pizza’s door ValueBleu en een verwijzing naar een van hun diensten genaamd BlueDolphin. Ik zag het verband niet (voor zover er dat al is) => vandaar de vraag.

Als ik ze uit elkaar trek dan is:
(1) - INSEAD een opleidingsinstituut waarvan twee professoren een visie en theorie hebben uitgewerkt rondom innovatie. Met als uitgangspunt innovatie als waarde creatie in een nieuwe markt (blauwe oceaan) versus innovatie als een concurrentie voordeel in een bestaande markt (rode oceaan).
(2) - ValueBlue een bedrijf wat ooit eens de rekening van een of meerdere pizza’s heeft betaald.
(3) - BlueDolphin een van hun diensten.

De aspecten van de rode- en blauwe oceaan waren (en zijn) een onderdeel van de opleiding - alleen gebaseerd op literatuur van andere schrijvers. In dat kader en ook als reactie op je eerdere vraag over mijn definitie van een organisatie en het waarnemen van veranderingen een paar voorbeelden.
Organisaties zijn er in verschillende smaken elk met hun eigen krachtenspel. Persoonlijk ben ik erg gecharmeerd van de 8 metaforen die Gareth Morgan gebruikt in zijn boek “Images of Organization”.
Voor het maken van markt- en bedrijfsanalyses is er o.a. gewerkt met het boek “Strategy Synthesis” (de Wit en Meyer). Het 5-sterren model van Galbraith is gehanteerd als een mogelijk instrument om invulling te geven aan een bedrijfsstrategie en bijbehorende organisatiestructuur.
Een artikel over “Organigraphs” (Mintzberg en van der Heyden) is gebruikt als een instrument om, naast de formele harkjes, in kaart te brengen hoe het er in een organisatie nou werkelijk aan toe gaat. Terwijl mogelijke invalshoeken van managers om organisaties te besturen zijn gebaseerd op een artikel van Mintzberg en Gosling met als titel “The five minds of a manager”.
Daarnaast was er een aparte module voor het onderdeel sturing met o.a. het gedrag van organisaties en hoe je daarin kan (bij)sturen. Bij de uitwerking van een van de opdrachten heb ik dat als vertrekpunt gebruikt voor een artikel over de mogelijkheden van sturing in een bedrijf- en organisatie overstijgende waardeketen (Extended Enterprise) en hoe zoiets vanuit IT gefaciliteerd kan worden (voor de liefhebbers - dit artikel kan hier opgehaald worden: http://moonen.me/documents/2014/08/output-van-proces-metingen-in-een-extended-enterprise.pdf.

Nogmaals, dit zijn voorbeelden die gebruikt zijn tijdens dit deel van mijn studie en het resultaat daarvan bij de uitwerking van een van de opdrachten. Het is zeker niet mijn intentie om me hiermee te profileren als een organisatie deskundoloog - het is slechts een eerste stap.

Dan de transacties binnen een keten - ik zal eens een poging wagen.
Als je een transactie definieert als iets wat een-op-een gekoppeld kan worden aan een bedrijfsproces (of een deel daarvan), dan is de kans van slagen het grootst bij een applicatie met een web voorkant, een .Net en/of Java “middenkant” en een SQL-achtige aan de achterkant.
Aan de voorkant wordt er dan gewerkt met Java-script injectie en een vorm van tagging om te herkennen waar een gebruiker zit en klikt - doorgaans zonder agent. De “middenkant” maakt gebruik van een agent en een vorm van tagging. Enerzijds om de executie tijd van de Java en .Net code te meten; anderzijds om de voor- en achterkant aan elkaar te knopen. Aan de achterkant wordt er ook gebruik gemaakt van een agent die de query’s herkent.
Als zoiets niet kan of het is geen web-achtige, dan zou je gebruik kunnen maken van een netwerk georiënteerde aanpak op basis van packet capturing (al dan niet in combinatie met DPI).
Afhankelijk van de plek in het netwerk waar je dit toepast kan het nodig zijn om een of meerdere SSL certificaten te installeren voor dat deel van de applicaties wat via SSL versleuteld is. Er zijn producten die gebruik maken van een agent op een server of desktop en er zijn er die werken als een appliance via een netwerk taps of span poorten.
Welke van de twee het ook gaat worden, de moeilijkheid en het werk zit hem in het configureren van de business transacties: hoe zijn die te herkennen.
Er is een tijd geweest dat hier een belangrijke taak leek te zijn weggelegd voor ARM (Application Response Measurement) - een initiatief uit eind jaren 90 van het toenmalige Tivoli en HP. Het idee was om applicaties te voorzien van een API waarmee timers bijgehouden konden worden tijdens de uitvoering van transacties. Tegenwoordig hoor of zie ik hier niks meer van.

Terwijl ik dit zo neerschrijf realiseer ik me dat het een hoop vragen zal oproepen - veel meer dan ik langs deze weg kan beantwoorden. Daarom stel ik voor om een afspraak te maken zodat ik dit verder kan toelichten en de vragen kan beantwoorden.

Tot slot…
(1) - Ik hoop dat je met deze uiteenzetting me voor de toekomst in ieder geval het voordeel van de twijfel gunt. Ook als mijn betoog (te?) veel weg heeft van een sales-pitch door mijn enthousiasme.
(2) - Van mijn kant zal ik een volgende keer wat meer tekst-en-uitleg geven bij uitspraken als “te veel gehinderd door ter zaken doende kennis”.
Maar op het moment dat ik in beide gevallen alsnog tekort schiet: nogmaals, stel vragen!

:-)

Beste Will,

Precies wat ik bedoel. Automatiseren is standaardiseren en door standaardiseren besparen. Tenminste, dat zou je denken. De praktijk is telkens weer dat men wielen opnieuw aan het uitvinden is, oude wijn, nieuwe zakken, en vooral veel blokkades aan het opwerpen is zichzelf in stand te houden.

In weerwil wat velen roepen of aandragen aan allerlei inzichten, alternatieven en oplossingen, IT is er om zaken te automatiseren en daarmee een begrijpelijk en hanteerbaar landschap in stand te houden. IT is niet commercieel, IT is niet politiek. Dat is iets wat maar weinig professionals zo willen zien. Soit, so be it. Maar roep dan niet dat alle problemen waar men tegen aan kijkt en waar de hausse van de artikelen en reacties hier in computable, zoveel facetten en oorzaken hebben.

IT is er om zaken te stroomlijnen en te verzelfstandigen en daar hoort ook het standaardiseren van het IT landschap bij. De uiteindelijke kern van het verhaal is dat je geen mankracht nodig hebt iets in beweging te houden.

Due Dilligence
Persoonlijk en professioneel heb ik Due Dillegence een volkomen idiotie gevonden. Klein voorbeeld. In 1995, werkende voor Holan in Amstelveen, ABN-Amro, kwamen er twee kwartiermakers die een inventarisatie wilde maken van de hele spullenboel in het gebouw. Ik hoefde me maar om te draaien om een ordner te pakken en die te overhandigen aan twee stomverbaasd kijkende 'consultants'.

Wat of de bedoeling was? ......

Again, voor mij een gewoon standaard die door velen graag en telkens weer opnieuw moet worden uitgevonden en uitgevoerd.

Onzinnig dus.

Beste NumoQuest (Rene?),

Ik ga een heel eind mee in je visie. Toch ook een paar nuances.

In mijn optiek is automatiseren eigenlijk niks anders dan mensenwerk vervangen door machines. Dat daarbij een voorkeur is voor een hoge mate van standaardisatie is begrijpelijk. Immers, op die manier is er het meest uit te slepen.

Het probleem van standaarden is dat het er zoveel zijn. Welke combinatie ga je gebruiken?
Op enig moment worden er dan toch keuzes gemaakt. Wat als het geheel niet brengt wat verwacht is en er toch (meer?) mensenwerk nodig is. Ga je dan door met wat je hebt en neem je de tekortkomingen voor lief? Of ga je terug naar af om opnieuw te beginnen?
Als je aan het begin of het eind van een dergelijk traject zit, dan zal het antwoord waarschijnlijk niet al te moeilijk zijn. Maar wat als je ergens rond het midden zit… zie daar de opening naar OSI perikelen op laag 8, 9 en 10.

Maar automatiseren zonder enig menselijk handelen (letterlijk) - ik weet het niet. Als menselijk handelen niet meer nodig is en de machinerie van het automatiseren hapert, wie gaat dan waar beginnen met een analyse? Laat staan oplossen?
Ik bedoel, tuurlijk zullen er events afgevuurd worden als er iets mis gaat. Maar zeker bij 2 of meer verstoringen tegelijk zijn dat vaak “symptomen”. Als er voor normaal bedrijf helemaal geen mensenwerk meer aan te pas komt, wie is dan nog in staat om op een dergelijk moment de root-cause van een probleem te bepalen?

Ook de business case zal een belangrijke rol spelen. Als het automatiseren een onderdeel is van een innovatie programma waar eerst bezuinigd wordt om de daaropvolgende innovatie (mede) te financieren, dan zullen er vrijwel zeker andere keuzes gemaakt worden dan wanneer het een onderdeel is van een programma om de winstgevendheid van het bedrijf te verbeteren.

Zo ook een due dillegence - vertrouwen is prima maar controle is beter (niets menselijks is ons vreemd - toch?).
Als een zekere installed base op papier een bepaalde verwerkingscapaciteit heeft met een zekere boekwaarde en een exploitatie budget van de nodige miljoenen, dan zou ik dat toch wel even willen tjekke. Ook als alles goed geadministreerd en gedocumenteerd is.
Achtergrond: ooit was ik (op afstand) betrokken bij een fusie tussen twee internationaal opererende IT bedrijven. De een had in zijn boeken een eigen zeekabel staan. Voor de ander was dat een meer dan welkome verbinding. Bij nadere controle van het contract(!) bleek dat die kabel eigenlijk geen eigendom was maar meer een (soort van) meerjarige huur met automatische verlenging.
Maar dat gezegd hebbende, die controle, dat houdt natuurlijk ook een keer op. Alleen maar doorborduren op wantrouwen lijkt me nou ook weer geen optie. Das funest voor alle ontwikkelingen en vooruitgang… zelfs als die vooruitgang gebaseerd is op drie stappen vooruit met twee stappen terug.

:-)

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×