Waarom je geen ICT architect moet worden

In de laatste uitgave van TIEM staat een artikel dat ik met Ron vd Burg schreef, getiteld: "Waarom je geen ICT architect moet worden". Het artikel is hier te downloaden.

Als u wilt reageren: Graag! Hieronder staat een link.

.

.

.

.

.

. 

.

.

ISA @ WORK

Afgelopen zaterdag ben ik op de ISA@WORK conferentie geweest.

Elk jaar wordt de hele Infrastructure, Security en Architecture (ISA) community van LogicaCMG in Nederland (ongeveer 500 man/vrouw) uitgenodigd voor dit evenement. Hoewel het op een zaterdag was, en het niet werd betaald, kwamen er ruim 120 man opdagen.

De opening werd verzorgd door Paul Schuyt, Chief Executive van LogicaCMG in Nederland.

Er waren verschillende parallelle tracks  over diverse onderwerpen. De presentaties die ik bezocht heb waren:

Publiceren kun je leren. Een presentatie van Rini van Solingen over ervaringen van de schrijfklas die hij organiseerde binnen LogicaCMG. LogicaCMG wil dat meer consultants artikelen gaan publiceren, en Rini is een ervaren publicist (zie bijvoorbeeld hier). Zijn presentatie (zonder Powerpoint!) was erg inspirerend. In zijn schrijfklas schreven 12 consultants in 8 weken een publicabel artikel.

RES  presenteerde hun producten PowerFuse en Wisdom. Powerfuse kan worden gebruikt om settings van gebruikers mee te nemen naar elke PC of laptop waar hij op werkt. Het is een meer robuuste uitvoering van Microsoft's roaming profiles. Wisdom is een product om software op een gestandaardiseerde manier uit te rollen op meerdere systemen. Hierdoor worden de systemen 100% identiek.

Na de lunch gaf Lex Boeré (Lead Technical Architect SOA technology) de presentatie "SOA in ISA". Zijn boodschap was dat nu alom SOA's worden geïmplementeerd ook de infrastructuur competentie hier steeds meer mee te maken gaat krijgen. Vooral de WS-* standaarden hebben een grote impact op de inrichting van infrastructuren en security. Zijn presentatie erg informatief en verhelderend.

De dag eindigde met een kort optreden van stand-up comedian Harry Glotzbach (ook bekend als Barry in een bekende reclame), en met een hapje en een drankje.

Network based infection detection

Een paar dagen geleden woonde ik op de Hanzehogeschool in Groningen een presentatie bij van Prof. Dr. Nasir Memon van de Polytechnic University in Brooklyn, New York. De presentatie ging over een nieuw systeem dat de universiteit ontwikkeld heeft voor het detecteren van computers die met malware zijn geïnfecteerd.

Kwaadaardige (malicious) software wordt normaal gedetecteerd en tegengehouden door virus scanners, IDS systemen, firewalls, enz. Het probleem hierbij is dat de meeste systemen hiervoor zogenaamde handtekeningen (signatures) gebruiken waarmee bepaalde software kan worden herkend. Kwaadaardige software wordt echter steeds meer stealthy en dus onzichtbaar. Hierdoor wordt door systemen die vertrouwen op signatures zo'n 80% van de aanvallen door kwaadaardige software niet opgemerkt. Het team van prof. Memon probeerde daarom een andere aanpak.

Deze aanpak is om te focussen op wat er gebeurt nadat een systeem geïnfecteerd is. In plaats van het controleren of een systeem geïnfecteerd is (hetgeen kan worden verhuld door bijvoorbeeld rootkits), wordt het netwerk verkeer van de systemen geanalyseerd. Hiervoor worden op enkele plaatsen in het netwerk zogenaamde SynApps geplaatst. Deze applicaties ontvangen alle data die door het netwerk gaat (bijvoorbeeld door ze te koppelen aan een span-poort van een core switch).

Omdat in een gemiddeld netwerk veel data wordt verstuurd, wordt de data zelf niet opgeslagen. In plaats daarvan wordt de data (payload) in de netwerk pakketten gehashed. Deze hash wordt dan opgeslagen, samen met extra informatie over de pakketten, zoals de source en destination, de tijd en het soort data. Verschillende technieken worden gebruikt om vast te stellen of de data bijvoorbeeld een MP3 stream of video.

