update jan 2015 i T S X DE COLUMN 2 Hans Van de Looy

Your Security is Our Business

23

jan 2015

u p d a t e DE COLUMN

2

HET NIEUWS

3

HET INTERVIEW

4

De hack

7

Hans Van de Looy

• BHS Part XIII 18 juni 2015 • Workshop Hacken met een Teensy • Voorkomen is beter dan genezen

Tim Hemel, CTO bij iComply, over het Framework Secure Software

Daniël Dragi evi bespreekt de cˇ c´ OWASP Top 10 Mobile Risks

de klant

10

het inzicht

14

ITSX

16

HET verslag

18

8 vragen aan Ziekenhuis Tjongerschans

Beveiliging van SAP-systemen

• Arthur Donkers over de ITSX Risico Tool • Ralph Moonen over de HSD Campus • Thorgal Nicasia stelt zich voor

t2 infosec conference 2014 door Walter Belgers

agenda 19 HET COLOFON

i

T

S

X

19

Deze keer Hans Van de Looy, partner en principal security consultant bij Madison Gurkha, aan het woord over het belang van security by design.

de column

Kosten van informatiebeveiliging Waarom is er de steeds groter wordende aandacht voor informatiebeveiliging? De ervaring leert dat het jarenlang best goed kan gaan en in veel gevallen wordt de business geholpen door de wet van de grote getallen. De enige valide reden die ik kan bedenken is dat we er allemaal, dus ook de business, toch van overtuigd zijn dat we - al dan niet ‘geholpen’ door weten regelgeving - als een goed huisvader met de (gevoelige) gegevens van het bedrijf, de instelling en onze klanten of gebruikers om dienen te gaan. We zouden het immers geen van allen leuk vinden als onze gegevens door een foutje op straat komen te liggen of dat een derde partij er misbruik van zou kunnen maken. En toch blijft er iets knagen. Een onbehaaglijk gevoel dat we met ons allen toch net niet voldoende doen om het probleem werkelijk op te lossen. Als ik zo eens terugkijk dan zie ik een nog steeds groeiende lijst van klanten waaraan wij onze diensten verlenen. Een nog steeds groeiende lijst van bedrijven en instellingen die aangeven dat ze informatiebeveiliging belangrijk vinden en daarom hun systemen en diensten, liefst met enige regelmaat, door ons willen laten onderzoeken om te zien of er voldoende aandacht is gegeven aan de beveiliging van de gegevens. Hiervoor wordt een kwetsbaarhedenonderzoek of penetratietest aangevraagd, waarin een team van specialisten gedurende een beperkte tijd (veelal drie tot acht mandagen) de gelegenheid krijgt om een werkend systeem of netwerk zodanig te manipuleren dat toegang wordt verkregen tot meer informatie dan initieel was voorzien door de ontwikkelaars en/of beheerders. Nadat dit team de bevindingen heeft gerapporteerd kunt u weer aan de slag om de aangetoonde kwetsbaarheden te laten repareren. Met andere woorden: veelal direct na de oplevering van een nieuw systeem moeten er structurele gaten en scheuren worden gedicht, en naarmate het systeem langer in gebruik is moeten er zelfs op deze lapmiddelen nieuwe reparaties worden uitgevoerd om de beveiliging van gegevens zoveel mogelijk te waarborgen. Moeten we dan stoppen met het uitvoeren van regelmatige controles en het aanbrengen van patches? Driewerf neen! Informatietechnologie en het ontwikkelen van correcte en veilige software blijven de meest complexe

2

Madison Gurkha januari 2015

werkzaamheden die de mensheid ooit heeft bedacht. Het regelmatig controleren van bestaande infrastructuren en IT-diensten geeft een beeld van de huidige stand van zaken dat door de CIO en/of CISO gebruikt kan worden om te sturen. Zo nu en dan zal er besloten moeten worden niet langer te proberen een systeem door middel van patches voldoende veilig te houden, maar dat het tijd is voor de ontwikkeling van een volledig nieuw systeem. Dit biedt nieuwe mogelijkheden, nieuwe kansen, meer gebruikersvriendelijkheid, grotere marktpenetratie en een betere beveiliging. Betere beveiliging; alle andere zaken worden wel door de business aangedragen en misschien dat ze zelfs beveiliging willen opnemen in het eisenpakket. Maar juist de kans om een systeem vanaf de grond op te bouwen met een correcte implementatie van informatiebeveiliging, wordt in verreweg de meeste gevallen nog niet aangegrepen. Informatiebeveiliging moet een integraal onderdeel zijn van het systeem. Het kan nooit worden toegevoegd aan een bestaand systeem, omdat het dan juist zwakke plekken zal vertonen op het koppelvlak tussen het bestaande systeem en de toegevoegde beveiligingsmaatregelen. Door security by design te omarmen zal er uiteindelijk een systeem ontwikkeld kunnen worden dat integraal aanzienlijk veiliger is. Onze consultants kunnen uw organisatie daarbij in alle fasen van het ontwikkelen testproject van dienst zijn. En hoewel de initiële kosten van de ontwikkeling van een dergelijk systeem wellicht hoger zijn, worden deze snel terugverdiend doordat er aanzienlijk minder kosten noodzakelijk zijn om het systeem veilig te houden. Ik hoop dat ik aan het einde van 2015 kan rapporteren dat meer organisaties de hierboven geschetste mindset hebben eigengemaakt en daarmee hebben geholpen de Nederlandse IT weer een heel stuk veiliger te maken. Hans Van de Looy Partner en principal security consultant

In ‘Het Nieuws’ belichten we nieuwe ontwikkelingen in de IT-beveiligingswereld en rondom Madison Gurkha.

het NIEU W S

Hoe veilig is (IT in) Nederland? Op 18 juni 2015 organiseert Madison Gurkha alweer de 13e editie van de Black Hat Sessions. Voor bijgelovigen is 13 een getal met een bijzondere lading, voor ons een mooi moment voor een evenement met een maatschappelijk relevant thema. Binnen de vitale infrastructuur zoals stroom, water, transport en communicatie is IT onmisbaar geworden. Maar het gaat uiteraard verder dan deze meest vitale sectoren, want wat is de financiële sector of gezondheidszorg zonder IT? Het einde van de digitalisering is nog lang niet in zicht. Met het internet verbonden systemen worden steeds meer gemeengoed: systemen in huis, in de auto en zelfs rondom het menselijk lichaam. Het gebruik van (zoveel) IT brengt automatisch (grote) risico’s met zich mee. Zijn we ons voldoende bewust van deze risico’s? Handelen we ernaar? Hebben we deze risico’s onder controle, of is het tijd voor een digitaal deltaplan? Het belooft wederom een inspirerende dag te worden met gerenommeerde sprekers uit het vakgebied, interactieve workshops en veel praktijkvoorbeelden. Via de website www.blackhatsessions.com houden wij u op de hoogte van de meest actuele informatie omtrent het programma en inschrijving.

“Bedankt voor de fijne samenwerking in het afgelopen jaar. Graag tot ziens in 2015 waarin we graag samen met u de uitdaging aangaan de (Nederlandse) IT weer een heel stuk veiliger te maken!” het team van Madison Gurkha

Save the Date: 18 juni 2015 | Black Hat Sessions Part XIII

Wegens succes herhaald: workshop Hacken met een Teensy Een digitale aanval uitvoeren met een ogenschijnlijk onschuldig usb-apparaat? Tijdens de workshop Hacken met een Teensy gaat u onder begeleiding van ervaren security consultants hands-on aan de slag met het programmeren van een Teensy: een usb-apparaat dat zich kan voordoen als een toetsenbord en geheel autonoom, door toetsaanslagen naar de computer door te sturen, een aanval uit kan voeren. De workshop wordt gehouden op 3 februari a.s. in de Pionier in Utrecht en wordt tweemaal aangeboden: een ochtendsessie van 09.30 uur tot 12.00 uur en een middagsessie van 14.30 uur tot 17.00 uur. Het deelnametarief bedraagt € 110,= inclusief documentatie, de Teensy en usb-stick met daarop de scripts. Zie onze website voor meer informatie en het inschrijfformulier.

