Vanguard Security Conference 2009

Vanguard Security Conference 2009 - dag 4

2009-06-04T20:27:00.002+02:00

Vandaag alweer de laatste dag van de conferentie. Wat gaat het toch hard als je zo intensief bezig bent, zeg!

De eerste sessie van vandaag ging over de nieuwe security functies in ingebouwd zijn in DB2 versie 9. Niet alleen draait dit op mainframe, maar ook op gedistribueerde omgevingen als UNIX. Wat dat betreft een behoorlijke multi-platform database omgeving.

De uitdagingen die nu zijn geadresseerd zijn onder meer het probleem dat er tot nu toe weinig controle bestaat over privileged users als SYSADM en SYSCNTRL, users die door DBA’s worden gebruikt. Een ander probleem is het de matige individuele accountability wegens het gebruik van zogenaamde common users. Common users worden ook gebruikt door remote connections als SAP, Linux of WAS. Dit wordt veroorzaakt door gebruik te maken van een 3-tier architectuur: een enduser vanaf een client authenticeert zich via en stuk middleware. Deze middleware verzorgt vervolgens de connectie met DB2 en gebruikt een apart, common dus, user ID met password voor alle connecties naar DB2. Het is deze common user waarvan binnen DB2 de autorisaties worden afgevraagd.

Een ander punt is dat database wijzigingen moeilijk te auditten zijn en het gebruik van impliciete privilieges. Dat laatste is eigenlijk het best te vergelijken met een soort van root access. Zodra een DBA een tabel of een ander object aanmaakt wordt zijn user ID de own van dat object en krijgt daarom alle toegangen tot dat object.
De oplossingen die IBM voor deze problematiek heeft bedacht zijn de concepten van een DB2 Trusted Context en van DB2 Roles. Een trusted context is een DB2 object dat gebruikt wordt om toegangen (zeg maar autorisaties) door users en applicaties mee te beheren.

Een DB2 role is een DB2 object dat uitgegeven privileges kan bevatten of eigenaar van andere DB2 objecten kan zijn.
Aangezien het beiden DB2 objecten zijn, kunnen ze via standaard SQL queries worden toegevoegd.

Om de accountability te verbeteren zijn een aantal maatregelen genomen. De audit logs hebben een uitbreiding ondergaan en het is mogelijk geworden om, in verband met user propagatie, gebruik te maken van EIM (enterprise identity mapping). EIM is een LDAP oplossing waar users aan elkaar kunnen worden geassocieerd.
Met de upgrade naar versie 9 is ook het redbook Securing DB2 en implementing MLS (SG24-6480) op z/OS hierop aangepast. Hier zijn alle nieuwe security features in te vinden: DB2 roles, trusted context, identity propagation en gebruik van SSL.

De laatste sessie van de dag ging over SOA/XML dreigingen model en nieuwe SOA/Web 2.0 aanvallen en dreigingen.
Ik heb nu voor het eerst een classificatie gezien van de verschillende typen XML en Web 2.0 dreigingen gezien. Een classificatie die als een “industry standard” zal gan gelden. Ten aanzien van XML dreigingen worden de volgende categorieën onderscheiden:
- Payload / content threats. Ten aanzien van end users moet je hierbij bijvoorbeeld denken aan XSS en malicious Active content. Ten aanzien van de back end systemen zijn SQL injection, BAPI protocol aanvallen Universal tunnel misuse een aantal voorbeelden.
- XML abuse/misuse. Voorbeelden hiervan zijn XML injection, XPath injection, XQuery injection en XXE.
- XML Structure manipulation. Denk hierbij aan entity expansion en schema poisoning.
- Infrastructure aanvallen als bijvoorbeel misuse of diagnostic services.
Ik wil eventjes XPath injection apart noemen. XPath is een programmeertaal waarmee je aan onderdelen in een XML document kunt refereren. Je kunt dus zonder kennis van XML documenten de hele documenten opnieuw opbouwen. Over deze manier van aanvallen is een goede whitepaper geschreven. Dit is te vinden op: www.packetstormsecurity.org/papers/bypass/Blind_XPath_Injection_20040518.pdf
Ten aanzien van Web 2.0 worden dreigingen als volgt geclassificeerd:
- Federation threats. Hierbij richten de dreigingen zich op een aantal problemen rond identity federation. Als voorbeeld je reputatie. Stel je verkoopt spullen via eBay of zo en hoe meer je verkoopt hoe beter je reputatie wordt. Zou het dan niet handig zijn om zelf je reputatie op te vijzelen door zelf een aantal accounts aan te maken en dan zelf (uiteraard zo goedkoop mogelijk hahaha) je eigen spullen te kopen? Wat heet dit met federation te maken denk je dan? Nou, eBay accepteert al een geldig e-mailaccount bij wijze van authenticatie. Als je nu bijvoorbeeld 100 e-mailadressen aanmaakt en dan je eigen spulletjes koopt, dan vertrouwt iedereen de geweldige verkoper. Hij heeft immers toch zoveel verkopen gedaan? Koud kunstje om dan, met je verkoper credentials, een grote aankoop te doen en die vervolgens niet te betalen; dat hadden ze niet verwacht. Wat ik hier beschrijf staat bekend als de Sybil attack.
Omgekeerd kan ook: je maakt een boel accounts aan waar nauwelijks naar credential wordt gevraagd en je misbruikt die om bijvoorbeeld iemand te stalken of andere onaangename dingen mee uit te vreten (denk ook eens aan het heen-en-weer schuiven van geld via bijvoorbeeld Paypal en het uiteindelijk op een rekening parkeren). Deze praktijken vallen onder de noemer Whitewashing.
- Client side browser threats. Denk hierbij aan het exploiteren van kwestbaarheden en onvolkomenheden in de AJAX engine bij het gebruik van Java scripts die in client browsers worden uitgevoerd.
- Data syndication threats. Dit heeft te maken met (vooral) cloud computing. Het is niet meer voldoende om naar de traditionele beveiligingsdriehoek te kijken, maar om te kijken naar zaken als: Data federation. Waar komt de data vandaan, kun je het vertrouwen? De dreigingen hier zijn malicious content en RSS aanvallen. Ja, ook RSS kan misbruikt worden om aanvallen uit te voeren. Je kunt er namelijk XSS en XML injection attacks mee uitvoeren en malicious code mee afleveren. Vertrouw je je RSS abonnement dat je veilige data binnenkrijgt? Think again.
- Social networking threats. Risico’s hierbij zijn, afgezien van bijvoorbeeld Cross Domain Scripting (XDS) een aantal social networking worms als bijvoorbeeld Samy en QT. Die krengen verspreiden zich razendsnel, sneller dan worms via “gewoon” internetverkeer. QT is trouwens een MySpace worm.
- Cloud en Mashup threats and attacks. Een Mashup is programmecode dat door derden is geschreven. Probleem 1: hoe weet je dat je deze mashup code kunt vertrouwen??? Zelfde verhaal eigenlijk voor widgets. En dan de beruchte cloud weer he. Ik blijf het zeggen: virtualisatie is al langer dan 20 jaar oud. Mainframe; moet ik nog meer zeggen? Dat platform is ten miste vertrouwd. Met de huidige technologieën weet je het niet meer. Zelf de definitie van een cloud varieert en betekent voor verschillende mensen verschillende dingen. Denk maar aan bijvoorbeeld Web 2.0 applicaties en API’s, cloud service applicaties (Google Apps, Salesforce.com Zoho) en virtualisatie van computerresources (Amazon EC2 en S3, AWS). Ik zal me hier beperken tot de, zeg maar, uitdagingen met betrekking tot cloud computing: hoe ga je om met privileged user access? Hoe ga je om met compliance aan wet- en regelgeving? Waar bevindt je data zich? Is je data gescheiden van anderen? Weet je wel of recovery van je data mogelijk is? Kun je zaken in de cloud onderzoeken?

Ik zal even over mijn hart strijken en een aantal adviezen geven om de hier genoemde dreigingen tegen te gaan. Doe aan “asset tracking”. Weet waar je data, sites, applicaties enzo zich bevinden. En maak daar iemand verantwoordelijk voor!! Meet regelmatig je beveiliging; voer zware vulnerability tests en scans uit. Train je eigen programmeurs in secure coding (denk ook eens aan OWASP in dit verband). Kijk verder dan je perimeter lang is; er zijn altijd externe applicaties die jouw sites kunnen platleggen als ze zelf onderuit gaan. Kijk ook goed naar cloud en Web 2.0 security producten en services. Ten slotte: werp zoveel mogelijk barrières op (maatregelen) als je maar kunt doen om aanvallers tegen te houden.

Wat ik zelf wel een aangename verrassing vond bij het napraten na de laatste sessie was dat er een aantal mensen naar mij toekwamen om mij nog eens te bedanken voor mijn sessie. Amerikanen kunnen nogal overdrijven en van meerdere personen heb ik de kwalificatie “awesome” (wat dat ook zijn moge?) meegekregen. Jaja, en nu maar afwachten hoe mijn sessie evaluatie uitvalt………..

Het allerhoogste hoogtepunt van deze conferentie voor mij was toch wel de uitnodiging van de CEO/CTO van Vanguard om met hem en een aantal in zijn suite over RBAC en mijn visie daarop te praten. Dit was echt een eer!

Vorig jaar sloot ik af met een aantal vreemde opmerkingen die ik van Amerikanen had gehoord. Deze keer niet. Denkend aan cloud computing heb ik twee voor mij, nieuwe termen gehoord: MEATcloud en cloudFLUX. Geen idee wat het is. Nu ik ze heb gebruikt kan ik in ieder geval zeggen dat ik 100% buzzword compliant ben!

Dit is mijn laatste blog voor de conferentie van dit jaar geweest. Misschien tot een volgende??

John Rudolph

Vanguard Security Conference 2009 - dag 3

2009-06-04T00:31:00.001+02:00

Vandaag de derde dag. Ik had vandaag zoiets van laat ik eens een sessie volgen over hoe je je thuispc’s, laptops en desktops, kunt en moet beveiligen. Niet alleen om ongewenste software buiten de deur te houden, maar zeker ook om zaken als diefstal van privé gegevens en identity theft te voorkomen. Waar de meeste mensen niet aan denken is dat ze, als ze een nieuwe pc/laptop hebben gekocht en vervolgens hebben geïnstalleerd, het account dat ze hebben aangemaakt over administrator bevoegdheden beschikt. Zeker in het geval als je je pc/laptop vooral voor internet toepassingen (surfen, chatten, e-mail etc. etc.) gebruikt het niet zonder risico’s is om continue over administrator rechten te beschikken. Het advies is dan ook om een tweede account, een soort van guest account, aan te maken en daarmee je internetactiviteiten uit te voeren.

Op zich een goede sessie, maar volgens mij eigenlijk meer bedoeld voor, zeg maar, de niet security-professionals. Ik kan me voorstellen dat dit soort sessies bijzonder nuttig zijn voor buurtgemeenschapsclubjes, kaartclubjes, senioren-die-willen-internetten clubjes enzovoort.

Nog een klein tipje om te zien wat er allemaal voor minder fraais met je thuispc/laptop kan gebeuren door kwaadwillenden is te vinden op YouTube. Er zijn zo’n 80 filmpjes van ongeveer 5 minuten elk te vinden als je zoekt naar “Household hackers”. Probeer maar eens.