Op deze manier wordt een compressie bereikt van 1:50, waardoor de data tot enkele weken bewaard kan blijven. Uiteraard kan de originele data niet meer gereconstrueerd worden. Het is echter wel mogelijk te controleren of data meer dan eens is verzonden, of dat data door een relaying system wordt doorgestuurd naar andere systemen. Dit wordt gedaan door te controleren of de gehashte data al in de database staat en hoe vaak. De data wordt opgeslagen met een systeem dat is gebaseerd op Bloom filters, die het mogelijk maken om data zeer efficiënt op te slaan, zodat het zeer snel weer opgevraagd kan worden. Bovendien is het mogelijk op een makkelijke manier naar patronen te zoeken.

Een aantal van die patronen zijn bijvoorbeeld:

• Systemen die steeds trager worden.
• Systemen die vaak worden ge-reboot.
• Relay systemen die data onveranderd versturen naar andere systemen.
• Systemen die data naar IP adressen sturen die niet eerst door een DNS query zijn opgevraagd.
• Enzovoort.

Deze patronen kunnen door de software worden gecombineerd zodat een top 10 van verdachte systemen ontstaat.

Data wordt enkele weken bewaard. Dit maakt het mogelijk om nieuw ontdekte exploits die al enkele systemen hebben geïnfecteerd, terug te zoeken en om zodoende systemen te vinden die al eerder ware geïnfecteerd. Deze systemen kunnen dan worden gerepareerd.

Het soort kwaadaardige software die op deze manier kan worden gevonden is:

• botnets;
• spyware;
• trojans;
• rootkits;
• viruses, worms.

Professor Memon is naarstig op zoek naar bedrijven die het systeem willen inzetten. Zijn universiteit kan dan leren van de resultaten, en de bedrijven hebben er een goed malware detectiesysteem bij. Iets voor uw bedrijf?

Non-functional requirements

Elk systeem kent requirements, waaraan het systeem moet voldoen. Het opstellen van requirements is geen eenvoudige taak. Er zijn zelfs speciale pakketten op de markt voor het vastleggen en correleren van requirements.

De meeste requirements zijn functioneel (functional requirements). Ze bepalen wat het systeem moet doen, zoals: "Na het invoeren van de klantorder moet een orderbevestiging worden geprint".

Naast de functional requirement zijn er ook Non-functional requirements. Deze requirements worden ook wel de "-abilities" genoemd. Enkele voorbeelden van non-functional requirements zijn:

• Availability (beschikbaarheid)
• Scalability (schaalbaarheid)
• Stability (stabiliteit)
• Reliability (betrouwbaarheid)

Naast deze -abilities zijn ook de volgende zaken non-functional requirements:

• Kosten/licentiestructuur
• Security
• Uptime
• Robustness
• Documentatie
• enzovoort enzovoort

Gebruikers van systemen stellen deze non-functional requirements vaak niet expliciet vast als eisen, maar ze hebben er wel verwachtingen over.

Het is de taak van de IT architect of de requirements manager om ook de niet uitgesproken  non-functional requirements boven tafel te krijgen. Dit kan behoorlijk lastig zijn. Zaken die voor klanten of eindgebruikers vanzelfsprekend zijn, zijn dat niet altijd voor iedereen. Denk ook aan de eisen die de beheerders stellen aan het systeem (is er een back-up window?).

Een groot deel van het budget voor een systeem kan bepaald worden door de non-functional requirements ("het systeem moet natuurlijk wel goed samenwerken met de bestaande systemen" of "De website mag nooit uit de lucht zijn"). Het is daarom belangrijk om deze requirements te kwantificeren: Hoe erg is het als de website elke dag 5 minuten niet beschikbaar is?  En als het 500.000 euro kost om dit te bereiken, is het dan nog steeds belangrijk?

De acceptatie van een systeem is vaak afhankelijk van goed geïmplementeerde non-functional requirements. Een website kan nog zo mooi en functioneel zijn, als het laden ervan 30 seconden duurt, dan zijn uw klanten verdwenen!