Voorkomen is beter dan genezen De beste manier om een applicatie zo veilig mogelijk te maken is het vanaf het begin meedesignen van de security. De training Secure web programming geeft u een goed inzicht in zaken waarop moet worden gelet bij het ontwerpen en implementeren van (web)applicaties zodat deze bestand zijn tegen de meest voorkomende aanvallen: zoals invoermanipulatie, SQL-injectie, cross-site-scripting en misbruik van zwakke authenticatie. Op 25 maart en 1 april a.s. organiseert Madison Gurkha in samenwerking met AT Computing een tweedaagse klassikale training Secure web programming. Aanmelden kan via onze website.

Let op! Er is per sessie ruimte voor max. 20 deelnemers. Inschrijving gebeurt op basis van volgorde van binnenkomst (vol=vol).


3

Madison Gurkha interviewt voor iedere editie een gerenommeerd persoon in de ICT-beveiligingswereld om zijn of haar visie te delen. Deze keer een interview met Tim Hemel, CTO bij iComply en lid van de Secure Software Foundation.

het interview

“Dit framework heeft een pragmatische insteek” Kun je kort samenvatten wie jullie zijn en wat jullie doen? Vanuit ons bedrijf iComply, dat zich specialiseert in secure software, zijn we het Framework Secure Software gestart. Hiermee geven we enerzijds ontwikkelteams een hulpmiddel om op ieder moment feedback te krijgen over de veiligheid van de software die ze ontwikkelen en anderzijds kan deze veiligheid onafhankelijk getoetst worden door middel van certificering.

“We zien de vraag naar aantoonbaar veilige software sterk stijgen” Waarom hebben jullie het Framework Secure Software in het leven geroepen? Hoe is het tot stand gekomen? Het ontbreken van een certificering voor de veiligheid van software was iets dat ons verbaasde en ons heeft doen besluiten te onderzoeken hoe zo’n certificering eruit moest zien. Snel bleek dat hier ook vanuit de markt behoefte aan was en met steun van het ministerie van Economische Zaken, via het programma

4


Digiveilig & Digivaardig van ECP, is de ontwikkeling hiervan gestart. Op 27 mei 2014 is de eerste versie van het framework vrijgegeven. Daarvoor is een onafhankelijke stichting opgericht: de Secure Software Foundation (www.securesoftwarefoundation.org). Waarom moeten bedrijven juist dit framework gebruiken? Welke incentives zijn er voor (nodig)? Als je vraagt wat het voordeel is van dit framework ten opzichte van andere initiatieven dan is het antwoord dat dit framework een pragmatische insteek heeft. Het richt zich echt op de techniek van het veilig bouwen van software en het kan toetsen hoe het staat met de veiligheid, op ieder moment in het ontwikkelproces: van requirements en architectuur tot en met implementatie en testen. Wat incentives betreft, zien we dat het framework deze zelf al biedt: ontwikkelaars zijn erg gecharmeerd van de pragmatische aanpak en hun managers zien met de certificering mogelijkheden zich te onderscheiden van hun concurrenten. We zien daarnaast de vraag naar aantoonbaar veilige software sterk stijgen. Dit geeft me het vertrouwen dat het framework een oplossing kan bieden voor het maatschappelijk probleem van onveilige software. Welke veranderingen zullen bedrijven in hun processen gaan merken zodra ze dit framework gebruiken? Dat hangt natuurlijk voor een groot deel af van hoe

het interview

een organisatie op dit moment software bouwt. Met het framework proberen we ons zo min mogelijk te bemoeien met hoe een organisatie software bouwt, maar we vragen wel om de resultaten van bepaalde processen vast te leggen zodat de veiligheid van de software getoetst kan worden. Dat betekent dat een organisatie op een bewustere manier moet nadenken over software-veiligheid en dat moet vastleggen. Wanneer dat vroeger nooit is gedaan, kan het wegwerken van deze technical debt best wat tijd kosten. Aan de andere kant bespaar je jezelf mogelijk een hoop ellende doordat de software minder beveiligingsfouten bevat. Hoe verhouden het Framework Secure Software en pentesting zich t.o.v. elkaar? Maakt het framework pentesting overbodig of blijft pentesting een kwaliteitscontrole? Ik zou erg trots zijn wanneer in jullie rapporten straks het beveiligingsoordeel ‘sterk’ zou staan als gevolg van het ontwikkelen volgens het framework. Toch verwacht ik dit niet snel, al was het maar omdat we nog steeds afhankelijk zijn van kwetsbaarheden in de infrastructuur en onderliggende software.

Door veranderende ontwikkelprocessen (agile, continuous delivery, devops) zie je dat de aard van beveiligingstests moet mee veranderen. In plaats van een grote applicatietest achteraf is er behoefte aan kleinere tests tussendoor. Ontwikkelteams hebben behoefte aan een beveiligingsexpert die meedraait in het ontwikkelteam om dergelijke tests uit te voeren. Het framework biedt hiervoor ook handvatten en pentesten heeft hierin zeker een plaats.

“Ontwikkelteams hebben behoefte aan een beveiligingsexpert die meedraait in het ontwikkelteam”


5

het interview

Secure Software Foundation De Secure Software Foundation heeft tot doel de ontwikkeling van veilige software te bevorderen. Concreet doet zij dit ondermeer door het beheren en ontwikkelen van het Framework Secure Software. Daarnaast is zij uitgever en kwaliteitsbewaker van het Secure Software Certificate. Met dit certificaat kunnen software-ontwikkelorganisaties aan gebruikers en klanten aantonen dat hun software betrouwbaar ontwikkeld is. De Normcommissie ontwikkelt en bewaakt de kwaliteit van het Framework Secure Software. Deze commissie bestaat uit specialisten op het terrein van Secure Software Development, waaronder Tim Hemel, CTO bij iComply. Contactgegevens Secure Software Foundation T 0348 40 80 61 E [email protected] www.securesoftwarefoundation.org

“Kwaliteitswaarborging is een van de grote uitdagingen van dit framework“

Daarnaast is het zo dat, om een certificaat te krijgen, de software op een gegeven moment gekeurd moet worden. Een onafhankelijke partij die de beveiliging controleert is hierbij essentieel. Zien jullie mogelijkheden om het Framework Secure Software als norm te verheffen waartegen getoetst kan worden? (denk aan de Logius-norm voor DigiD-onderzoeken). Welke voors en tegens zien jullie hierin? Een van de doelen van het framework was het kunnen toetsen van de beveiliging via een certificering. Dat betekent dat overheden, branche-organisaties enzovoorts zouden kunnen eisen dat software moet voldoen aan de certificeringseisen. Een dergelijke adoptie zou een geweldige steun zijn in de strijd tegen onveilige software. Belangrijk is daarbij echter wel dat de kwaliteit van het framework en de toetsing hierop gewaarborgd blijft. We lezen vaak over keurmerken die in de praktijk waardeloos blijken te zijn. Het zou echt zonde zijn als iets dergelijks met het framework zou gebeuren, juist omdat veilige software zo belangrijk is voor onze maatschappij. Kwaliteitswaarborging is een van de grote uitdagingen van dit framework en we zijn op het moment bezig met het preciezer vastleggen van de kaders waarbinnen een auditor de normen kan interpreteren. Op die manier streven we ernaar de waarde van de certificering zo hoog mogelijk te houden. Waar kunnen we, buiten de papieren versie van het Framework Secure Software om, meer leren over het werken met het framework. Zijn er voorbeelden/casussen vanuit de praktijk, cursussen, e.d.? De beste manier om meer te leren over het framework is door het toe te passen, maar we beseffen dat enige hulp hierbij handig kan zijn. Naast de begeleiding die we onze klanten geven, willen we dan ook meer kennis verspreiden, bijvoorbeeld via cursussen vanuit ons zusterbedrijf Security Academy en examenpartner EXIN. Voorbeelden uit de praktijk zijn wat lastiger te geven, omdat niet iedere organisatie informatie over hun softwarebeveiliging wil delen. We zijn bij iComply bezig met een intern project, dat we ontwikkelen met behulp van het framework. Het plan is om het verloop hiervan gedetailleerd te beschrijven, zodat ontwikkelaars een idee krijgen hoe het framework in de praktijk kan worden toegepast.