Sja, toen werd het tijd voor mijn sessie. Achteraf moet ik toch nog constateren dat ik best wel nerveus was. En dat ondanks de voorbereidingen en het tig-maal doorlopen van mijn presentatie en speakernotes en ondanks de aanmoedigingen van vrienden en bekenden (you can do it, you’re OK, we know you can en meer van dat soort opbeurende taal). De zaal was vol met meer dan 20 belangstellenden. Onder de aanwezigen bevond zicht en vrij zware delegatie van Vanguard zelf, waaronder de CEO/CTO, Ronn Bailey. Om mezelf wat op gemak te stellen ben ik maar begonnen met het vertellen dat ik uit Nederland kwam en dat “Dutch” niet noodzakelijkerwijs een positief iets is. Bij een Dutch party word je geacht om zelf je drank mee te nemen, we praten Double-Dutch, als je iets pas durft nadat je een behoorlijke hoeveelheid alcohol hebt ingenomen heb je Dutch courage. Vervolgens hield ik iedereen voor dat dit een Dutch session was, die door de mensen zelf ingevoerd moest worden 

Nou, dat heb ik geweten. Ik had anderhalf uur voor mijn presentatie en ben tot halverwege mijn slides gekomen. De sessie was bijzonder levendig met meer vragen en discussie dan dat ik met de andere sesies heb meegemaakt. Als dit representatief is voor hoe men in de USA tegenover RBAC staat, en waar men met de invoering van RBAC staat, is hier nog ont-zet-tend veel werk te doen. Het grootste probleem is eigenlijk dat iedereen een eigen invulling geeft van de definitie van RBAC. Voor de een is het het groeperen van alle gebruikers van bepaalde applicaties (en dat noemen ze rollen), voor een ander is het groeperen van autorisaties per platform. Het model dat ik ze voorhield, gebaseerd op het NIST model was werkelijk een eye opener voor een aantal mensen. Toen ik overging op de challenges die je –als security persoon- tegenkomt bij het implementeren van RBAC gaf dat zoveel stof tot discussie dat ik dit op en gegeven moment heb afgekapt en ben doorgegaan. Vrijwel de hele zaal discussieerde mee! Wat men ook graag wilde weten is hoe je CobiT, inclusief controls vanuit ISO27002 kunt gebruiken bij het inrichten van RBAC-processen.

Zodra ik weer thuis ben uit Jacksonville zal ik mijn presentatie op onze site plaatsen.

Een ander issue was dat de aanwezigen wilden weten hoe je nu vast kunt stellen welke rechten er nu in een bepaalde rol moet opnemen, hoe je kunt voorkomen dat er meer rollen dan medewerkers gaan ontstaan.

Aansluitend op mijn sessie was er een speciale sessie met specifiek daarvoor geselecteerde genodigden in de suite van de CEO, waar men mij verder wilde spreken over RBAC en mijn visie hierover wilde horen. Hoe zie ik de positie van RBAC, wat zijn manieren om tot goede rollen te komen, wat is de te verwachten return on investment (en op welke manieren) als je met RBAC “aan de slag” gaat. Hoe ga je in je rollenmodel om met wijzigende compliance eisen ten aanzien van wet- en regelgeving etc. etc. Deze bijeenkomt heeft ook nog zo’n anderhalf uur geduurd.

De dag heb ik afgesloten met het volgen van een sessie over “gotchas” en gebruik van digitale certificaten op het z/OS mainframe. Deze sessie werd gegeven door een instructeur die zich binnen IBM (RACF onwikkel lab in Poughkeepsie) al 12 jaar bezighoudt met PKI implementatie op z/OS mainframe. Een van de ontwikkelingen op dit gebied die ik alleen zal noemen omdat dit volgens mij een mainframe specifiek iets is. Dit is het gebruik van Virtual Key Rings. Met het gebruik hiervan kun je een certificaat impliciet associëren met verschillende Key Rings. Grappig te merken dat virtualisatie ook hier heeft toegeslagen 

Morgen de laatste dag van deze conferentie. Ik ga de laatste twee sessies volgen. De eerste gaat over uitbreiding en verbetering op beveiligingsfuncties voor DB2 versie 9. De tweede gaat over SOA/XML threat model. Morgen, in mijn laatste blog vanuit Jacksonville, zal ik hiervan verslag doen.

John Rudolph

Vanguard Security Conference 2009 - dag 2

2009-06-03T00:37:00.002+02:00

De tweede dag begon waar dag-1 eindigde. Met een enorm technische sessie over z/OS mainframe kwetsbaarheden, vooral in relatie tot enablement (mooi woord, niet?) van webconnectiviteit. Als eerste werd ingegaan op een aantal consequenties als je een Web Application Server (afgekort tot WAS) implementeert als frontend voor mainframe transactieservers als bijvoorbeeld CICS. Gebruik van WAS maakt gebruik van een stuk extra middleware noodzakelijk: een CICS Transaction Gateway (afgekort tot CTG). En daar beginnen de problemen, nog afgezien van de securityvoorzieningen die in WAS zelf kunen worden uitgenut. Plaats je de CTG niet op het mainframe, dan wordt RACF (of ACF2 of TSS) niet geraadpleegd bij het afvragen van autorisaties. Plaats je ‘m wel op het mainframe, dan wordt RACF (of ACF2 of TSS) dus wel geraadpleegd. Een ander aspect is dat CICS transactiebeveiliging niet meer wordt gebruikt. Voor WAS bestaan er geen transacties, er worden programma’s uitgevoerd. Dit betekent dat je binnen CICS van transactiebeveiliging zult moeten migreren naar programmabeveiliging. Een andere, serieuze, kwetsbaarheid is dat alle functionaliteit die via de webinterface wordt toegevoegd, ook via de traditionele 3270 interface uitvoerbaar is. Het advies is dan ook om een van beiden uit te schakelen!
Een kritisch punt over WAS beveiliging: de beveiliging die geboden wordt is nog vrij basaal en onvolwassen, zeker vergeleken met de andere, meer traditionele producten als bijvoorbeeld CICS en DB2.

Over DB2 gesproken, ook die kun je via een CTG via WAS benaderen. Gebruik je hiervoor direct access (dus niet via CICS naar DB2, maar rechtstreeks) dan zit je met het volgende: direct access maakt gebruik van een JDBC-connector. Laat deze connector nou gebruik maken van een hard coded (!!!) userid en een hardcoded (!!!) password. Gelukkig is deze kwetsbaarheid opgelost in DB2 versie 9.

Ik riep altijd dat het mainframe niet gevoelig is voor virussen (malware in het algemeen) dat vanaf het internet overal en nergens opduikt. Ik moet dit toch even nuanceren. Dankzij het gebruik van NFS en SMB file systemen kun je directories/bestanden als netwerk shares beschikbaar stellen. Je kunt natuurlijk daar ook van buitenaf komende bestanden in opslaan. En ja hoor, tuurlijk heb je een bestand met een virus te pakken. Nu zal dat virus geen kwaad kunnen op het mainframe zelf, maar het mainframe fungeert in dat geval wel als gastheer!

Ik wil het, wat betreft de soms uiterst technische mainframe sessies hierbij laten; ik denk dat er anders teveel lezers van min blog zullen afhaken 

Een andere, boeiende, sesie die ik heb gevolgd ging over “Identify and Manage Security Exposures in Your Disaster Recovery Strategies". Een aantal uitdagingen bij het opstellen van DR strategieën zijn dat recovery management vaak als het ware verzuild is geraakt tussen een aantal partijen, elk met hun eigen belang. Zo is er de storage manager die zich voornamelijk bekommert om de data in de vorm van bits en bytes, zonder inzage te (willen) hebben in de applicatie(s) waar deze data belangrijk voor is. Dan is er de applicatiemanager, die alleen naar zijn eigen applicatie kijkt en geen inzicht heeft in het belang van andere data; hetzelfde geldt eigenlijk ook voor de business manager, die alleen naar zijn eigen processen kijkt. Tot slot is er de DR manager die moet zien te laveren tussen de verschillende betrokken belanghebbenden. Andere uitdagingen zijn bijvoorbeeld, in de huidige economische tijden, het terugdringen van budgetten ten behoeve van uitwijklocaties, uitwijktesten etc. De conclusie van de presentatie kwam neer op een risk based benadering, bij voorkeur met gebruikmaking van goede risico analyses, niet alleen een BIA, maar ook een afhankelijkheidsanalyse: wat zijn de primaire bedrijfsprocesen, van welke informatiesystemen maken deze processen gebruik en wat is de door de gebruikte informatiesystemen gebruikte infrastructuur.
Een andere conclusie van deze presentatie was dat uitwijktesten bijzonder goed voorbereid moeten worden: heb je de juiste (versie) van de data en programmatuur? Kun je de juiste infra opbrengen binnen de vastgestelde tijd? Zijn de juiste mensen aanwezig? Zijn de uitwijkprocedures actueel?

De aardigste anekdote van de spreker was die over een organisatie dat zijn uitwijkcentrum aan de andere oever van de rivier had geplaatst. Alsof een overstroming maar aan een oever voorkomt…….

Hierna heb ik een sessie gevolgd over het doen van Wireless Assesments. Een tak van sport waarvan ik vind dat er eigenlijk nog (veel te) weinig kennis over aanwezig is. Door het ontbreken van touwtjes en lijntjes zul je toch iets anders moeten kijken naar wireless apparatuur en het gebruik daarvan. Radiogolven kunnen immers dwars door muren heen gaan en zelfs onbedoeld worden gereflecteerd. Denk maar eens aan je autoradio als je opeens een andere zender door je voorkeurszender heen krijgt, dat een tel later weer is verdwenen. Een probleem is natuurlijk dat je niet kunt ontdekken dat iemand je wireless netwerk afluistert; er wordt immers niets fysieks ingeplugd. Een ander onderwerp van gedachten is dat het bereik van een wireless access point afhankelijk is van de kwaliteit en type van de gebruikte antenne.

Vanuit beveiliging bezien zijn zaken als een bijzonder matige authenticatie en encryptie een bron van zorg evenals de prijs, grootte en makkelijke installeerbaarheid van wireless apparaatjes.

Qua encryptie zijn er een aantal mogelijkheden; WEP, WPA, WPA2 en TKIP. De eerste (WEP dus) is inmiddels zodanig verouderd dat dit niet meer gebruikt behoort te worden. In mooi engels: obsolete since 2001! Mocht er nog iemand zijn die dit gebruikt, vervang WEP door (minimaal) WPA. een belangrijke reden hiervoor is dat WEP binnen minuten te kraken is; manieren om WEP te kraken zijn uitgebreid te vinden op internet, waar je ook gratis tools & drivers hiervoor kunt vinden. Zoals altijd is Google je beste vriend; google maar eens op “how to crack wep”.

