Madison Gurkha Update 23

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
agenda19
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 wet- en 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 ontwikkel- en
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).
Madison Gurkha januari 2015
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
Madison Gurkha januari 2015
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”
Madison Gurkha januari 2015
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
Madison Gurkha januari 2015
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
Madison Gurkha januari 2015
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.
Madison Gurkha januari 2015
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
Madison Gurkha januari 2015
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.
Madison Gurkha januari 2015
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
Madison Gurkha januari 2015
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.
Madison Gurkha januari 2015
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
Madison Gurkha januari 2015
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]).
Madison Gurkha januari 2015
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
Madison Gurkha januari 2015
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
Madison Gurkha januari 2015
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
Madison Gurkha januari 2015
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.
Madison Gurkha januari 2015
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]

Download Report