6


Dit keer in de rubriek ‘De Hack’ gaat Daniël Dragicevic ˇ ´ in op de verschillende kwetsbaarheden die in de OWASP Top 10 Mobile Risks zijn opgenomen.

OWASP

de h ac k

OWASP Top 10 Mobile Risks Praktijkvoorbeelden, aandachtspunten en aanbevelingen Madison Gurkha januari 2015

7

de h ac k In Update #22 (september 2014) zijn we in de rubriek ’De Hack’ ingegaan op de verschillende risico’s bij het gebruik van mobiele platformen en applicaties. In dit artikel bespreken we specifiek de OWASP Top 10 voor mobiele applicaties, en benoemen we praktijkvoorbeelden, aandachtspunten en aanbevelingen. M1: Insufficient server controls Het eerste risico betreft onvoldoende of onvolledige controle aan de serverzijde van inkomende berichten en/of acties. Wanneer we het hebben over de serverzijde kunt u zich afvragen of dit risico wel thuishoort in een lijst van risico’s voor mobiele applicaties. Mobiele applicaties worden veelal in combinatie met gegevensbronnen op serversystemen gebruikt; denk hierbij aan SOAP-, REST- of XMPP-interfaces. De clienten servercomponent vormen in feite twee onderdelen van hetzelfde informatiesysteem. Deze worden vaak ten onrechte los van elkaar gezien. We raden daarom aan om beide componenten in een beveiligingsonderzoek mee te nemen. In de praktijk zien we vaak dat inkomende berichten onvoldoende worden gecontroleerd. Dit geeft een aanvaller de mogelijkheid om meer informatie op te vragen dan noodzakelijk. Ook kan een aanvaller acties uitvoeren die niet bij zijn rol passen. Dit soort autorisatiecontroles dienen zowel aan de client- als aan de serverzijde te worden uitgevoerd.

M2: Insecure data storage Het tweede risico gaat over onveilige opslag van gegevens. We adviseren vaak om zo min mogelijk gegevens op een mobiel apparaat op te slaan. Dat wil zeggen: sla enkel de gegevens op die noodzakelijk zijn voor het functioneren van de applicatie. Om tot deze dataset te komen moet er een threat model van de applicatie worden gemaakt waarbij duidelijk wordt welke gegevens worden gebruikt en waar deze worden opgeslagen. Voorbeelden van plaatsen waarin we vaak gevoelige data vinden zijn SQLite-databases, logbestanden, XML-bestanden, binaire opslagbestanden en cookie stores. Tijdens onderzoeken zien we vaak onversleutelde SQLite-databases en logbestanden waarin gevoelige informatie is opgenomen. Denk hierbij aan POST-requests met sessie-identifiers, gebruikersnamen en wachtwoorden. Met deze gegevens is het voor een aanvaller mogelijk om zich voor te doen als gebruiker van de applicatie, zonder deze ooit te hebben gestart.

8


Het is erg belangrijk om u bewust te zijn van de plaatsen waar deze gegevens terecht kunnen komen. Denk hierbij aan backups op desktopsystemen of synchronisatie naar clouddiensten als iCloud, Google Drive of Microsoft SkyDrive. Het feit dat gegevens gesynchroniseerd worden zorgt ervoor dat een aanvaller de mogelijkheid heeft om gegevens te achterhalen zonder dat deze in het bezit is van het mobiele apparaat waarop de applicatie geïnstalleerd is. Het aanvalsoppervlak wordt hiermee aanzienlijk vergroot. Zorg daarom voor sterke encryptie van gegevens die op een mobiel apparaat worden opgeslagen. Denk hierbij ook aan het veilig opslaan van sleutelmateriaal.

M3: Insufficient Transport Layer protection Dit risico draait om de bescherming van gegevens tijdens transport over een netwerk. In sommige gevallen zien we dat er geen gebruik wordt gemaakt van een versleutelde verbinding. De vertrouwelijkheid van gegevens is dan in beginsel niet gewaarborgd. Vaker zien we dat er gekozen wordt voor een ’gewone’ SSL-verbinding. Dat wil zeggen dat de applicatie vertrouwt op de certificate store van het mobiele OS voor de controle van SSL-certificaten. Wanneer een CA-certificaat in de certificate store van het mobiele besturingssysteem voorkomt, zal de applicatie gesigneerde certificaten vertrouwen en een verbinding opzetten. Wanneer een aanvaller de certificate store van een mobiel bestu-

Zorg voor sterke encryptie van gegevens die op een mobiel apparaat worden opgeslagen

ringssysteem kan manipuleren (d.w.z. een CA-certificaat kan toevoegen), vervalt de beveiligingsmaatregel en kan een aanvaller het netwerkverkeer afluisteren en manipuleren. Ook moet rekening worden gehouden met de mogelijkheid dat onder de vele standaard vertrouwde CA’s, die zich over de wereld verspreid bevinden, ook CA’s kunnen zitten die een vals certificaat uitreiken; bijvoorbeeld als gevolg van compromittering of toepassing van juridische dwangmiddelen. We adviseren daarom altijd om gebruik te maken van certificate pinning. Bij deze techniek controleert de applicatie zelf of het server- of CA-certificaat voldoet aan de verwachting van de applicatie. Op deze manier wordt het slagen van een SSL-verbinding afhankelijk (pinned) van een specifiek server- of CA-certificaat.

M4: Unintended data leakage Dit risico omvat alle vormen van informatielekken. Vaak komen deze informatielekken voor als gevolg van onbewuste opslag van gegevens, dat wil zeggen: opslag op plaatsen waarmee geen rekening wordt gehouden. Deze opslaglocaties zijn platformspecifiek. Op Apple’s iOS wordt bijvoorbeeld een screenshot van de applicatie gemaakt wanneer deze door een gebruiker naar de achtergrond wordt gedrukt. Zo’n screenshot kan gevoelige informatie bevatten. Ook URLen toetsaanslag-caches zijn locaties waar onbedoeld gevoelige data terechtkomt. In de praktijk zien we dat logbestanden en diagnostische data onnodig veel informatie bevatten. We hebben in de praktijk meerdere keren gezien dat logbestanden met daarin leesbare gebruikersnamen, wachtwoorden, bestandsnamen en andere gevoelige informatie naar ontwikkelaars, advertentieproviders en clouddiensten worden gestuurd. Zorg ervoor dat u exact weet welke informatie wáár wordt opgeslagen en of deze naar het internet wordt gecommuniceerd. M5: Poor authorization and authentication Dit risico omvat gebreken in de autorisatie en authenticatie van gebruikers. Gevolg hiervan is dat beperkingen die zijn opgelegd, niet altijd worden gehandhaafd. Gebrekkige

de h ac k autorisatie en authenticatie zijn problemen die we vaker tegenkomen bij onderzoeken naar mobiele applicaties. We zien veelal dat vertrouwd wordt op autorisatiecontroles aan de clientzijde. Ook zien we dat er geen misbruikscenario’s (abuse cases) worden gedefinieerd bij het bouwen van de serversoftware. Wanneer een aanvaller een geldige sessie met de server kan opzetten, heeft hij soms meer functionaliteit tot zijn beschikking dan zichtbaar is in de client. Dit heeft invloed op de vertrouwelijkheid en integriteit van gegevens die op de server worden verwerkt. Ook zien we dat authenticatie een uitdaging is op mobiele platformen. Het is voor gebruikers immers niet handig om lange wachtwoorden te moeten invoeren op een klein toetsenbord. Vaak wordt vertrouwd op vier- of vijfcijferige pincodes voor toegang tot gegevens en applicaties. Deze zijn aanzienlijk gemakkelijker te kraken dan complexe wachtwoorden. We adviseren daarom vaak om te kijken naar het gebruik van meerfactorauthenticatie in de vorm van clientcertificaten of tokens.