Een aantal praktische, en gratis, tools om de kwaliteit van je wireless implementatie te beoordelen zijn onder meer:
• Network stumbler (www.netstumbler.com)
Een aantal kenmerken van network stumbler zijn dat het alleen voor het Windows operating system geschikt is. Het kan signaalsterktes monitoren, SSID’s en MAC adressen uitlijsten, wireless activiteiten monitoren en loggen, wireless apparatuur ontdekken en ondersteunt zelfs GPS. Alleen, wanneer een SSID geen broadcast doet, zal dit tool het SSID niet opmerken.
• De aircrack-ng suite (www.aircrack-ng.com)
Dit tool is iets uitgebreider; het is geschikt voor zowel Linux als Windows. Het bevat packet sniffers, packet injectors, een capture file decoder en, in tegenstelling tot networkstumbler, zal het ook SSID’s ontdekken die geen broadcast doen. Ook bevat dit tool meerdere typen van crackers, waaronder encryption.
• De backtrack live CD (www.remote-exploit.org/backtrack.html)
Dit is een bootable ISO image, zodat je geen software hoeft te installeren om een beoordeling van een wireless network te doen en is qua functionaliteit vergelijkbaar met aircrack.

Disclaimer: ik noem deze tools uitsluitend en alleen met als gedachte dat ze netwerkbeheerders en auditors kunnen helpen bij het beoordelen van de kwaliteit van een wireless netwerk.

De laatste sessie die ik vandaag heb gevolgd betrof het klaar zijn voor de volgende RACF-audit. Aangezien ik zelf mijn aandeel van mainframe security & integriteitsaudits doe, was het voor mij bijzonder prettig te ontdekken dat een KPMG auditor, met meer dan 15 jaar systeemprogrammeringservaring, dezelfde onderzoeksgebieden, instellingen, configuratie issues en aanbevelingen voor security instellingen in de presentatie heeft benoemd 

Morgen is mijn dag; dan ben ik aan de beurt met mijn sessie en ik moet eerlijk toegeven dat het een beetje begint te kriebelen. In mijn volgende blog zal ik hiervan een verslag opnemen. Nu eerst een biertje, een hapje eten en daarna een laatste herhaling / doorlopen van mijn presentatie…

John Rudolph

Vanguard Security Conference 2009 - dag 1

2009-06-02T04:15:00.003+02:00

De conferentie is losgebarsten! Na gisteren bijgekomen te zijn van de reis (en de “buttlag” die ik aan 10 uur vliegtuigstoelen heb overgehouden) kon ik min of meer uitgerust aan de dag beginnen.
Evenals vorig jaar begon de dag met de key note presentatie. Deze keer verzorgd door Christian Christiansen, Program Vice President security products and services van IDC. De titel van zijn presentatie: “Mainframe security: enterprise crisis?” Een van de ontwikkelingen die door IDC als zeer significant wordt gezien is de verdergaande virtualisatie, met name in relatie tot inzet van (nieuwe) technologieën als cloud computing. Om de mainframers onder de lezers van mijn blog een een beetje gerust te stellen: virtualisatie als in het concept van lpars, logische partities draaiend op een stuk hardware, het operating system VM (Virtual Machines) bestond allang voordat VMWare beschikbaar kwam. Wat dat betreft is er niets nieuws onder de zon, het wordt alleen met veel bombarie als iets nieuws gebracht… Het punt waar we nu wel mee zitten is dat nieuwe technologieën en toepassingen als bijvoorbeeld VoIP, PDA connectiviteit, SaaS niet goed functioneren in een gedistribueerde omgeving. Zijn boodschap komt erop neer dat er een tendens is, en die door zal zetten, naar een hernieuwde vorm van centralisatie. Hij stuurt me zijn presentatie toe zodat we die via onze site openbaar mogen maken.
Ik sprak hem na afloop, waarbij we nog een half uurtje zijn doorgegaan over cloud computing en de betekenis hiervan voor de huidige, traditionele, manier van werken.

Na de key note heb ik als eerste sessie eentje gevolgd over toepassing van cryptografie op systeem Z (zeg maar IBM mainframe). In deze sessie werd toegelicht welke vormen van crypto ingezet kan worden met welke encryptie algoritmen. Naast het gebruikelijke DES en T-DES is toepassing van AES mogelijk, ook in combinaie met Kerberos. Een mainframe kan digitale certificaten aanmaken en beheren en zelfs als certificate authority optreden. Hierdoor kunnen PKI-toepassingen op het mainframe draaien, of vanaf een mainframe geïnitieerd worden. Een enorm technische sessie die behoorlijk eisen stelde aan je wiskundige inzichten!

Deze sessie werd gevolgd door een dubbele (!) sessie over Websphere Application Server security. Dit is eigenlijk een transactie server die gebruik maakt van Java en de J2EE standaard volledig ondersteunt. Met WAS worden drie soorten applicaties ondersteund: web applicaties, EJB applicaties (dit zijn enterprise java beans) en java objects. Het aardige is dat WAS als een frontend voor de traditionele applicaties draait. Hiermee ben je in staat om via een webinterface de traditionele applicaties te ontsluiten. Qua security instellingen, settings en mogelijkheden was dit een bijzonder technische sessie. Zo uitgebreid dat er zelfs een dubbele sessie voor nodig was.

Na de double heb ik de “must attend” sessie gevolgd: de RACF update. Hier werd ingegaan op alle vernieuwingen en uitbreidingen die het RACF development team heeft aangebracht in RACF voor z/OS 1.8 en 1.9 gevolgd door een aankondiging van vernieuwingen in z/OS 1.10. Zo is het mogelijk geworden om, behalve in WAS, ook in DB2 op basis van role based autorisaties toe te kennen. Waar het in WAS gaat om EJB-roles, gaat het in DB2 om SQLroles. Het is daarnaast ook mogelijk geworden om t.b.v. digitale certificaten met virtual key rings te werken. Een nieuwtje is dat passphrases nu vanaf 9 tot 100 karakters in lengte kunnen zijn; dat was hiervoor van 14 tot honderd karakters. De reeks tussen 9 en 13 is in eerste instantie overgeslagen. Er zijn nog een aantal vernieuwingen doorgevoerd, maar ik ben bang dat dit te technisch gaat worden voor dit verslag. Laten we afspreken dat ik de gehele lijst op verzoek zal toezenden.

De laatste sessie van de dag begon om half 6 en duurde maar liefst 3 uur en ging over het hacken van een mainframe. Onnodig te zeggen dat ook dit een uiterst technische sessie was; technischer nog dan de RACF update Het slechte nieuws: ook een mainframe kan hacked worden. Boeiend, heel boeiend. Hoewel ik een aantal dingen al wist, zaten er voor mij toch ook een aantal eye openers in, per slot van rekening ben ik hier om te leren.
Maar goed dat er voor de deelnemers aan deze sessie voor pizza & frisdrank werd gezorgd!

Na van ’s ochtends 9 tot ’s avonds 9 bezig te zijn geweest ben ik nu toch echt wel een een biertje toe!!

John Rudolph

Vanguard Security Conference 2009 - Vooruitblik

2009-05-22T21:46:00.001+02:00

Na vorig jaar de conferentie bezocht te hebben in Los Angeles ga ik dit jaar ongepland weer. Onze afspraak binnen Information Risk Control is dat alle collega’s een keer per jaar een buitenlandse conferentie kunnen bezoeken. De reden dat ik dit jaar weer ga is dat ik door Vanguard als spreker ben gevraagd.

Dit jaar vindt de conferentie plaats in Jacksonville in Florida.

Ook de Vanguard conferentie heeft last van de huidige economische omstandigheden. Voeg daarbij nog eens de Mexicaanse griep waardoor een aantal (grote) bedrijven een reisverbod hebben uitgevaardigd voor hun medewerkers. Van de oorspronkelijk geplande acht tracks is men teruggegaan naar vijf tracks. Vier van de vijf zijn gereserveerd voor die sessies waarvoor de meeste voorinschrijven waren en de vijfde is gereserveerd voor Vanguard zelf… dat wordt een technische track over de werking van hun tooling in samenwerking met z/OS en RACF.

Mijn sessie vindt plaats op woensdag 3 juni, in het midden van de conferentie, en heeft als titel “RBAC Maturity Model using CobiT and ISO 27002 controls”. In feite bespreek ik het IAM³ model en wel verbijzonderd naar Role Based Access Control als access control component.

Het IAM³ model is mede ontwikkeld om de processen op het gebied van Identity and Access Management te kunnen meten en sturen om daarmee in lijn te komen met het door de organisatie gewenste functioneringsniveau. Indien u meer wilt weten over dit model wil ik u vragen contact met ons op te nemen voor een nadere uitleg en toelichting van dit model.

Het feit dat men mijn sessie heeft opgenomen in het gereduceerde curriculum geeft volgens mij aan dat men, niet alleen in Nederland, maar ook in de USA nog steeds worstelt met het in control komen (en blijven!) betreffende autorisatiebeheer in de diverse aspecten. Laten we nou gewoon eerlijk toegeven dat autorisatiebeheer een moeilijk vak blijft. Enerzijds zijn de autorisatieaanvragen vaak gewoon onduidelijk of worden door niet daartoe gemachtigde functionarissen gedaan. Weiger dan maar eens om een dergelijke aanvraag uit te voeren. Ik heb meer dan eens meegemaakt dat de aanvragers zich behoorlijk intimiderend kunnen opstellen. Anderzijds wordt er van autorisatiebeheer een niet realistische inhoudelijke kennis op applicatief- of syseemniveau verondersteld.

Evenals vorig jaar zal ik in mijn blog dagelijks verslag doen over de door mij gevolgde sessies. Een aantal daarvan zullen weer technisch van aard zijn op het gebied van netwerken, z/OS mainframe en RACF. Een aantal andere sessies zullen op het gebied van governance, auditing & risk management liggen. Wat ik heb gezien van de agenda, de door mij uitgekozen te volgen sessies en natuurlijk mijn eigen sessie, belooft het ondanks slecht economisch weer en de Mexicaanse griep een bijzonder boeiende conferentie te worden.

Houd vooral mijn blog in de gaten om op de hoogte te blijven en aarzel vooral niet om te reageren!

Tot vanaf de Vanguard in Jacksonville!

John Rudolph

Vanguard Security Conference - dag 4

2008-06-06T04:08:00.003+02:00

Donderdag 5 juni
Deze dag borduurt eigenlijk wel voort op die van gisteren. Met andere woorden: de sessies die ik vandaag heb gevolgd, horen logisch gezien bij die van gisteren over rootkits en malware.

Vandaag was de afsluitende dag van de conferentie met alleen twee ochtend sessies. Bij het ontbijt had Vanguard nog een verloting (een “raffle” noemen ze dat hier) georganiseerd en natuurlijk hoorde ik niet bij de prijswinnaars. Om met B100 te spreken: ik heb ook altijd pech!
Incident response and network forensics
Deze sessie is bedoeld om (IT) security professionals te helpen vaak gemaakte fouten bij incident response te voorkomen en ervoor te zorgen dat eventueel bewijsmateriaal zodanig bewaard wordt dat fornsisch onderzoek mogelijk is. Deze sessie was wel heel erg gericht op Amerikaanse wetgeving en rechtspraak…
De sessie werd gegeven door Dr. Michael Staggs, met een militaire achtergond bij de US luchtmacht. Hij heeft doctoraals aan de universiteiten van Arizona, Pima, Florida Keyes, Phoeniz en St Leo’s University.

Dr. Staggs gaf de volgende definitie van en incident: “an incident can be thought of as a violation or eminent treat of violation of computer policies, acceptable use policies, or standard security practice.”
Mee eens?

Ja, eigenlijk wel.

In het incident process is het eerste problem al: identificeer een incident als zijnde een security incident. Daar gaat het vaak al helemaal mis.
Als een incident eenmaal als zodanig is geclassificeerd, komt de volgende fase: volg je de standaard geïmplementeerde incident procedures of moet je forensisch onderzoek (laten!) doen?

Opmerking: zorg er wel voor dat je voorbereid bent op het optreden van incidenten. De vraag is niet OF je ge-hacked wordt. De vraag is WANNEER!

Met andere worden: er moet een security incident afhandelingsprocedure bestaand. Het liefst met een incident management handboek, waar de juiste stappen in de juiste volgorde staan beschreven. En, o ja, het moet natuurljk up-to-date zijn en worden gehouden!

De meest voorkomende tekortkomingen bij security incidenten zijn eigenljk wel:
- er is onvoldoende aandacht voor security, functionaliteit gaat vóór
- er wordt geen gebruik gemaakt van netwerk- of host IDSsen
- FW of (of AV) messages worden niet bekeken,
- onvoldoende onderhoud op FW access control lists
- logs worden niet bekeken, worden niet bewaard
- meldingen van gebruikers (uhh.. mijn pc is opeens zo traag geworden) worden niet serieus genomen
- er is onvoldoende organisatie
- en, voor de Amerikanen onder ons, tegenwerking van de autoriteiten wanneer ze met een huiszoekingsbevel komen binnenvallen.

Forensich onderzoek is een stap verder. Iedereen (bijna iedereen) kijkt wel eens naar CSI. Voordeel van deze serie is dat men zich meer bewust is geworden van het belang van goed forensisch onderzoek wil het bewijsmateriaal door een rechtbank geaccepteerd worden (nadeel van deze serie is dat veel mensen denken een boel van forensisch onderzoek af te weten).

Forensisch onderzoek kent ruweg 3 aspecten:
- verzamelen en interpreteren van (bewijs)materiaal
- volgen van de chain-of-custody. M.a.w. het moet altijd herleidbaar zijn wie onder welke omstandigheden wat heeft gedaan met het (bewijs)materiaal
- het presenteren van de conclusies (vaak voor een rechtbank)

Bij het verzamelen en analyseren van (bewijs)materiaal is het belangrijk dat er altijd aangetoond kan worden dat niet met het bronmateriaal is kunnen knoeien. Denk hierbij aan het gebruik van de “2 person rule” (getuige), gebruik logboeken, beveiligde opslag van het mateeriaal in een lab-omgeving en natuurlijk: gebruik nooit het origineel voor analyse!

Een andere praktische tip: zorg van rapportage templates, zodat je incident rapportage consistent is. Misschien moet je zelfs verschillende templates hebben voor de verschillende doelgroepen als HR, juridische zaken, management etc. Denk hier maar eens over na…

De presentatie ging verder nog in op het gebruik van bijvoorbeeld hashes van binary files – om later na te kunnen gaan of deze files zijn gewijzigd (of niet) en gaf een aantal praktische tips. Nogmaals, vooral gericht op de Amerikaanse weten en rechtspraak/

Wel een aantal aardige leeswerkjes:
- Emergency guidelines:
http://www.forensics-intl.com/guidelns.html
- Seizure and examination guidelines
http://www.crazytrain.com/seizure.html
- Detailed analysis and tools
http://www.garykessler.net/library/computer_forensics_books.html
Incident response challenges in a dynamic threat environment
Deze sessie gaat over het verkrijgen van awareness over de typen aanvallen die tegenwoordig het meest voorkomen, het verkrijgen van een begrip over de technische aspecten daarvan en over de uitdagingen waar je voor gesteld wordt bij een response op die aanvallen.

De sessie is gegeven door Jeanie Larson CISSP-ISSMP CISM. Zij is programma manager van de chief Information Officer Incident Divvision van het Department of Engergy.

In één zin samengevat zijn de trends in cyber-dreigingen en economische spionage meer complex en verfijnd geworden. Traditionele beveiligingsmaatregelen verliezen effectiviteit en een goed ingericht incident response mechanisme is cruciaal om de “information assets” te beschermen.

Volgens de Amerikaanse federale overheid zijn de top-drie landen die zich met electronische spionage en hacking bezighouden (vaak door kleine onafhankelijke groepjes hackers, maar wel betaald door vreemde mogendheden) in deze volgorde: 1-China, 2-Rusland en 3-India. De Amerikaanse heeft een geheime (in hun termen classified) presidentieel decreet vervaardigd om alle overheidsgegevens afdoende te beschermen. Dit heeft tot het gevolg dat instanties als FBI en NSA zich hier actief mee bezighouden. Het classificatieniveau van dit decreet is inmiddels naar beneden bijgesteld, zodat ook bedrijven in de private sector als het ware kunnen meeliften op de overheidsmaatregelen.

De meest voorkomende oogmerken van aanvallers zijn crimineel van aard – met de bedoeling om veel geld te verdienen of houden zich bezig met economische en industriële spionage.

Het aardigste onderdeel van deze sessie was de benoeming van een lifecycle bij het doen van incident rsponse en forensics. Als je goed kijkt herken je de PDCA-cirkel hierin weer terug. Ik zal ‘m niet verder uitdiepen per onderscheiden fase in de cyclus, maar de cyclus wel als zodanig weergeven.
Denk er eens over na. Ik hoor graag als je er iets meer van zou willen weten.

Een aantal adviezen om bedreigingen zoveel mogelijk tegen te gaan zijn:
- identificeer de belangrijkste “assets” en voer er risico analyses op uit;
- classificeer de “assets”, definieer beveiligingseisen en pas deze dan ook toe;
- maak eindgebruikers bewust van dreigingen als phishing etc. en neem incidentmeldings procedures op;
- zorg voor een goed uitgerust incident response team, inclusief organisatie;
- Voor Amerikanen: “establish relationship with FBI Counterintelligence Domain Program”.

Een aantal technische adviezen:
- gebruik zoveel mogelijk een two-factor authenticatie;
- pas zoveel mogelijk encryptie toe bij het versturen van informatie en gegevens (ook voor belangrijke data dat binnen de organisatie blijft);
- zorg voor periodieke web applicatie testen (!);
- beoordeel je architectuur nogmaals (b.v. zorg voor full pcap als dat mogelijk is) ;
- zorg voor web proxies;
- en last but not least: houd de applicaties en inrastructuur op het hoogste patchlevel!

Tot slot nog een aantal bijzonder nuttige URL’s met meer (en meer en meer) informatie:
- Antiphishing working Group
http://www.antiphishing.org/index.html
- Email Sender Policy Framework
http://www.openspf.org/
- Information Asset Protection Guide
http://www.asisonline.org/guidelines/guidelinesinfoassetsfinal.pdf
- FBI Infragard
http://www.infragard.net/

Einde conferentie!
Dit waren mijn bijdragen vanaf de Vanguard Security Conference in Los Angeles. Volgend jaar wordt de conferentie georganiseerd in Jacksonville, Florida.

Ik hoop dat het leesbaar en informatief was. Mocht iemand nog meer willen weten over een (of meer) van de door mij gevolgde sessies: je weet me te vinden!

Ik heb, om nu echt af te ronden, nog een paar bijzonder aardige uitspraken van mede conferentiegangers kunnen opschrijven, die ik jullie allemaal niet wil onthouden. En bij een aantal heb ik het niet helemaal droog kunnen houden!

“Hi, I’m from the Netherlands.”
“Right, are you a democracy?”
“Ow, do you guys have an army?”
“Well, you must be Danish then.”
“That’s very close to Russia, right?”
“Never been there, but I’m told everybody smokes pot.”

“Actually the Netherlands is the same as Holland.”
“So tell me why they call you Dutch then?”
“So how many capitals do you have?”

“Hi, I’m from Holland.”
“Let me guess, Michigan?”

Vanguard Security Conference - dag 3

2008-06-05T05:48:00.003+02:00

Woensdag 4 juni

Mijn blog van gisteren ben ik begonnen met een stukje over de grondleggers van z/OS mainframe security zoals we dat nu kennen: Eldon Worley en Barry Schräger. Ik noemde ook mijn andere held: Walt Farrell.

Bijgaande foto wil ik jullie niet onthouden; ik ben er bijzonder trots op! Walt (links) en ik samen op de Vanguard Security Conference 2008 in Los Angeles.

In mijn huidige project ben ik bezig om een technische implementatie te maken van RBAC op een groot aantal z/OS mainframe systemen bij één van onze klanten. Ik praat hier over een constellatie (sommigen noemen het een “server-farm”, maar die hebben het dus echt niet begrepen!) van 19 individuele mainframes en een userpopulatie van rond de 40 tot 50.000 users. Omdat dit met de hand natuurlijk niet te doen is, niet alleen vanwege de aantallen ,maar zeker ook vanwege lokale (per systeem verschillende) standaarden in user conventies, toekenning van autorisaties, applicaties die zich verschillend gedragen, verschillende typen van applicaties met elk weer andere functionaliteiten, verschillende security management afdelingen, procedures en ga zo maar door heb ik een eigen RBAC implementatietool ontworpen. Het gaat te ver, zeker voor deze blog, om te beschrijven wat het allemaal doet (en hoe), maar ik heb Walt de naam die ik eraan heb gegeven verteld. We hebben er samen vreselijk smakelijk om moeten lachen. En daar ging het om! De RBAC implementatietool heb ik gedoopt: Rapid Acces Conversion Framework. Als acronym is dit. ……….. RACF.

Vandaag is, qua gevolgde sessies, voor mij de meest technische dag van de conferentie. Niet alleen op het gebied van mainframes, maar zeker ook op het gebied van malware en vooral rootkits. Nu ik dit allemaal op zit te schrijven kan ik wel vertellen dat ik vre-se-lijk last heb van een information overload. Ik ben bijzonder onder de indruk van de kennis, en zeker ook van de manier van presenteren, van de sprekers van vandaag. Deze dag kan ik in één woord samenvatten: topdag!

Security for WebSphere MQ on z/OS using RACF

WebSphere MQ is niet de enige, maar wel één van de meest populaire middleware toepassingen voor het verzenden en ontvangen van berichten. Niet alleen op z/OS, maar zeker ook op andere platformen. Inmiddels ondersteunt WebSphere MQ meer dan 35 verschillende platformen.

Deze presentatie gaat vooral in op de Websphere implementatie op z/OS, maar de architectuur (uitgezonderd de beveiligingsmechanismen) is gelijk op alle platformen.

Wat WebSphere MQ is, is het makkelijkst uit te leggen aan de hand van een voorbeeld: vergelijk het met TNT post (of een andere postverwerker als Selectmail enzo). Je stopt je envelop met je brief in de brievenbus van het postkantoor bij je in de buurt en enige tijd later wordt de brief bij de ontvanger bezorgd. MQ heeft de postverzorgingsfunctie: het leegt de brievenbus, sorteert de berichten op bepaalde kenmerken (denk aan postcode en vervolgens specifieke adressering), verstuurt de berichten naar het postkantoor bij de ontvanger in de buurt en levert het vervolgens af. Om zeker te zijn van een juiste aflevering kun je de bezorging vergelijken met het versturen van aangetekende post.