M6: Broken cryptography Het risico van zwakke versleuteling kan verregaande gevolgen hebben. Vaak zien we dat, wanneer er versleuteling wordt gebruikt, ervoor gekozen wordt om meer gegevens op het mobiele apparaat op te slaan. Er wordt verondersteld dat het risico op uitlekken van gegevens is weggenomen. Bij zwakke versleuteling zien we vaak meerdere oorzaken. Ten eerste kan er gebruik worden gemaakt van oude en onveilige versleutelings- of hashingmethoden. Denk hierbij aan 3DES, MD4, MD5 of SHA1. Ook kan het zo zijn dat de gegevens waarop de versleuteling wordt gebaseerd onvoldoende willekeurig zijn. Wat we in de praktijk vooral tegenkomen is een onveilige omgang met sleutelmateriaal. Denk hierbij aan encryptiesleutels die in de applicatiedirectory worden opgeslagen. Wat we ook zien is dat sleutelmateriaal in de broncode van de applicatie wordt opgenomen. Een aanvaller kan in deze gevallen door het dumpen van de applicatiedirectory en reverse engineering van de binary het sleutelmateriaal achterhalen waarmee de gegevens kunnen worden ontsleuteld. We adviseren dan ook om sleutelmateriaal niet buiten de daarvoor bedoelde secure storage op het mobiele apparaat op te slaan. M7: Client Side Injection Dan is er het risico van injectie van gemanipuleerde data in de mobiele applicatie. Hierbij wordt vaak gedacht aan JavaScript- of SQL-injectie op het moment dat de appli-

We adviseren om alle in- en outputs in kaart te brengen en overal strikte validatie toe te passen catie uitgevoerd wordt. Echter, bij mobiele applicaties kan het verder gaan dan dat. Ook gegevens die vanaf het bestandssysteem van het mobiele apparaat worden gelezen kunnen worden gemanipuleerd. Zo hebben we een mobiele applicatie onderzocht die gebruikmaakte van certificate pinning. Hierbij werd een CA-certificaat vanuit de bestandsmap van de applicatie geladen en vergeleken met het CA-certificaat dat door de server werd overlegd. We hebben het CA-certificaat op het bestandssysteem vervangen door een CA-certificaat dat door ons was uitgegeven: zo konden we certificate pinning omzeilen. Dit is een eenvoudige manier waarop door middel van injectie van gemanipuleerde data een beveiligingsmaatregel is omzeild. We adviseren om alle in- en outputs in kaart te brengen en overal strikte validatie toe te passen.

M8: Security decisions via untrusted inputs Wanneer een applicatie beveiligingsmaatregelen laat afhangen van invoer die door de gebruiker of door een aanvaller kan worden gemanipuleerd, spreken we van een beveiligingsbesluit dat is genomen op basis van niet-vertrouwde invoer. Een voorbeeld hiervan is het toekennen van beheerdersrechten wanneer een “admin=True” parameter in een URL wordt meegestuurd. Deze parameter kan door een aanvaller worden gezet. In het geval van mobiele applicaties zien we dat beveiligingsbesluiten worden genomen op basis van gegevens (bijv. cookies) die onversleuteld op het bestandssysteem van het mobiele apparaat staan. Door deze te manipuleren kan een aanvaller onterecht toegang krijgen tot functionaliteit en gegevens die niet toegankelijk zouden moeten zijn. Zorg er daarom voor dat deze informatie versleuteld wordt opgeslagen om de kans te verkleinen

dat deze worden gemanipuleerd. Ook kan gekozen worden voor een opzet waarbij de autorisatiegegevens van de server worden opgehaald bij het starten van de applicatie; zorg hierbij wel voor een veilige (pinned) verbinding.

M9: Improper session handling Onveilig sessiebeheer is een risico dat we in de praktijk vaak tegenkomen. We zien dat sessie-identifiers vaak niet, of pas na lange tijd verlopen en worden geïnvalideerd. Gecombineerd met het onveilig opslaan van gegevens is het voor een aanvaller gemakkelijk om toegang te krijgen tot een gebruikerssessie. Zorg ervoor dat sessies binnen acceptabele tijd verlopen. Daarnaast moeten sessie-identifiers willekeurig worden gegenereerd en versleuteld worden opgeslagen. M10: Lack of binary protections Dit risico spitst zich toe op de mogelijkheid tot reverse engineering van mobiele applicaties. Door een binary te analyseren en te vertalen naar leesbare broncode en begrijpelijke applicatielogica is het voor aanvallers mogelijk om aanvalsmogelijkheden te ontdekken. Denk hierbij aan het omzeilen of uitschakelen van ingebouwde beveiligingsmaatregelen, het aanpassen van applicatielogica en het stelen van gegevens. In een recent onderzoek hebben we op basis van reverse engineering achterhaald hoe de gegevens op het mobiele apparaat werden versleuteld. De versleuteling werd uitgevoerd op basis een aantal factoren. Een vijfcijferige pincode die bij het starten van de applicatie werd gevraagd was in dit geval de enige onbekende factor. Op basis van deze informatie konden we in korte tijd de pincode van de gebruiker achterhalen en de gegevens ontsleutelen. Zoals u heeft kunnen lezen is er een groot aantal zaken waar rekening mee gehouden moet worden bij de ontwikkeling van mobiele applicaties. Zorg ervoor dat zowel voorafgaand aan, als tijdens het ontwikkelproces, gebruik wordt gemaakt van threat modeling. Dit geeft een goed beeld van het aanvalsoppervlak, de trust boundaries en gegevensstromen in de applicatie. Op basis van deze informatie is het mogelijk om in alle fasen van het ontwikkelproces misbruikscenario’s (abuse cases) te definiëren. Deze kunnen in een pentest worden gebruikt en zorgen uiteindelijk voor een mobiele applicatie waarin de vertrouwelijkheid, integriteit en toegankelijkheid van gegevens kan worden gewaarborgd.


9

In elke Madison Gurkha Update vragen wij een klant het spreekwoordelijke hemd van het lijf met betrekking tot zijn of haar relatie met IT-beveiliging. Dit keer 8 vragen aan Ziekenhuis Tjongerschans.

de k l ant

8 vragen aan ... ... Wiebrand Hoeksma,

hoofd ICT en lid van de commissie informatie-

veiligheid en Janneke Hofstede, projectcoördinator ICT en voormalig projectleider NEN 7510, bij Ziekenhuis Tjongerschans.

1 “Tjongerschans wil zijn patiënten op gastvrije wijze moderne, effectieve en efficiënte tweedelijns basiszorg aanbieden, passend bij zijn functie en excellerend op een aantal speerpunten. Wij doen dit zoveel mogelijk in samenwerking met onze partners in de regio.”

10


Wat voor een ziekenhuis is Tjongerschans? Ziekenhuis Tjongerschans is een algemeen ziekenhuis in Friesland. Het ziekenhuis heeft, naast het leveren van basiszorg op alle vakgebieden, speerpunten als sportgeneeskunde, ouderenzorg en het centrum voor Moeder en Kind. Het ziekenhuis heeft haar hoofdvestiging in Heerenveen en heeft daarnaast nog sublocaties als Sportstad Heerenveen, Steenwijk en Lemmer.

2

Hoe is de informatiebeveiliging opgezet binnen uw organisatie? De invoering van informatieveiligheid is projectmatig opgepakt binnen Tjongerschans door implementatie van de NEN 7510. In dit project is vooral ook aandacht besteed aan bewustwording onder de medewerkers. Daarnaast zijn vele punten uit de NEN 7510 pragmatisch aangepakt. Na de implementatie van de NEN-norm is een permanente commissie in het leven geroepen om de informatieveiligheid te borgen en te handhaven. Hierbij is een Information Security Management System (ISMS) ingericht.