Als je het zo bekijkt niet al te moeilijk, toch?

Enkele karakteristieken van MQ zijn:

- op elk platform heeft het eenzelfde interface;

- communicatie geschiedt asychroon en tijdonafhankelijk tussen applicaties. De ontvangende applicatie hoeft dus ook niet gelijktijdig met de verzendende applicatie actief te zijn;

- het is een message-to-message protocol, dat met de huidige releases meer en meer gebruik maakt van XML

Ik zal proberen om de sessie in zo algemeen mogelijke bewoordingen te bespreken en niet in te gaan op de specifieke z/OS beveiligingsaspecten, omdat die te technisch-specifiek zijn voor mijn achtenswaardige lezerspubliek. Met algemeen bedoel ik architectuur die voor alle ondersteunde platformen gelijk(waardig) is.

De Websphere MQ basisarchitectuur ziet er volgens onderstaand schema uit:

Vanuit security perspectief zijn er een aantal objecttypen van belang:

- Queues

Queues bestaan uit application queues en system queues. Bij system queues wil ik even de “Dead-letter queue” noemen. Hierin worden onbestelbare berichten in opgeslagen. Dit is om te voorkomen dat een ontvangende queue een dergelijk bericht blijft proberen te bezorgen en daarmee het verkeer voor andere berichten blokkeert. Belangrijk is dan wie er toegang tot deze queue heeft. Immers: de vertrouwelijkheid van deze niet bestelbare berichten moet worden gewaarborgd!

- Queue managers

- Channels, waarbij de transportchannel het verkeer tussen queue managers onderling en tussen queue managers en clients verzorgt.

- Namelists die de namen van andere queues bevat.

- Process definitions ten behoeve van applicaties en

- Topics. Dit is een nieuw objecttype met ingang van WebSphere MQ versie 7.

Topics is wel een aardige: hiermee wordt, zeg maar, forum-achtige toepassingen ondersteund. Denk hierbij aan bijvoorbeeld iets van Yahoo!Groups o.i.d. Je kunt er ook zaken als koersinformatie mee beschikbaar maken als dat relevant is voor je organisatie.

Afsluitend over dit onderwerp heb ik nog de volgende wetenswaardigheden:

MQ Series versie 5.3.0. is inmiddels out-of-support;

MQ Series versie 5.3.1. gaat binnenkort out-of-support;

Met ingang van versie 6 is de naam gewijzigd naar WebSphere MQ. Dit is de meest courante versie;

Websphere MQ versie 7 is in april 2008 aangekondigd en zal zomer 2008 beschikbaar komen.

Voor vragen over de z/OS specifieke security configuratie van Websphere MQ kan ik natuurlijk altijd, als ik weer terug ben in Nederland, benaderd worden. Ik zal met plezier een toelichting komen geven.

Lessons learned in malware defense

Deze sessie gaat in op de ontwikkelingen van malware, de toenemende bedreigingen en impact. Niet alleen vanwege de ontwikkelingen op het sociale en technologische vlak, maar ook op de manieren waarop maatregelen tegen nieuwe vormen van malware kunnen worden genomen. De sessie is gegeven door Dr. Richard Ford (PhD, professor bij het Florida Institute of Technology en en Director van het Center for Security Science in Florida).

Anekdote vooraf van Richard Ford (nou ja, anekdote?) Hij is in toenemende mate slachtoffer van spear phishing attacks die specifiek tegen hem zijn gericht, waarbij zelfs bij één gelegenheid zijn computer met succes in geïnfecteerd met een rootkit…

Het probleem van malware is groter dan het ooit is geweest en wordt alleen maar erger (Richard Ford). Groot deel van het probleem is dat de bestrijdingsmiddelen nog steeds zijn gebaseerd op technologieën en oplossingen van de jaren 80!

Was de eerste golf van malware gericht op vernietiging van data en de tweede golf gericht op het modificeren van data, de derde en huidige golf is gericht op diefstal van data. Als voorbeeld werden genoemd: identity theft, illegal access door het “stelen” van tokens, usernames en passwords en vooral diefstal van creditcard gegevens.

Er is een duidelijke waarneembare trend naar financiële motieven bij de aanvallers. Malware is big business geworden, waar miljoenen en miljoenen in omgaan.

Virussen zijn het probleem niet meer; AV-scanners zijn voldoende uitgerust om virussen tegen te houden. Hetzelfde geldt voor Worms. Het probleem zijn vooral de Trojans. Een van de redenen is dat een Trojan ook als Trojan herkend moet worden. Daarbij maken Trojans vaak gebruik van “packing” technieken. Packing is een techniek waarbij uitvoerbare code zodanig wordt “ingepakt” dat reverse engineering niet meer mogelijk is. Veel software leveranciers werken op deze manier om te voorkomen dat hun code wordt gekraakt. Een bekend voorbeeld: Microsoft laat de code van het Vista operating system door een packer heengaan en geeft de broncode niet vrij. Trojans maken dankbaar gebruik van dezelfde technieken.

Omdat je aan packed code niet meer kunt zien of het om legitieme code, of om een Trojan gaat, wil Ford de discussie wel aan om bijvoorbeeld alle packed software, die in een organisatie in omloop is, op een blacklist te zetten. Ik noem nu wel Microsoft, maar unix-, linuxvarianten en Mac OS zijn ook niet veilig…

De maatregelen die je kunt nemen zijn niet nieuw. Waar het om gaat is dat je het elke keer juist moet doen en dat er gemeten moet worden hoe goed de maatregelen worden uitgevoerd. Klinkt bekend, toch?

De belangrijkste typen maatregelen zijn:

- maak backups (niet nieuw)

maak de juiste backups met de juiste regelmaat op het juiste tijdstip;

verifieer of de backups goed zijn; test de backups

- patch!

verifieer dat alles het laatste patchlevel heeft;

verificeer dat alles het laatste patchlevel heeft

- Zorg voor je perimeter defense

spamfilters, virusscanning bij de gateway;

verifieer of de firewall rules nog wel in orde zijn

- Zorg voor je host-based defense

zorg voor een standaardniveau in desktop en laptop bescherming

- Bescherm de servers

weet wat je aan machinepark hebt staan

- Laat de IDS vooral ook outbound verkeer controleren

De belangrijkste conclusies van deze presentatie waren:

- het malware probleem gaat nog veel en veel groter worden

- nemen van maatregelen is niet opwindend of sexy, het gaat om consistentie

- als niet regelmatig de voortgang en kwaliteit van je maatregelen meet, zul je gegarandeerd falen.

Rootkits: the ultimate malware threat

Deze sessie is eigenlijk ene logisch vervolg op de vorige, maar ging specifiek in op rootkits. Wat zijn rootkits (en wat niet), hoe kun je voorkomen dat rootkits geïnstalleerd worden, hoe ontdek je ze en hoe kom je er weer van af?

De sessie werd gegeen door Dr. Eugene Schultz, PhD CISSP CISSM, CTO en CISO van Hightower Software.

Deze sessie ging voor mij eigenlijk te diep; ik had behoorlijk moeite om en het niveau en het tempo van de spreker bij te houden. Na afloop van de sessie was ik echt afgemat…

Rootkits zijn de ultieme vorm van malware, maar worden in de hypes over virussen en worms maar al te vaak over het hoofd gezien. Aardige stelling, toch?

Een rootkit is een een Trojan die het operating system zodanig wijzigt dat het de sporen van een aanvaller actief uitwist en vaak een op een backdoor-achtige manier het systeem openzet.

Kernmerken zijn dat rootkits vrijwel altijd met maximum privileges draaien in de kernel (ring 0) van het OS, dat ze geen kwetsbaarheden uitbuiten en dat ze persistent of niet-persistent kunnen zijn (persistent is memory resident).

Een rootkit wijzigt data structuren; onderschept system calls, vangt interrupt calls af waardoor ze system privileged instructies kunnen uitvoeren en wijzigt kernel memory waardoor instructies naar de rootkit code verwijzen.

Er werd een aardige analogie gegeven van de plaats in een aanval van een rootkit. Vroeger werden kolonisten door indianen opgejaagd en als ze gevangen werden, werden ze gescalpeerd. Een rootkit is als het scalperen van een geïnfecteerde pc.

Er zijn twee typen van rootkits te onderscheiden: user-mode rootkits en kernel-mode rootkits. Van beide typen is de laatste het meest gevaarlijk.

Een van de laatste ontwikkelingen is dat rootkits steeds populairder worden in VM (virtual memory) omgevingen als bijvoorbeeld VM Ware.

Een aantal van de nu in omloop zijnde rootkits zijn FU (en varianten), Shadow Walker, NaviPromo en Suckit (laatste speciaal tegen Linux varianten).

Een rootkit kun je op verschillende manieren “oplopen”. Door het aanbrengen van patches (ja ja), downloaden van freeware, door aanlevering van software door (bona fide?) leveranciers. Van dit laatste een voorbeeld: Sony BMG heeft een rootkit (DRM-0enforcement rootkit) uitgebracht om te voorkomen dat DVDs en CDs illegaal gekopieerd worden. Verder kun je ze oplopen door spyware, bezoek aan “malicious” websites en via virussen en worms, hoewel dit laatste makkelijk detecteerbaar is.

Het detecteren van rootkits kan op verschillende niveau’s en met verschillende tools:

- signature based detection

tools als chkrootkit (linux)

- behavior detection

tools als VICE, Patchfinder

- cross view-based detection

tools als Rotkit revealer, klister, Blacklight, JMER

- integrity-based detection

tools als Tripwire (unix), system virginity Verifier

- hardware-based detection

tools als Copilot

- event correlation

tools als High Tower, Cisco, ArcSight

- handmatige inspectie en analyse

Vervolgens werd nog ingegaan op het detecteren van rootkists via Tripwire, compleet met hexadecimale omrekening van poortnummers etc. Zal ik hier maar niet neerzetten J

De belangrijkste conclusies waren:

- rootkits komen vaker voor dan je denkt (en lief is)

- er zijn geen “silver bullets”, zoals de Amerikanen dat zo mooi kunnen zeggen, het beste is zorgen voor adequate maatregelen

- incident response is van het grootste belang

- voorkomen is beter dan genezen.

Ten slotte nog een advies: tref je een door een rootkit geïnfecteerd systeem aan, moet je dat systeem compleet vanaf scratch heropbouwen en zorg ervoor dat je backups schoon zijn!

Dan wordt het nu zo langzamerhand tijd voor een shrimp skewer, ijskoud biertje erbij en ik kijk verder wel wat voor side dishes ik erbij zal nemen! En daarna toch nog even bijkomen van vandaag.

John Rudolph

Vanguard Security Conference - dag 2

2008-06-04T06:42:00.002+02:00

Dinsdag 3 juni

Vandaag stond de dag in het teken van mobile security, compliance en incident response. Maar het absolute hoogtepunt van de dag, en ik denk zelfs van de hele conferentie, was een ontmoeting met Eldon Worley en Barry Schräger. Voor de gemiddelde medemens onbekende namen, maar voor mij twee van de grootste security-helden . Barry is de bedenker, ontwerper en eerste ontwikkelaar van ACF2; Eldon de bedenker, ontwerper en eerste ontwikkelaar van RACF.

A trip down memory lane

Voor diegenen die niet weten wat ACF2 en RACF zijn: het zijn twee van de meest gebruikte security databases in z/OS mainframe-land. In totaal kun je voor z/OS mainframes drie security producten krijgen: deze twee en TopSecret. De laatste heeft een marktaandeel van ongeveer 10 %; de overige 90 zijn ongeveer gelijkelijk verdeeld tussen ACF2 en RACF. RACF is van IBM, de andere twee van CA (Computer Associates).

Beide “tools” zijn min of meer gelijktijdig conceptueel ontstaan toen op een Share conferentie in Montreal in 1972 een probleem werd gemeld: er was per ongeluk een bestand verwijderd door een student op een universiteit en dat bestand kon niet worden recovered. Die student had helemaal niet aan dat bestand mogen komen!

Barry had een eerste prototype van zijn oplossing in 1974 gereed, maar kon geen klant vinden om het commercieel te maken. In 1977 werd CA klant en kocht het product. Alle productontwikkeling ging onafhankelijk van de ontwikkelingen met RACF, maar volgde wel de technische ontwikkelingen van de IBM mainframes op de voet.

Eldon werkte voor IBM research en kreeg medio 1970 wat code om “iets” aan security te doen. Dit is blijven liggen tot na de Share in Montreal, die de ontwikkeling triggerde. In 1972 startte het project RAC (Resource Access Control); in het begin een papieren tijger, die niet werkte. De naam RAC werd intern binnen IBM verbasterd tot RACF: RAC with a graded B Flat (researchers humor…)

In 1974 en 1975 werkte Eldon voor IBM in Engeland en stond de ontwikkeling van RAC(F) min of meer stil.

Walt Farrell (mijn andere held) werd aan het project toegevoegd en op 26 september 1976 zag RACF versie 1.0 het levenslicht.

Vanaf RACF versie 1.4 werden password rules en validatie toegevoegd; echt op z’n research methode. De functies zijn door Eldon bedacht, gecodeerd, uitgetest (hij test accepteerde dus zijn eigen code) en in productie genomen. Hoezo formeel acceptatieproces J

Vanwege performanceproblemen (als RACF actief was liep de hele systeemperformance drastisch terug) is vervolgens een “fastpath” functionaliteit ingebouwd; tegenwoordig bekend als de Global Access Table.

Ik had het al even over Walt. Ten tijde van versie 1.4 werkte Walt nog voor een klant van IBM. Die klant had RACF, maar liep tegen technische problemen aan. Walt vond de problemen in de code, belde met IBM, zo van daar-en-daar hebben jullie een probleem en dit is de oplossing. Vervolgens stuurde IBM nog meer geconstateerde problemen met RACF naar Walt om ze op te lossen. Later is Walt in dienst van IBM gekomen. Vanaf zijn indiensttreding tot nu heeft hij altijd aan de verdere ontwikkeling van RACF gewerkt.

In 1992 is Eldon Worley met pensioen gegaan.

Penetration testing of mobile devices

Deze sessie gaat over de noodzaak van penetratietesten op mobile devices, de risico’s die makkelijk over het hoofd kunnen worden gezien wanneer er geen penetratietesten plaatsvinden en hoe een penetratietest uitgevoerd zou moeten worden met de focus op het testen van iPhones, PDA’s en MP3 spelers.

Deze presentatie was op zich redelijk saai; de spreker las de slides op en voegde daar verder niet al te veel aan toe. Wat wel aardig is, en wat de meeste mensen zich niet realiseren is dat als je een mobile device aansluit op je netwerk -of via een USB-poort- aan je computer, die mobile devices een IP-adres krijgen.

Juist, daar kun je wat mee als hacker zijnde.

In de presentatie kwam een aardige opsomming van pentest tools ter sprake. In de categorie war-walking tools (zeg maar war-driving, maar dan lopend) kwamen de volgende tools aanbod:

Pocket Warrior – http://www.pocketwarrior.org

De tools die hier te vinden zijn, zijn een PDA wifi sniffer, Pocketwarrior, en andere war driving tools

WiFiFoFum – http://www.wififofum.org

Een wifi scanner en war-driving software voor PocketPC 2003, Windows Mobile 5 Pocket PC en Smartphone edities

Ministumbler – http://www.netstumbler.org

Een tool die je kunt gebruiken om war-driving uit te proberen. Zeg maar: for recreational use only.

In de categorie reconnaissance tools, die gebruikt worden om network informatie te vinden, werden besproken:

vxUtil – http://www.cam.com/vxutil.html

Dit kan gebruikt worden om een DNS lookup te doen, finger en ping. Het bevat een subnet calculator en voorziet in password generation. Dit tool draait op een PDA.

vxSniffer – http://www.cam.com/vxsniffer.html

Dit is een compleet netwerk monitoring tool voor Windows CE-devices.

NeoScan – http://www.dotnetux.net

Dit is de snelste portscanner die voor een pocketpc beschikbaar is.

De presentatie ging verder over in een demonstratie over het van buitenaf overnemen van een iPhone (MAC OS platform). Boeiend maar een beetje te technisch om dat allemaal uitgebreid in deze blog te verwoorden.

De belangrijkste conclusie van de sessie was dat het uitvoeren van penetratietesten op mobile devices periodiek; het liefst elke 2 tot 3 maanden, uitgevoerd zou moeten worden. Dan ben je in ieder geval op de hoogte welke devices er (wired of wireless) aan het netwerk zijn toegevoegd zonder dat de geldende organisatieprocedures hiervoor gevolgd zijn.

Making a CICS application SOx compliant

Deze sessie gaat in over het implementeren van role based access control in een CICS omgeving om daarmee te kunnen voldoen aan SOx vereisten.

CICS. Weer zo’n term . CICS staat voor Customer Information Control System en is een on-line transactieverwerkend systeem draaiend op een z/OS mainframe. Zie dit als tegengesteld aan batchgewijze verwerking.

De presentatie ging over de manier waarop autorisaties logisch bijeengegroepeerd werden naar business functie. Vervolgens vindt er een periodieke verantwoordingsrapportage plaats naar business owners (managers) die een sign-off moeten doen op de juistheid van hun medewerkers met een bepaalde rol. Data owners (informatie eigenaren) moeten periodiek een sign-off doen van autorisaties toegekend aan functies. Die functies zijn technisch gerepresenteerd door autorisatiegroepen.

Over het algemeen een vrij basaal verhaal met middelmatige implementatie. Althans, dat vond ik. Voor de aanwezige Amerikaanse personen die deze presentatie bijwoonden zaten er wel een paar eye openers is.

Misschien moeten wij als Information Risk control zijnde ons werkterrein maar eens uitbreiden; over het algemeen is de (technische) kennis over RBAC vrij matig in de USA. Uhh… dit is uitsluitend een persoonlijke visie…

PCI compliance

Deze sessie gaat in op de “minimum standards of due care” die vanuit PCI-compliancy worden opgelegd.

De presentatie werd gegeven door mw. Anne Rogers PMP CISSP CCE – Director Information Safeguards van Waste Management en tevens lid van de international board van ISSA.

Payment Card Industry Data Security Standard (nu: versie 1.1, in de loop van 2008 komt een update). We hebben er allemaal mee te maken, overal ter wereld, ja ook in Nederland. Tenminste, als je credit cards accepteert bij wijze van betaling. Of je nu een restaurant bent, een warenhuis, een dienstverlener. Maakt niet uit: alle bedrijven die credit card betalingen accepteren.

De standaard heeft, heel kort gezegd, als doelstelling het bewaken van privacy gegevens van kaarthouders.

De standaard beschrijft zes verschillende gebieden:

1. Build and maintain a secure network

2. Protect cardholder data

3. Maintain a vulnerability program

4. Implement strong access control mechanisms

5. Regularly monitor and test networks

6. Maintain an information security policy

Er worden zes verschillende niveau’s van organisaties onderscheiden die credit cards als betaling accepteren. Ik zal alleen noemen welk type organisatie op niveau 1, het hoogste niveau, voorkomt en welke eisen de PCI hieraan stelt om een compliancy certificering te krijgen. Overigens is een certificering maar één jaar geldig en moet je elk jaar hercertificeerd worden.

Level 1 merchants zijn:

- merchants met meer dan USD 6.000.000,00 aan Visa en MC transacties per jaar

- elke mechant waarvan Visa of MC bepaalt dat deze aan level 1 moet voldoen

- elke non-compliant merchant die een incident met een creditcard transactie heeft.

Dit laatste kan letterlijk dodelijk zijn voor een kleine(re) organisatie.

De eisen die aan een level 1 PCI validatie worden gesteld zijn:

- er moet jaarljks een PCI data security audit plaatsvinden, uit te voeren door een door de PCI geaccediteerde auditor. Je kunt het ook door de eigen interne auditor laen doen, maar dan moet de hoogste directie tekenen en neemt daarmee persoonlijke aansprakelijkheid. Vergelijk dit met SOx.

- Er moet elk kwartaal een netwerk scan uitgevoerd worden door een door de PCI geaccrediteerde leverancier.

Op de VISA site is overigens een lijst te vinden van PCI compliant card processors en een overzicht van door PCI geaccrediteerde netwerk scan leveranciers.

De boetes die PCI kan opleggen bij het constateren van non-compliance incidenten zijn niet misselijk:

- een boete van USD 100.000,00 per incident voor het niet melden van dit incident

- een boete oplopend tot USD 500.000,00 per geconstateerd incident

- het niet meer toestaan dat creditcard betalingen worden geaccepteerd

Verdere boetes zijn, als uit de compliance status rapporten blijkt dat je niet voldoet aan de PCI standaard:

- een eerste boete van USD 5.000,00 pe3 maand

- na het eerste kwartaal een boete van USD 25.000,00 per maand

- het niet meer toestaan dat creditcard betalingen worden geaccepteerd

Om te zien of een bedrijf/organisatie PCI-compliant is kun je op je kwitantie kijken die je krijgtt als je met creditcard betaalt. Staan op die kwitantie alleen de laatste 4 cijfers van je creditcard, zit je goed (tenminste als je diegene bent die de betaling accepteert). Wordt daarentegen het gehele creditcardnummer afgedrukt heb je een probleem en ben je niet PCI compliant.

Vervolgens werd een toelichting gegeven wat Waste Management heeft moeten doorlopen om PCI compliant te worden. Wate Management is het grootste afvalverwerkend bedrijf van Amerika met een jaaromzet van USD 13 miljard.

Damage control

Damage control is een synoniem voor Incident Response en de sessie gaat in op de verschillende aspecten die hierbij zijn betrokken.

Voordat ik inga op de presentatie eerst een tip: er bestaat een goed boek over incident response. Het heet “Damage Control”, geschreven door Eric Dezenhall. Houd je je bezig met IR, dan is dit boek een must. Dus: massaal kopen! En dan wel lezen natuurlijk!

Aan de hand van een concreet voorbeeld ging de spreker in op een aantal aspecten rond incident response.