3

Hoeveel mensen houden zich in uw organisatie bezig met informatiebeveiliging? Binnen Ziekenhuis Tjongerschans hebben wij een commissie Informatieveiligheid ingericht, bestaande uit diverse medewerkers met verschillende functies. Daarnaast is er ook een permanente link gelegd met kwaliteitszorg binnen het ziekenhuis. In totaal zijn er circa 10 a 15 medewerkers met een actieve taak/functie binnen informatiebeveiliging.

dekl a nt

4

Met welke uitdagingen op het gebied van informatiebeveiliging en privacy heeft uw organisatie te maken? In de zorg is privacy van de gegevens een belangrijk item. Niemand wil natuurlijk dat zijn/haar gegevens op straat liggen. Maar ook binnen de organisatie mag niet iedereen overal bij kunnen. Echter, als alle rechten worden beperkt, wordt het werken op de werkvloer erg omslachtig en tijdrovend. De juiste inrichting van autorisaties en het kiezen en bepalen van kaders waarbinnen medewerkers dienen te acteren is dan ook een dagelijkse uitdaging. Een voorbeeld hiervan is het delen van gegevens onder collega’s ten behoeve van bijvoorbeeld een collegiaal overleg. Wat kan wel via e-mail en wat niet? Wij hebben de bescherming van persoonlijke en gevoelige patiëntgegevens, waarmee wij als zorginstelling te maken hebben, hoog in het vaandel staan. Er zijn dan ook allerlei aspecten waarmee wij rekening houden op het gebied van de aanschaf, inrichting en configuratie van bijvoorbeeld netwerken en software. Ook laten wij mogelijke hackerstechnieken meewegen bij de diverse keuzes die gemaakt worden.

5

Wat betekent de NEN-norm specifiek voor uw organisatie? De NEN-norm stelt hele duidelijke voorwaarden over wat wel en wat niet mag met betrekking tot persoons-/bedrijfsinformatie. In de praktijk is dit soms lastig toepasbaar, dus vergt het hier en daar meer inspanningen om de NEN ingeregeld te krijgen en geborgd te houden binnen ons ziekenhuis. NEN heeft niet alleen betrekking op het feit dat je je in de praktijk moet houden aan de norm, maar het moet bovendien worden vastgelegd in documentatie.

6

Onlangs is er een onderzoek door het CBP gedaan naar de staat van gebruikte software bij een ziekenhuis. Hieruit is gebleken dat er veel verbeterd dient te worden aan verouderde software van medische apparatuur. Hoe gaat Tjongerschans om met de software van medische apparatuur? 95% van alle pc’s binnen ons ziekenhuis zijn reeds over op Windows 7. Voor de laatste 5% is de oplossing iets ingewikkelder en

vergt dit meer tijd. Dit zijn vooral de medische pc’s. Sommigen zijn wel over te zetten naar Windows 7 maar vergen veel afstemming met leveranciers omdat dit vaak legacy software betreft. Een aantal is ook niet over te zetten omdat de leverancier geen compatible software heeft voor Windows 7. Vandaar dat er binnen ons ziekenhuis voor de laatste werkplekken gekeken wordt naar individuele oplossingen. Deze werkplekken zullen in ieder geval worden geïsoleerd binnen de ICT-infrastructuur.

7

Welke maatregelen worden genomen om bestaande informatiebeveiligingsrisico’s onder controle te houden? Hieronder volgen een aantal maatregelen die binnen Tjongerschans genomen zijn ten behoeve van de informatieveiligheid: • Implementatie van o.a. firewalls en IPS-systemen; • We hanteren 2-factor authenticatie op de werkplek (inloggen met personeelspas); • Kritische ruimten zijn alleen met geautoriseerde personeelspas te betreden; • Uitvoeren van interne scans van het netwerk d.m.v. Nessus; • Er worden regelmatig interne audits uitgevoerd; • Met regelmaat moeten de wachtwoorden verplicht gewijzigd worden; • Autorisaties / rechten worden regelmatig geëvalueerd; • Toegang is gekoppeld aan de Active Directory, die gekoppeld is aan het HRM-systeem.

8

Hoe ondersteunt Madison Gurkha daarbij wat zijn de ervaringen tot nu toe? Madison Gurkha ondersteunt Ziekenhuis Tjongerschans bij het verbeteren van haar beveiliging, door als onafhankelijke partner de ICT-netwerken te controleren op mogelijke zwakheden en verbeterpunten. Door deze samenwerking ontstaat een overzicht van de risico’s die binnen de ICT-afdeling kunnen worden opgepakt en verbeterd. Dit zorgt voor een continue verbetering van de status van de ICT-beveiliging van ons ziekenhuis. De samenwerking ervaren wij tot op heden als erg positief.


11

In de rubriek ‘Het Inzicht’ stellen wij bepaalde (technische) beveiligingsproblemen aan de orde. Dit keer geven we meer inzicht in de beveiliging van SAP-systemen, met bijdrage van Mark Deiss, SAP security consultant.

H E T IN Z IC H T

evens Salarisgeg

Actuele liquidite

it

cificaties

Materiaalspe

ens

Testgegev

Grootboekgegevens

evens

Bankgeg

SAP

de aanvaller van binnenuit Bij het zoeken naar risico’s ten aanzien van SAP-systemen wordt meestal gedacht aan functieconflicten en kritieke autorisaties. Die aanpak focust op administratief-organisatorische risico’s die kunnen optreden als gevolg van handelen van eigen medewerkers. Dit artikel gaat over de beveiliging van SAP-systemen op het grensgebied tussen de interne organisatie en het publieke internet. Over welke kwetsbaarheden moet je je zorgen maken en hoe krijg je de risico’s onder controle?

12


HET INZ IC H T

Dit proces van toenemende rechten in SAP gaat ongemerkt steeds verder, SAP-systemen SAP-systemen vormen het hart van de bedrijfsvoering bij veel grote organisaties. Ze spelen een grote rol bij financiële instellingen maar ook bij bijvoorbeeld productiebedrijven. SAP levert systemen voor verschillende aspecten van de bedrijfsvoering: denk aan Enterprise Resource Planning (ERP), Human Resources (HR) management en Customer Relation Management (CRM). In principe kan elk type organisatie de bedrijfsvoering met SAP ondersteunen. SAP kan volledig worden toegesneden op de organisatie. Om dit laatste te realiseren heeft SAP een bijzondere strategie. Programmeren is namelijk niet nodig. Zonder een regel code aan te passen kan een SAP-systeem op maat worden gemaakt (“gecustomized”) voor elke organisatie. Een SAP-consultant analyseert de bedrijfsprocessen en legt deze vast in selecties in SAP. Dankzij deze methode kan de software meegroeien met de organisatie, is het systeem goed passend te maken en is er veel standaard functionaliteit beschikbaar. Deze grote voordelen hebben ook nadelen, want er is beveiligingstechnisch weinig ruimte voor flexibiliteit. De wurging van flexibiliteit Henry Ford wist dat industrialisering van de auto-industrie alleen mogelijk is als alles repeteerbaar en standaard is. Bij SAP-systemen lijkt het omgekeerde te ontstaan. Er kunnen makkelijk uitzonderingen gemaakt worden. Dat is wat bedrijven willen: zo flexibel mogelijk zijn. Voor een bepaald proces wordt een aantal SAP-transacties gebruikt, maar tegelijkertijd kan met andere transacties hetzelfde proces bestuurd worden op een iets andere manier. Uiteindelijk worden autorisaties op verzoek steeds breder gemaakt. Daarbij ontstaan ongemerkt combinaties van autorisaties die te veel toegang geven. Processen ontsporen als ze niet meer rechtlijnig zijn en veel afkortingen kennen. Denk hierbij bijvoorbeeld aan magazijnprocessen die een wirwar van boekingscodes kennen en waarbij veel gebruikers het proces mogen beïnvloeden. Daarnaast zorgen krimpende budgetten ervoor dat dezelfde hoeveelheid werk vaak met minder personeel moet worden uitgevoerd, waardoor medewerkers aan meer processen deelnemen en meer autorisaties hebben. Dit proces van toenemende rechten in SAP gaat ongemerkt steeds verder, met alle risico’s van dien. De dode hoek van SAP GRC-oplossingen Rond 2008 was duidelijk dat dit uiteindelijk zou leiden tot ongewenste situaties. SAP lanceerde daarop de Governance Risk Compliance (GRC)-applicatie, waarmee kan worden gescand naar optredende functieconflicten en kritische autorisaties. Bijvoorbeeld de autorisatie tot het bewerken van crediteuren in combinatie met de autorisatie tot het aanpassen van de betalingsrun. De SAP GRC-applicatie kan dit soort functieconflicten goed detecteren.