Het concrete voorbeeld was de affaire Tylenol. Ik denk dat de meeste niet-Amerikanen hier nog nooit van hebben gehoord, ik hoor in dit geval ook bij de meeste niet-Amerikanen. Tylonol is een vrij verkrijgbaar medicijn dat in capsulevorm wordt (werd) verkocht. In 1982 heeft de een of andere gestoordeling de inhoud van een aantal capsules in de een of andere winkel vervangen door cyanide. Gevolg: 7 doden verspreid over een aantal dagen. Niet elke koper nam er na aankoop gelijk eentje in, vandaar de spreiding in tijd dat de slachtoffers vielen.

Dit voorbeeld is makkelijk te transponeren naar cyber/computer gebaseerde incidenten.

Analyserend zijn er een aantal eigenschappen aan een incident te onderkennen:

- het grote publiek gelooft altijd het slechtste;

men weet niet precies wat er is gebeurt (in dit voorbeeld dacht men dat er een seriemoordenaar aan het werk was).

- media publiceren (tv, internet, krant) meestal niet de juiste informatie;

verkeerde citaten, speculaties.

- er bestaan middelen om de slachtoffers te helpen;

artsen (in dit voorbeeld), schadebeperkende maatregelen.

- niemand wil toegeven dat zij fouten hebben gemaakt.

(In dit voorbeeld ontkende de fabrikant in eerste instantie over cyanide te beschikkend, later moesten ze toegeven dat ze het toch hadden, maar ontkenden ze dat het mogelijk was dat er een fabricagefout was gemaakt).

Nog even over Tylenol: na dit incident is het middel niet meer via capsules, maar in tabletvorm gefabriceerd – die zijn moeilijker te vergiftigen en zijn de flesjes waar capsules inzitten voorzien van een “dop-beveiliging” en een afsluitfolie.

In een incident response zijn een aantal fasen te onderkennen. In een notedop (notendop?):

- WAT???

Je weet niet wat er gebeurt; informatie/gegevens zijn alleen ongestructureerd beschikbaar

- Herkenning

Je realiseert je dat er een incident heeft plaatsgevonden en begint naar een oorzaak te zoeken

- Emergency response

Informatie over het incident wordt verzameld, gedocumenteerd en verzegeld (bewijsvoering)

Opties om te “recoveren” worden geëvalueerd

De incidentbron(nen) worden opgespoord (“closing the holes”)

- Structurele afhandeling

Alternatieve verwerkingen worden gestart

- Rapportage & verantwoording

Er wordt een “root cause” analyse uitgevoerd en eventuele verbeteringen in de procesvoering en/of de aanwezige maatregelen worden doorgevoerd.

Het gebruik van een echt voorbeeld, zoals in dit geval de Tylenol-affaire, heeft de presentatie bijzonder levendig en aansprekend gemaakt.

Ter afsluiting de lessons learned: een paar jaar na deze affaire is de leverancier van Tylenol weer

overgeschakeld naar het fabriceren van capsules.

Waarvan acte.

John Rudolph

Vanguard Security Conference - dag 1

2008-06-03T06:21:00.004+02:00

Maandag 2 juni

Zo, de kop is eraf! Dag 1 van de Vanguard Security Conference zit erop. De dag begon met een keynote sessie, gehouden door Dr. Ron Ross, computer scientist & security researcher van het NIST (Natioal Institute of Standards and Technology). Hij is verantwoordelijk voor NIST special publications over informatiebeveiliging. Zijn presentatie ging over “Information systems under attack”.

Volgens zijn betoog is niet alleen de (Amerkiaanse) overheid maar ook de gehele private sector inmiddels zo afhankelijk geworden van de inzet van ICT-technologieën dat iedereen daar min of meer blindelings op vertrouwt. Dat betekent dat de gebruikte informatiesystemen betrouwbaar moeten zijn en dus adequaat beschermd. Tot zover niets nieuws eigenlijk. Maar… diegenen die verantwoordelijk zijn voor informatiebeveiliging staan in de frontlinie van een cyberwar die momenteel plaatsvindt. Als voorbeelden werden gegeven aanvallen tegen energiecentrales, air traffic control centers op vliegvelden en andere infrastructurele onderdelen van de samenleving. De aanvallers hoeven (in verhouding) niet veel te investeren: er worden laptops gebruikt, tools worden gedownload vanaf het internet.

Uiteindelijk is een risk-based informatiebeveiligingsprogramma op dit moment het beste antwoord op de bedreigingen van buitenaf. Immers, risico’s veranderen, de technologie verandert. Elke organisatie, zij het overheid, financiële instellingen, zorginstellingen, industriële organisaties hebben elk hun eigen risico profiel op basis waarop bepaald zal moeten worden welke beveiligingsmaatregelen noodzakelijk zijn en welke risico’s geaccepteerd zullen worden.

En de informatiebeveiligers staan vooraan met hun verantwoordelijkheid voor het implementeren en onderhouden van de geïmplementeerde maatregelen.

Een tweetal statements om de standpunten van Dr. Ross te onderstrepen:

· Good security measures are multi-faceted.

Dit statement spreekt geheel voor zich.

· Awareness is critical.

Als mensen zich niet bewust zijn van eventuele beveiligingsimplicaties van hun handelen, hebben veel maatregelen weinig zin. Een voorbeeld: een kleine handeling als het klikken op een weblink kan al tot gevolg hebben dat er kwaadaardige code het systeem binnendringt.

Na deze keynote sessie ben ik een aantal sessies gaan volgen waarvan ik hieronder een verslag heb opgenomen.

RACF Update

Deze presentatie bevat de laatste informatie die door IBM, ten tijde van de conferentie, beschikbaar is gesteld over nieuwe functies en mogelijkheden die in RACF en de z/OS Security Server zijn opgenomen.

Dit is een puur RACF-technische sessie en voor mij een van de absolute hoogtepunten van de conferentie. Juist omdat deze sessie zo technisch is op het gebied van z/OS en RACF zal ik alleen de besproken onderwerpen weergeven en er inhoudelijk niet diep op ingaan; ik vermoed dat alleen voor mensen die zich op het gebied van system engineering, system security (en auditing) bezighouden met het z/OS mainframe deze informatie relevant of van belang is.

Wat auditing betreft heeft het me enigszins verbaasd dat ik verder geen auditors bij de toehoorders heb aangetroffen. Is dit tekenend? Ik zal geen oordeel hierover uitspreken, hoewel ik van mening ben dat een auditor over actuele, en voldoende, inhoudelijke kennis moet (kunnen) beschikken over het te onderzoeken object, ongeacht de technische samenstelling van dat object.

DB2 V9

Binnen DB2 is het met ingang van V9 mogelijk om rollen en trusted contexts te definieren. Doordat DB2 deze informatie doorgeeft aan RACF is mogelijk geworden om deze nieuwe autorisatiemechanismen door RACF te laten valideren.

z/OS Healthchecker

De z/OS Healthchecker is een mechanisme waarmee gecontroleerd kan worden of bepaalde kritische systeemcomponenten nog de juiste instellingen hebben. Denk hierbij aan bijvoorbeeld systeem configuraties.

Na afloop van de sessie heb ik gesproken met Mark Nelson, de IBM ontwikkelaar van de Healthchecker, omdat ik wilde weten of het mogelijk was om, naast de door IBM als kritisch gedefinieerde systeemcomponenten, ook zelf componenten toe te voegen om door de Healthchecker te laten controleren. Hoewel dit (nog) niet de bedoeling is, is dit zeer wel mogelijk; en dat met minimale coderingsinspanningen. Zodra ik een z/OS “speeltuin” ter beschikking heb ga ik dit uitproberen volgens de aanwijzingen die ik heb gekregen. Ben benieuwd…..

Virtual key rings

Als een gebruiker meerdere SSL-based client applicaties wil gebruiken, zal hij voor al die applicaties een eigen key pair nodig hebben. Om het beheer en administratie van key pairs te vereenvoudigen is er nu een voorziening waarbij RACF alle certificaten van een gebruiker als een key ring benaderd worden, zonder dat er fysiek een key ring gedefinieerd hoeft te worden.

Password phrases

Het is nu mogelijk om, behalve een password, ook passphrases van 14 tot maximaal 100 karakters te gebruiken. Het probleem is echter dat z/OS applicaties het gebruik van passphrases moeten ondersteunen, en niet alle (IBM) applicaties doen dat al! Op dit moment kan een user over zowel een password als een passphrase beschikken.

PKI Services

Vanaf deze release wordt Multiple Certificate Authority ondersteund: je kunt dus meerdere CA’s op een z/OS hebben.

SCEP (Simple Certificate Enroll Protocol) wordt ondersteund, waardoor ook certificaten van hardware (bijvoorbeeld routers, VPN devices) rechtstreeks voor RACF worden geaccepteerd hetgeen natuurlijk leidt tot een vermindering van beheeractiviteiten.

z/OS Kerberos ondersteunt nu ook het AES encryptie algoritme.

Verder zijn er zijn nog een aantal andere, reeds bestaande functionaliteiten, ge-upgrade en uitgebreid.

New trends in wireless attacks

Het gebruik van wireless netwerken is inmiddels gemeengoed geworden. Hoewel security protocollen en tools meegroeien, doen “wireless attacks” dat ook. Er bestaan een aantal basis technieken om beveiliging van wireless te verbeteren. Een aantal van deze technieken worden vaak aanbevolen, maar hoe effectief zijn de ingezette middelen? Kunnen deze technieken makkelijk doorbroken worden? Welke nieuwe technologieën kunnen de beveiliging wel verbeteren?

De sessie begon met een alleraardigst statement van de spreker: “There are no new trends in wireless attacks. But attackers are more knowledgeable and tools are getting much better. Security still sucks!”

Zo, komt u maar even binnen.

Kennelijk weten wij beveiligers nog steeds niet hoe we de juiste maatregelen kunnen implementeren om aanvallen op wireless (netwerk)componenten effectief te kunnen bestrijden. Dit beeld werd ook bevestigd in de vierde sessie van de dag (door een andere spreker).

De sessie had vier hoofdonderwerpen:

· Een overzicht van RFC 802.11.

· Maatregelen die niet werken.

· Maatregelen die wel werken.

· Effectieve manieren om te beveiligen.

RFC 802.11 is een basis standaard en protocol, waarop verschillende uitbreidingen zijn gekomen:

· 802.11a – een upgrade.

· 802.11b en 802.11g; beiden worden het meest gebruikt.

· 802.11n – gebruikt WPA als standaard encryptie

Er zijn in totaal zo’n 25 tot 30 verschillende standaarden waarvan een aantal ook een protocol zijn.

Er zijn een aantal categorieën van bedreigingen:

· Interceptie van data.

· Diefstal van services.

· Denial of Service.

· Netwerkpenetration via wireless netwerk(segmenten).

Wat niet werkt is het toepassen van MAC filtering. Het is vrij eenvoudig om in de registry een MAC adres van een wireless kaart zelf toe te voegen. Bovendien zou je dan MAC filtering voor elke client aan moeten zetten, hetgeen vrij moeilijk is om te onderhouden.

Wat ook niet werkt is het niet broacasten van het SSID. Immers, client en access point hebben dat nodig om contact te kunnen leggen. Je kunt wel SSID beaconing door de client uitzetten, hetgeen in Vista overigens standaard is ingesteld.