met alle risico’s van dien

Ook kritische autorisaties kunnen goed gedetecteerd worden. Het probleem hierbij is dat kritieke functies door de hele organisatie worden uitgevoerd. Dat iemand een kritieke autorisatie heeft, wil niet direct zeggen dat er sprake is van een probleem of risico. Dit hangt van de persoon en de functie af en is door een tool moeilijk te bepalen. Zo worden bepaalde kritieke autorisaties makkelijk toegestaan omdat het nu eenmaal onvermijdelijk is. Ook voor accountants is SAP GRC een opleving geweest: je kunt er immers snel mee zien op welk gebied een organisatie wel of niet ‘in control’ is. Er zijn ook zaken die buiten het blikveld van SAP GRC vallen: welke autorisaties wel en niet gebruikt worden in maatwerkcode, de kwaliteit van de maatwerkcode zelf, beveiligingen die niet in autorisatie maar in customizing zijn vastgelegd en alle andere constructies in de SAP-infrastructuur die kwetsbaarheden kunnen bevatten. SAP GRC is dus geen oplossing voor alle mogelijke problemen. In de praktijk wordt echter vaak de houding aangenomen dat het hebben van een beveiligingsbeleid en de SAP GRC-applicatie voldoende veiligheid waarborgt. In dit artikel proberen we uit te leggen dat deze insteek de achilleshiel van veel organisaties is. Zoals de Chief Executive Officer (CEO) het ziet Voor de CEO is het vooral van belang dat het aantoonbaar is dat de organisatie ‘in control’ is, voor de goedkeuring van de jaarrekening. SAP GRC is een belangrijk hulpstuk om dit te waarborgen. Inzicht in functieconflicten en kritieke autorisaties is de zichtbare ‘bovenkant’ van het SAP-systeem. Er is echter ook een minder zichtbare ‘onderkant’ van SAP. Je ziet niet direct of je wel of niet kwetsbaar bent. Daarom laat de CEO een beveiligingsassessment of penetratietest uitvoeren door een onafhankelijke derde. Deze testen worden doorgaans niet vanaf het interne netwerk, maar vanaf het internet uitgevoerd. Er is hierbij onvoldoende aandacht voor aanvallen van ‘binnenuit’. Dit kunnen aanvallen zijn vanaf het interne netwerk naar de SAP-servers en databases of aanvallen op SAP- functionaliteit en autorisaties die buiten het zicht van SAP GRC vallen.


13

H E T IN Z IC H T

Het in ‘control’ zijn is dus van meer zaken afhankelijk dan de uitkomsten van alleen SAP GRC. Het kwetsbare gebied van SAP In SAP hoef je niet te programmeren, maar het kan wel. En als dat gedaan wordt, ligt de focus vaak alleen op de functionaliteit, en niet op de vraag of het veilig is. Een vaak optredend probleem is dat eigen maatwerkcode niet genoeg autorisatiecontroles uitvoert. Als gevolg daarvan ontstaan er kwetsbaarheden die moeilijk te vinden zijn. Een voorbeeld is maatwerk dat geen rekening houdt met organisatiestructuren, zodat er (ongewenst) informatie van andere organisaties of vestigingen opgehaald kan worden. Een ander voorbeeld is maatwerk dat een eigen beveiliging creëert die minder sterk is dan autorisatie in SAP, en gemakkelijk omzeild kan worden. Een voor de hand liggende gedachte is dat de organisatie dit zelf moet oplossen door grondig te testen. Echter, op een SAP-project en de onderhoudsorganisatie ligt doorgaans een hoge druk om tijdig een nieuwe release op te leveren waardoor het snel in gebruik kunnen nemen van de functionaliteit door de business vaak prevaleert boven de beveiligingseisen. Bovendien ontbreekt het vaak aan diepgaande technische kennis om alle kwetsbaarheden op te sporen. Target SAP Op afstand over een computernetwerk pogen in te breken heeft een groot voordeel: de aanvaller zit (ver) weg en hoeft niet bang te zijn om gevonden te worden. Als een aanvaller toegang krijgt tot het besturingssysteem van een SAP-omgeving, dan is een volgende aanval gemakkelijk uit te voeren. Het is echter niet eenvoudig om langs die weg iets van betekenis in SAP te doen. Een rekeningnummer uit het systeem halen is iets heel anders dan ongemerkt betalingen uitvoeren. Aanvallers weten tot op de dag van vandaag veel van netwerktechnologie, kwetsbaarheden en het gebruik van exploits, maar veel minder van SAP. Dit is echter aan het veranderen. Sinds 2010 wordt binnen hacker communities aandacht besteed aan SAP. Het valt te verwachten dat goed

14


Wat moet er beschermd worden? Organisaties hebben vaker dan gedacht onvoldoende besef van hun kwetsbaarheid. Er zijn veel voorbeelden van gegevens te noemen die zeker kwaad kunnen in de handen van anderen, denk aan: • Gegevens over de actuele liquiditeit; • Grootboekgegevens; • Salarisgegevens; • (Bank)gegevens van crediteuren en debiteuren; • Materiaalspecificaties; • Testgegevens (speciaal voor de farmaceutische industrie). Hierbij hebben we het alleen nog maar over gegevens. Wat als men van buitenaf ook invloed krijgt op de specifieke bedrijfsprocessen? Denk hierbij aan: • Vertragen van orders zodat klanten afhaken; • Beïnvloeden van de leverancierskeuze; • Omleiden van SEPA-betalingen; • Instellen van minimale maar periodieke betalingen aan een bonafide lijkende crediteur; • Toegang blokkeren via een “locking attack”; • Verbindingen met klanten stilleggen door middel van een DDOS-aanval. SAP is vaak een kroonjuweel van een organisatie en dus een heel interessant target. Daar moet je zijn voor gegevens en daar moet je zijn voor betalingen.

HET INZ IC H T

gefinancierde groepen die in teamverband werken, SAP effectief zullen kunnen binnendringen en hierop geavanceerde aanpassingen kunnen doen. Het combineren van verschillende kennisgebieden waaronder netwerktechnologie maar ook bijvoorbeeld kennis over financiën en logistiek is hierbij van groot belang. De aanvaller is al binnen Waar moet men zich meer zorgen over maken: kwaadwillenden binnen de organisatie of kwaadwillenden van buiten de organisatie? Leveranciers van GRC-tooling stellen dat de grootste risico’s van binnen het bedrijf komen, gezien de kennis en de toegang die mensen daar hebben. Mensen binnen de organisatie weten vaak heel goed waar de echt belangrijke gegevens zitten of waar zich een geldstroom bevindt waarop weinig of geen controle plaatsvindt. Daar zullen ze echter nooit misbruik van maken, want alle sporen leiden dan direct naar hen. Geheel anders wordt het als er mogelijkheden bestaan om sporen te wissen, of handelingen van een ander afkomstig te laten lijken. Onzichtbaar worden is waar het om gaat. Eén van de meest kwetsbare plekken in SAP zit daar waar mensen functionaliteit gebruiken op een onhandige en onveilige manier, in een gebied waar veel kennis bestaat over de organisatie, en er enig idee bestaat over hoe dit op een malafide manier toe te passen is zonder gezien te worden. Deze plek zit precies tussen de gebieden die volop aandacht krijgen zoals netwerkbeveiliging en de detectie van functieconflicten. Kwetsbaarheden kunnen op creatieve manieren worden gecombineerd. Bijvoorbeeld door gebruik te maken van een Single Sign-On-mechanisme dat het toestaat om ook andere gebruikers over te nemen. Als dit wordt toegepast, dan wijzen alle sporen naar het slachtoffer. Onderzoek loopt dan vaak naar een dood spoor, omdat het voor de hand liggende niet bewezen kan worden. De ‘dader’ heeft het niet gedaan.

SAP is vaak een kroonjuweel van een organisatie en dus een heel interessant target Op de website www.madison-gurkha.com staat een fictieve aanval beschreven waarin het combineren van kwetsbaarheden wordt gedemonstreerd. Er is hierbij bewust gekozen om bepaalde stappen en informatie weg te laten, zodat de aanval niet direct nagebootst kan worden. In control Zoals het artikel aangeeft is het toepassen van SAP GRC een goede eerste stap om risico’s van SAP-systemen te verminderen. Maar dat is zeker niet voldoende. Er zullen ook penetratietesten moeten worden uitgevoerd richting SAP-servers en databases en dan niet alleen van buitenaf, maar vooral vanaf het interne netwerk. Het grootste gevaar dreigt van binnenuit, hetzij door medewerkers of inhuurkrachten, hetzij door buitenstaanders die zich toegang tot het interne netwerk hebben verschaft door middel van geavanceerde malware. Het meest onbekende en daarmee het meest kwetsbare gebied ligt in het maatwerk van SAP en de blinde vlekken van SAP GRC. Een integrale SAP security test waarin alle bovenstaande onderzoeksgebieden worden meegenomen, geeft het meest complete beeld van de risico’s van SAP-systemen en de maatregelen die organisaties dienen te nemen. Pas na het uitvoeren van deze testen en het nemen van adequate maatregelen, kan een organisatie stellen dat het ‘in control’ is. Dit artikel is tot stand gekomen in samenwerking met Mark Deiss, SAP security consultant ([email protected]).


15

Dit keer in de ITSX-rubriek uitleg over de ITSX Risico Tool door Arthur Donkers. Verder vertelt Ralph Moonen over de ervaringen in Den Haag en Thorgal Nicasia stelt zich aan u voor.

ITSX

ITSX Risico Tool Risicomanagement is een continu proces binnen een organisatie. Tools kunnen hierbij ondersteunen om het risicomanagementproces zo soepel mogelijk te laten verlopen. Op basis van ervaringen uit de praktijk en met haar klanten heeft ITSX een eenvoudig te gebruiken risicotool ontwikkeld. De tool houdt gedetailleerd bij welke risico’s van toepassing zijn op een organisatie. De risico’s zijn verdeeld over de thema’s van de ISO 27001/27002 standaard. Om de risico’s in te schatten wordt gebruik gemaakt van een lijst van ongeveer 600 dreigingen die in meer of mindere mate van toepassing kunnen zijn op de organisatie. De impact (schade) van een risico is gemodelleerd volgens een generieke middelen- en impactclassificatie en maakt het daardoor mogelijk resultaten te vergelijken over verschillende organisaties heen. Per risico is het mogelijk om een aantal maatregelen uit de ISO 27002 te selecteren met als doel het risico terug te brengen naar een acceptabel niveau. Tevens wordt per risico ingeschat hoe gedegen de organisatie met het risico omgaat.

16


Alle informatie is samengevat in een dashboard waarmee een organisatie het middel in handen heeft om de voortgang van de risicomaatregelen bij te houden. Tevens kan dit dashboard gebruikt worden als rapportage naar het management. In onderstaand figuur is een voorbeeld van het dashboard opgenomen. In een volgende versie zal de tool worden voorzien van een exportmogelijkheid voor de totaalscores. Deze geëxporteerde informatie kan worden gebruikt om een scorecard inzichtelijk te maken op basis van het gewogen gemiddelde. Dit gewogen gemiddelde wordt in een apart overzicht weergegeven. Uiteraard houden wij u op de hoogte van nieuwe mogelijkheden en verdere ontwikkelingen!

IT SX

HSD Campus ITSX heeft haar team uitgebreid met Thorgal Nicasia in de rol van accountmanager. Wellicht heeft u al kennis met hem gemaakt? Hij stelt zich graag aan u voor. Als accountmanager bij ITSX ben ik sinds september vorig jaar actief om de zichtbaarheid van ITSX in de markt te vergroten. Met veel enthousiasme zet ik me samen met de rest van het team in om organisaties bewust te maken van het belang van goed risicomanagement en informatiebeveiliging. De rol bekleden van accountmanager bij ITSX betekent dat je de vrijheid krijgt om niet alleen de dienstverlening onder de aandacht te brengen, maar ook marktontwikkelingen te integreren in bestaande en nieuwe diensten. Hierdoor kan ITSX niet alleen inspelen op nieuwe behoeftes die bij klanten ontstaan maar daagt het mij en het consultancyteam uit om te blijven innoveren. In 2015 zal ITSX veel aandacht besteden aan thema’s zoals: privacy en kennisdeling op het gebied van informatiebeveiliging en risicomanagement. Dit doen we onder andere door het verzorgen van privacy impact assessments en het organiseren van cursussen, workshops en kennissessies. Daarnaast blijven we uiteraard ook in het nieuwe jaar onze doelstellingen verwezenlijken om een succesvol bedrijf te zijn en u als klant optimaal te ondersteunen om ‘in control’ te komen en te blijven.

Op 13 februari 2014 opende minister Opstelten officieel de HSD Campus in Den Haag. De Campus is een cluster voor security en safety gerichte bedrijven en is een initiatief van de gemeente Den Haag en de Hague Security Delta (HSD). Op de Campus komen overheid, bedrijven en researchinstellingen met een gezamenlijke focus op beveiliging samen. De bedoeling is om met deze clustering ook een samenwerking tussen de bedrijven en instellingen te verkrijgen. Op 1 juni 2014 heeft ITSX haar kantoor op de HSD Campus geopend. Dit biedt ons een zeer prettige werkruimte, maar ook toegang tot de andere bedrijven en instellingen. Dit heeft inmiddels al geleid tot samenwerking. Op onze verdieping zitten bijvoorbeeld ook het Cyberlab van TNO, de Belastingdienst, KLPD en Fox-IT. Een verdieping lager zit de receptie met een aantal gezamenlijke faciliteiten zoals een vergaderruimte, open werkplekken en een presentatieruimte.

Regelmatig wordt er door de HSD ook het “HSD Café” georganiseerd waar uiteenlopende maar vaak gespecialiseerde onderwerpen worden gepresenteerd zoals Biometric Identification, Crisis Communication of Data Breach Notification Requirements. De Campus is dermate succesvol dat behalve de 7e en 8e verdieping, nu ook de 6e verdieping wordt verbouwd en binnenkort door nieuwe huurders betrokken kan worden. Voor ITSX is het grootste voordeel echter dicht in de buurt te zitten van een aantal van haar klanten en via de HSD toegang te hebben tot een zeer groot netwerk van overheidsorganisaties en instellingen. De vestiging in de Campus past dan ook zeer goed in de groeistrategie van ITSX en we hopen hier nog lang en met veel plezier te kunnen werken.

Graag tot horens/ziens. Thorgal Nicasia [email protected] 06 551 96 550

Het nieuwe adres van ITSX is: HSD Campus, kamer 8.01 Wilhelmina van Pruisenweg 104 2595 AN Den Haag

i

T

S

X


17

Dit keer doet Walter Belgers verslag van de “t2 infosec conference” die hij vorig jaar oktober in Helsinki heeft bezocht en waar hij zelf een presentatie over lockpicking en IT-beveiliging heeft verzorgd.

foto’s beschikbaar gesteld door t2 infosec