Het CISCO LEAP protocol werkt niet omdat de username met bijbehorende password hash in plain text worden verzonden. Brute force attacks zijn/blijven dus mogelijk. Daarnaast is LEAP uitsluitend afhankelijk van de sterkte van het gekozen password.

DHCP uitzetten werkt niet omdat dit het probleem van interceptie niet oplost. Bovendien kun je natuurlijk zelf ook op een vrij eenvoudige manier IP-adressen toevoegen.

De plaats waar de antenne(s) wordt (worden) opgesteld werkt waarschijnlijk ook niet. Een aanvaller zorgt eenvoudig voor een antenne met groter bereik.

Een suggestie is wel om antennes zodanig te plaatsen dat er een maximaal bereik met minimale interferentie is. En natuurlijk: plaats geen antenne(s) waar je ‘m niet nodig hebt!

WEP encryptie werkt waarschijnlijk ook niet. Het is matig ontworpen en geïmplementeerd. Hoewel, als WEP het enige is dat je hebt, is het beter dan niets…

Voor de jonge onderzoekers is er een aardig tool vrij downloadbaar om de kwaliteit van de WEP-implementatie te beoordelen: WEPCRACK. Om op z’n Amerikaans te waarschuwen: don’t try this at home!

WPA werkt wel, vooropgesteld dat er een goede encryptiesleutel is gekozen. VPNs en tunnels werken ook hoewel dit natuurlijk alleen de inhoud van het verkeer afschermt.

Een aantal suggesties om een wireless netwerk te beveiligen zijn:

· Isoleer het wireless netwerk van de overige netwerken en plaats dit in een DMZ.

· Gebruik een IDS; beschouw een wireless netwerk als alle andere netwerken en gebruik hetzelfde type van maatregelen.

· Voer periodiek war-driving uit op het wireless netwerk om te ontdekken of er “vreemde” clients aanwezig zijn. Doe dit niet alleen voor de access points, maar ook voor de users op dit netwerk die het SSID broadcasten.

· Besluit of het SSID wel of niet iets van de identiteit van de organisatie moet onthullen.

· Gebruik dezelfde authenticatie en encryptie voor alle wireless componenten. Denk hierbij aan zaken als de inzet van RADIUS, EAP, PEAP en TAP-TLS.

Auditing IT controls

Deze presentatie geeft een IT auditor de noodzakelijke informatie om een effectieve audit van IT controls uit te kunnen voeren.

Dit was een vrij basale presentatie over het hoe en waarom van het uitvoeren van een audit. Het enige dat ik echt vermeldenswaard vind is dat er een update op SOX 4.04 is gekomen, waaruit blijkt dat de kwaliteit van password rules een indirecte relatie heeft met de financiële rapportage (te vinden op blz 42). De reden hierachter is dat, als je in staat bent om een password te kraken, je dan in staat bent om frauduleuze handelingen uit te voeren die de financiële rapportage kunnen beïnvloeden. De laatste tekst van SOX 4.04 (A guide for management by internal controls practitioners) is te vinden op de onderstaande URL:

http://www.theiia.org/download.cfm?file=31866

Wireless risk in an enterprise environment

Meer en meer worden WIFI netwerken toegepast aan de binnenkant van de organisatie-eigen security-perimeter. Dat kan verstrekkende gevolgen hebben voor het eigen algemene beveiligingsniveau en infrastructuur.

Deze presentatie gaat in op beveiligingsmaatregelen die inherent zijn aan RFC 802.11 en de wireless architectuur om daartussen een balans te vinden in een operationeel netwerk dat goed is beveiligd.

Deze presentatie sluit aan op de eerdere presennatie die ik over wireless attacks heb gevolgd en gaat iets (nou ja iets: heel wat!) dieper in op de technische implicaties van het gebruik van een wireless netwerk.

De samenvattende conclusie van de spreker is: “Beschouw een wireless netwerk als een tweede internet en neem overeenkomstige beveiligingsmaatregelen”.

Als je wireless netwerken wilt gaan exploiteren zul je goed moeten nadenken. Een eenvoudige en heldere zin, op het eerste gezicht. Ga je hier echter goed over nadenken, komt er nogal wat op je af.

Op de eerste plaats moet er een bepaalde zakelijke noodzaak bestaan voor het gebruik van wireless. Bij het bepalen van een zakelijke noodzaak moeten minimaal de volgende vragen worden beantwoord:

· Is er een balans tussen gewenste functionaliteit en noodzakelijke beveiligingsmaatregelen?

· Wat is het type omgeving waar de access points worden opgesteld (zijn er bijvoorbeeld andere, niet-organisatie eigen) access points in de buurt die een bedreiging zouden kunnen vormen?

· Wat is het type service dat over een wireless netwerk moet en met welk kwaliteitsniveau moet dat worden geleverd?

· Wat zijn de andere organisatie assets die door het gebruik van wireless worden bedreigd?

· Wat zijn de beperkingen ten aanzien van kosten?

· Was is het aanvaardbare risiconiveau als wireless wordt ingezet?

In een wireless omgeving komt authenticatie vaak neer op: “you are who you say you are”. Je zult dus aanvullende maatregelen moeten nemen om zoveel mogelijk zekerheid te krijgen dat alleen de juiste users van een wireless verbinding gebruik kunnen maken.

Aan de access point kant kan aan het volgende gedacht worden:

· Activeer de hoogst mogelijke encryptie die beschikbaar is.

· Maak het SSID niet specifiek, maar algemeen en/of broadcast het niet.

· Filter MAC adressen (helpt waarschijnlijk niet, maar is beter dan niets).

· Probeer het juiste vermogen voor de antenne(s) te vinden; vooral niet teveel zodat het signaal te sterk wordt en eventuele aanvallers gewoon een paar straten verderop gaan zitten.

· Sta onderhoud op een wireless netwerk alleen via een lijnverbinding toe via een aparte netwerkconnectie.

· Probeer, als dat haalbaar is, om toch IP-adressen toe te wijzen.

· Voer zeer periodieke audits van het netwerk uit.

Aan de client-kant zijn de onderstaande maatregelen van belang:

· Sta alleen bedrijfs-eigen computers toe voor wireless gebruik.

· Gebruik voor deze computers alleen hardened images om ze op te bouwen.

· Schakel wireless standaard gewoon uit. Immers: wireless = untrusted!

· Sta niet toe dat users admin privileges krijgen.

· Sta alleen wireless gebruik via een aparte VPN toe.

De presentatie ging verder in op de antennes: welke soorten zijn er en wat zijn kun karakteristieken? Waar moet je allemaal qua fysieke aspecten op letten bij het plaatsen van een antenne? Welke encryptie algoritmen en authenticatie protocollen worden er bij wireless gebruikt, met hun voor- en nadelen? Welke test-software is vrij downloadbaar? Hoe ga je om met incident response t.a.v. wireless?

Ik wil dit verslag afsluiten met twee plaatjes, door de sessie-presentator (Cody Burrows van Imagined Security) gemaakt, die duidelijk maken wat de huidige implementatie van een wireless netwerk is (plaatje-1) en die aangeeft hoe je, vanuit beveiliging gezien, een wireless netwerk in het gehele netwerk zou moeten opnemen.

Zoals uit dit plaatje blijkt worden wireless access points rechtstreeks in het corporate netwerk opgenomen, terwijl toegang via dit netwerk net zo niet-vertrouwd is als internet-toegang.

En wat je eigenlijk zou willen (moeten) is het opnemen van de wireless access points in een DMZ, met aan de voorkant het gebruik van IDS’sen.

John Rudolph

Vooruitblik op de Vanguard Security Conference

2008-05-20T12:56:00.000+02:00

De Vanguard Securtiy Conference heeft van oudsher een sterke affiniteit met technische beveiligingsaspecten op het IBM z/OS platform en dan met name gericht op RACF (Resource Access Control Facility) als onderdeel van de z/OS SecureWay Security Server.

Vanguard Integrity Professionals is een leverancier van security management software, dat zich richt op de gehele onderneming vanuit het hart van de mainframes. Daarnaast biedt Vanguard managed security services, trainingen en natuurlijk DE Security Conference, die in nauwe samenwerking met IBM jaarlijks wordt georganiseerd.

De Vanguard Security Conference wordt dit jaar in Los Angeles, California gehouden.

Dit jaar zijn de verschillende tracks die aangeboden worden divers en afwisselend van aard. Ten aanzien van RACF zijn er tracks die zich richten op security administration, management en technical development.
Behalve mainframe-achtige sessies zijn er ook tracks gewijd aan governance & regulatory compliance, system audit strategies & solutions en networks, threats & solutions.

In totaal worden er ruim 150 individuele sessies georganiseerd tijdens deze conference.

Om de zoveel jaar probeer ik de Vanguard bij te wonen. Enerzijds om bij te blijven op mijn eigen specifieke technische gebied (z/OS mainframe security, dus) en om bij te praten met de mensen van RACF development & level II support. Anderzijds om andere ontwikkelingen op het gebied van informatiebeveiliging, compliancy, audit techniwues en standaarden op de voet te volgen. En ja, natuurlijk ook om contacten te onderhouden.

Dit jaar ga ik uiteraard als eerste naar de RACF Update sessie van Walt Farrel (onthoud die naam!) waar de laatste ontwikkelingen, vernieuwingen en functionaliteiten van RACF worden toegelicht.
Een ander boeiend onderwerp is Webshpere MQ security voor het mainframe platform. Voor mij vooral vanwege de connectivity met ander platformen en via die andere platformen met externe (al dan niet openbare) netwerken en/of partijen.

Verder heb ik een aantal sessies uitgezocht over onderwerpen die mij zeer aanspreken, omdat ik denk dat de besproken onderwerpen behoorlijk actueel en leerzaam zijn. De sessies die ik heb uitgezocht zijn bijzonder gevarieerd. Denk hierbij aan wireless security, onderwerpen als new trends in wireless attacks, penetration testing of mobile devices, wireless risk & risk management. Een andere track die ik ga volgen gaat over controls against malware als bijvoorbeeld rootkits. Andere voor mij interessante onderwerpen zijn compliance & auditing als bijvoorbeeld PCI compliance en SOx audits in CICS environments (ja… weer mainframe). Tot slot wil ik sessies gaan volgen over security incident management, met subonderwerpen als damage control, network forensics en last but not least hoe om te gaan met incident response in dynamische omgevingen, waar risico’s zeer moeilijk in kaart te brengen zijn doordat de omgeving en/of organisatie steeds wijzigt.

Het is een behoorlijk vol programma, met in totaal rond 15 à 16 sessies die ik ga volgen.

Vanaf de Vanguard zal ik in mijn blog dagelijks verslag doen van de door mij gevolgde sessies en daar mijn mening over geven. Veel tijd om (inhoudelijke) vragen te beantwoorden zal ik, vrees ik, niet hebben. Als er vragen voor mij zijn, kom ik daar later wanneer ik weer in Nederland ben, graag op terug.

Ik kijk al behoorlijk uit naar de Vanguard en hoop met een schat aan informatie & kennis terug te komen. Kennis die ik kan gebruiken om onze clientèle nog beter van dienst te kunnen zijn bij vraagstukken op gebieden van informatiebeveiliging, risico management en auditing.

Tot de eerstvolgende blog vanaf de Vanguard!

John Rudolph CISA CISM CISSP