het versl ag

t2 infosec Op 23 en 24 oktober 2014 vond de 11e editie van de jaarlijkse conferentie t2 infosec plaats in Helsinki. Aan het roer van deze conferentie staat Tomi Tuominen, een Fin die ruim 10 jaar geleden op een andere conferentie vrienden werd met allerlei goede sprekers uit de ITbeveiligingswereld (oftewel “hackers”, maar dat woord heeft een beetje een verkeerde bijsmaak) die hij uitnodigde om naar Finland te komen. Hij betrok daarbij onder andere de graag geziene spreker Mikko Hyppönen.

18


De t2 infosec conference stond al heel lang op mijn lijstje om eens te bezoeken. Het belangrijkste verschil met andere conferenties is dat er slechts 99 bezoekers worden toegelaten (naast de sprekers). Dit maakt t2 een hele intieme conferentie, waarbij volop gelegenheid is om anderen uit het vakgebied te leren kennen. Wat daar ook aan bijdraagt, is de gezamenlijke borrel en het diner na de eerste conferentiedag. De sponsoren waren tijdens de conferentie subtiel aanwezig, wat de intimiteit alleen maar verhoogde. Programma De organisatie stelt strenge eisen aan het programma. Zo wordt (net als bij de NLUUG in Nederland) als eis gesteld dat de sponsoren geen invloed hebben op het programma. Sprekers voorstellen is mogelijk, maar die worden door de programmacommissie beoordeeld, onafhankelijk van het sponsorbe-

het verslag

het versl Ag enda ag In de Madison Gurkha Update presenteren wij een lijst met interessante bijeenkomsten die de komende tijd zullen plaatsvinden. Zie ook Het Nieuws elders in deze Update.

drag. Bij veel, wat commerciëlere conferenties, werkt dat niet zo. Verder worden alleen sprekers uitgenodigd die aantoonbare ervaring hebben, en dan moet het onderwerp natuurlijk ook nog eens interessant genoeg zijn. Ik had zelf een lezing ingestuurd over lockpicking en IT-beveiliging en de parallellen daartussen. Mijn TEDxpraatje op YouTube bleek voldoende om mijn presentatiekunsten te beoordelen en zo stond ik 24 oktober voor een zaal mensen een praatje te geven. Ik noem verder een aantal opvallende praatjes die ik volgde. De keynote was van Aral Balkan van http:// ind.ie/. De boodschap was dat de manier waarop startups met venture capital werken en uiteindelijk door grote jongens als Google opgekocht (willen) worden, er nooit toe zal leiden dat communicatie-applicaties veilig zullen worden en de privacy van de gebruiker zullen beschermen. De gegevens van de gebruikers zijn namelijk het product. Ind.ie gaat apps maken en heeft een clausule die het onmogelijk maakt om het bedrijf te verkopen. Alexander Bolshev had de (voor mij) meest indrukwekkende presentatie. Een klant van hem met een grote fabriek had een paar kilometer buiten het (beveiligde) terrein sensoren geplaatst, die gekoppeld waren met een draad via het HART protocol (een analoog protocol dat met PLC’s praat in een ICSomgeving, net zoals bijvoorbeeld Modbus). Het is hem gelukt om, met alleen toegang tot deze draad, het protocol te analyseren en te kraken om zo de FieldCare software (Plant Asset Management) aan te vallen en ook de SAP-server die daar weer achter stond. Alsof het kraken van ICS-systemen al niet erg genoeg is, liet Hugo Teso in de lezing daarna zien, hoe je vliegtuigsoftware kraakt. Het is

erg makkelijk om die software te downloaden en deze blijkt vol met lekken te zitten. Deze software draait op een aparte VxWorks instance, maar die draait wel op dezelfde hardware als waarop VxWorks instances draaien met bijvoorbeeld de in-flight entertainment software. Mijn vlucht naar huis was opeens iets minder ontspannen, kan ik je zeggen. Tijdens een praatje over enkele malwarefamilies door Antti Tikkanen, bleek dat professionele pokerspelers doelwit zijn van criminelen die op hun scherm mee willen kijken als ze on-line spelen. Bij een Finse speler had men het sleutelsysteem van het hotel gekraakt om zijn kamer binnen te dringen en malware op zijn laptop achter te laten. Verder waren er verhalen over gerichte aanvallen op bedrijven in de energiesector en overheden. De afsluitende lezing ging over de t2 ‘14 Challenge. Dit was een soort “hackme”, waarbij je wat informatie krijgt en moet uitzoeken wat er precies aan de hand is. Hierbij zul je moeten reverse engineeren, decompileren en goed nadenken. De challenge was zodanig ingewikkeld dat ik veel ontzag heb voor de winnaar (de hoofdontwerper van Spotify), die daarmee een gratis toegangskaart won. Maar ik heb ook bewondering voor de maker die bijvoorbeeld een DOSbinary voor een schuifpuzzel wist te maken in 400 bytes, met self-modifying code, archaïsche opcodes en allerlei andere trucjes. Op (toch nog) een enkele mindere lezing na was de conferentie erg geslaagd. De inhoud, de mensen, de intimiteit, de locatie, het rendierenvlees: ik hoop dat ik er volgend jaar weer bij kan zijn. Voor meer informatie: http://t2.fi

2 februari 2015

Workshop Hacken met een Teensy De Pionier, Utrecht In deze interactieve workshop gaat u hands-on aan de slag met de Teensy. Ervaren security consultants van Madison Gurkha leggen uit hoe de Teensy werkt, wat u ermee kan en leert u aan de hand van een ´toy example´ hoe de Teensy kan worden gebruikt bij het uitvoeren van een digitale aanval.

25 maart, 1 april

Training Secure web programming De Pionier, Utrecht Deze tweedaagse klassikale training leert, voornamelijk aan de hand van voorbeelden en discussies, hoe (web)applicaties geprogrammeerd moeten worden zodat ze bestand zijn tegen de meest voorkomende aanvallen: zoals invoermanipulatie, SQLinjectie, cross-site-scripting en misbruik van zwakke authenticatie.

18 juni 2015

Black Hat Sessions Part XIII De Reehorst, Ede www.blackhatsessions.com Op 18 juni organiseert Madison Gurkha de 13e editie van de inmiddels befaamde Black Hat Sessions. Tijdens deze editie kijken we samen met deskundigen uit het vakgebied hoe Nederland ervoor staat: hoe afhankelijk zijn we van IT en hoe gaan we om met de daaraan verbonden ITbeveiligingsrisico’s. Houd de website in de gaten voor actuele informatie omtrent het programma en inschrijving.

het colofon Redactie Rinke Beimin Daniël Dragicˇevic´ Laurens Houben Remco Huisman Matthijs Koot Maayke van Remmen Ward Wouts

Vormgeving & productie Hannie van den Bergh / Studio-HB Foto cover Digidaan

Contactgegevens Madison Gurkha B.V. Postbus 2216 5600 CE Eindhoven Nederland

T +31 40 2377990 F +31 40 2371699 E [email protected]

Bezoekadres Vestdijk 9 5611 CA Eindhoven Nederland

Redactie [email protected]

Voor een digitale versie van de Madison Gurkha Update kunt u terecht op www.madison-gurkha.com. Aan zowel de fysieke als de digitale uitgave kunnen geen rechten worden ontleend.


19

Safe?

Goede IT-beveiliging is niet zo eenvoudig als vaak wordt beweerd. Bovendien blijkt keer op keer dat deze beveiliging van strategisch belang is voor organisaties. Alle IT-beveiligingsrisico's moeten op een acceptabel niveau worden gebracht en gehouden. Professionele en gespecialiseerde hulp is hierbij onmisbaar. Kies voor kwaliteit. Kies voor de specialisten van Madison Gurkha.

Your Security is Our Business

tel: +31(0)40 237 79 90 - www.madison-gurkha.com - [email protected]

update jan 2015 i T S X DE COLUMN 2 Hans Van de Looy

Recommend Documents