The good, the bad and the innocent Hoe minimaliseren organisaties de kans op een SAPgerelateerde hack? Door: Mark Deiss / april 2015
Het liefst maakt een hacker misbruik van onschuldige medewerkers. Zo kan hij lange tijd onopgemerkt blijven en wachten tot de mogelijkheid om het maximale uit zijn hack te halen. Hoe kunnen onschuldige medewerkers zonder dat ze het weten door SAP-hackers tegen het bedrijf gebruikt worden? En wat kan een organisatie doen om deze en andere SAP-gerelateerde hacks tegen te gaan? In dit whitepaper buigt Mark Deiss, SAP Security expert bij Sogeti, zich over deze vragen. Dat doet hij aan de hand van een realistisch scenario, veelvoorkomend stappenplan van hackers, inzicht in de werking en de oorzaken van een hack en mogelijke securitymaatregelen. Bij de meeste geavanceerde hacks gaat het er om zo lang mogelijk onontdekt te blijven. Hoe onzichtbaarder een hacker is, hoe langer hij op het bedrijfssysteem actief kan blijven. Zolang een hacker alleen maar data leest en deze data op een voorzichtige manier naar buiten brengt, hoeven zijn activiteiten niet op te vallen. Op een gegeven moment wil een hacker toch zijn invloed uitoefenen. Elke actie die hij uitvoert, kan echter ook zijn ontdekking betekenen en dan is het voorbij. In dit whitepaper behandelen we de meest vervelende vorm van een hack. Namelijk een poging waarbij een hacker de medewerkers van een bedrijf op slinkse wijze gebruikt. In dat geval lijken de daden van hackers van vertrouwde medewerkers te komen.
1 Een realistisch scenario: ‘Bert heeft het gedaan’ Het volgende stuk is volledig fictief met gefingeerde namen.
Bert is een IT-beheerder bij een groot bedrijf. Hij beheert onder andere de interfaces van IT-systemen. Zijn collega Jan werkt op de crediteurenafdeling. Op donderdag moeten de wekelijkse betalingen gedaan worden. Jan controleert de betalingen en verzendt deze uiteindelijk met een SEPA-bestand. Op een donderdag is er echter iets vreemds aan de hand: het SEPA-bestand wordt zoals altijd aangeboden aan een interface die zorgt voor de verzending naar de bank, maar vandaag lukt het niet om het bestand te verzenden. De interface geeft een paar foutmeldingen en verstuurt het bestand niet. Dit is het moment waarop Bert wordt ingeschakeld. Jan belt Bert, ze kunnen elkaar dus niet zien. Bert opent het bestand, maar kan er in eerste instantie niets vreemds aan ontdekken. Bert wist het bestand en vraagt Jan het opnieuw te genereren. Opnieuw blijft het bestand hangen. Jan vraagt Bert nog eens het bestand te openen en te kijken wat er mis is. Na een tijdje van opnoemen van wat er in het bestand zit, wordt er één betaling gevonden die er niet in hoort. Aan een bekende crediteur met een bedrag van niet meer dan €5,-, maar toch een betaling die eerder niet in het SEPA-bestand zat. Jan spreekt met Bert af dat hij deze betaling zal verwijderen en het betalingstotaal met €5 zal verminderen. Jan
1
vertrouwt Bert. Ze kennen elkaar en Bert werkt al 25 jaar bij het bedrijf. Bert start de interface opnieuw en het bestand wordt nu wel verzonden. Mooi, nu is het tijd voor de controle. Aan de kant van de bank klopt het aantal betalingen en ook het totaalbedrag dat nu €5,- lager is, is juist. Dit bedrag klopt nu wel weer met de totaalsom die in SAP wordt aangegeven. Er gaat echter wel een rood lampje branden bij de automatische integriteitcontrole1, want er zijn verschillen tussen de gegevens van SAP en de bank. Maar dat is logisch, want Bert heeft een betaling verwijderd. Er is dus een duidelijke reden waarom dit afwijkt. Jan weet dit, hij heeft het allemaal gezien en autoriseert de betaling. Niet veel later blijkt dat er toch iets is misgegaan. Een van de rekeningnummers is onbekend. Er is onterecht een groot bedrag naar dit rekeningnummer overgeboekt dat eigenlijk naar een bekende crediteur had moeten gaan. Jan belt Bert. Boos vraagt hij waarom Bert dit rekeningnummer heeft aangepast. Bert weet van niks, hij ontkent in alle toonaarden. Toch is hij de enige die het gedaan kan hebben. Hij is immers de enige die toegang tot het bestand had. Bovendien heeft hij het SEPAbestand aangepast naar aanleiding van de fout die Bert en Jan ontdekt hadden. Bert, op zijn beurt, wordt ook boos. Hij beschuldigt Jan ervan hem in een val te laten lopen. Intussen is er een lachende derde: de hacker. Wat was werkelijk aan de hand in het hierboven beschreven scenario? Er heeft een hack plaatsgevonden. De hacker wist namelijk al lang van tevoren dat het bedrijf altijd een bepaalde interface gebruikt om betalingen te verzenden. Ook wist hij dat Bert de rechten had om het SEPA-bestand en de interface aan te passen. Dat alles is bepalend. De hacker kan echter, door de usergegevens van Bert te stelen, deze rechten zelf gebruiken. Maar dat doet hij niet: dit levert onregelmatigheden op die Jan zal herkennen. Jan zal vervolgens deze frauduleuze handelingen voorkomen, waardoor de hacker misschien ontdekt wordt. Daarom hanteert hij een andere strategie. De hacker veroorzaakt expres fouten in de interface en laat Jan en Bert een tijdje proberen om die op te lossen. Ondertussen heeft hij met malware, in een fractie van een seconde, het SEPA-bestand aangepast. Deze malware werkt onder de rechten van Bert, waardoor niemand doorheeft dat er een hackpoging achter schuilt. Het is de bedoeling dat Bert en Jan aan het bestand gaan sleutelen en de nepbetaling verwijderen. Pas als dat gebeurt, wordt het bestand in de interface vrijgegeven. De rest is bekend. Het is duidelijk dat een hacker niet alle rechten en alle wachtwoorden nodig heeft, zo lang er maar mensen zijn die deze rechten wel hebben en hij die kan overnemen. Dit laatste heeft absoluut zijn voorkeur, omdat naderhand alles er op wijst dat de onwetende medewerkers de schuldigen zijn. Sterker nog, de kans is aanwezig dat de benadeelde medewerkers zelf proberen de hack te verbergen omdat het moeilijk uit te leggen is.
2 Fraude of een hack? Op zich is het vreemd dat mensen overwegen fraude te plegen. Het is; stelen van je eigen baas die je salaris betaalt. Daarnaast riskeer je gevangenisstraf en verspeel je 1
Dit is een hashcheck. Controle van twee gegenereerde hash waarden. Als het bestand niet aangepast is, zijn de waarden het zelfde
2
de kans op het vinden van een nieuwe baan. Frauderen kan ook simpelweg niet meer, want met de huidige systemen wordt elke actie gelogd en is onzichtbaarheid onmogelijk. Toch komt fraude regelmatig voor. Voor een hacker ligt het net weer even anders. Hij fraudeert op afstand en heeft niet veel te verliezen. Hij heeft namelijk redelijke mogelijkheden om zijn sporen te wissen. En al is zijn IP-adres te achterhalen en te koppelen aan een locatie in het Russische buitengebied, dan nog is het allerminst zeker dat de hacker op basis van deze informatie opgepakt wordt. Voor zowel de fraudeur als de hacker heeft het vele voordelen om de schuld bij iemand anders in de schoenen te schuiven: een katvanger. Hun voorkeur gaat uit naar een katvanger die niet doorheeft dat hij een katvanger is, zoals in het geval van Bert en Jan. Ondertussen wil het benadeelde bedrijf maar een ding en dat is het verlies zo snel mogelijk aanvullen. Daarbij maakt het niet uit of de eigen verzekering of de bank het bedrag vergoedt. Helaas voor het bedrijf stellen banken en verzekeraars vaak een eigen onderzoek in. Als daaruit blijkt dat het bedrijf niet de juiste maatregelen heeft getroffen of op een andere manier verwijtbaar nalatig is geweest, dan keren zij niet uit. Voor het bedrijf is de kans op terugbetaling het grootst als er een aanwijsbare schuldige is. Daarom gaan de meeste organisaties die de dupe zijn van fraude direct op zoek naar een schuldige – ook al bestaat het vermoeden dat er meer achter zit. Dat is vervelend voor de betrokken medewerkers, ook al ben je in Nederland onschuldig tot het tegendeel bewezen is. Meestal wijst er namelijk veel bewijs in de richting van de medewerkers. Bewijs dan maar eens dat je onschuldig bent. Om zichzelf vrij te pleiten, is een medewerker dan eigenlijk alleen nog maar afhankelijk van een goede advocaat. Dat geldt ook in het hierboven geschetste scenario. Hierin heeft Bert alle schijn tegen. Hij heeft dan wel niet gefraudeerd, maar hij is wel de laatste geweest die het SEPA-bestand en de interface handmatig heeft aangepast. Daarmee is de kans groot dat hij als schuldige wordt aangewezen. Fraude is ineens heel aantrekkelijk als de kans om er mee weg te komen bijna 100% is. Dat is bijvoorbeeld het geval als een fraude lijkt op een hack of op een diefstal door derden. Zelfs voor een hacker die toegang heeft tot bedrijfssystemen en daardoor een lucratieve ‘hit and run’ kan uitvoeren, heeft identiteitsdiefstal voordelen. Daarom zal hij zijn hack het liefst in combinatie met identiteitsdiefstal doen. Het grote nadeel van ‘hit and run’ is dat het maar één keer werkt, hoe briljant de hack ook is. Daarna zijn alle slapende honden wakker en zijn de kansen om de hack nog eens uit te voeren voorgoed verkeken.
3 Stappenplan van een hacker Voordat we dieper ingaan op hoe identiteitsdiefstal werkt, eerst een schematisch overzicht van een aantal hack-vormen. Hierin is te zien hoe deze zich tot elkaar verhouden.
3
Network access SAP App server OS access
Hit and run
SEPA-without-rehashing SEPA-with-rehashing
explore Sabotage
password
SAP access
system-shutdown
Sabotage
permutational-data-corruption Stealth
Identity change by SSO misuse
data-extraction Stealth
vendor-selection empl-reactivation malicious-invoice
Hit and run
inc-and-transfer
Het spreekt voor zich dat niet alle mogelijke hack-methoden zijn weergegeven. Zo kan een hacker bijvoorbeeld met alleen OS-toegang ook data uit het bedrijfssysteem halen. Toch heeft hij liever toegang tot het SAP ERP-systeem, want dat levert hem veel betere gegevens op. Wie data uit SAP steelt, niets aanpast en niet laat blijken over bepaalde kennis van een bedrijf te beschikken, kan lang onontdekt blijven. Veel bedrijven hebben werkelijk geen idee wat anderen met hun bedrijfsinformatie kunnen doen. De wereld wordt mobieler en opener en informatie verbergen lijkt niet meer van deze tijd. Zo heb ik beheerders horen zeggen: “Zo lang een hacker maar niets kapot maakt, vind ik het prima. We hebben geen geheimen. Iedereen mag alles van ons weten”. Dat is een gevaarlijke aanname. Een klantenlijst in de verkeerde handen kan namelijk al leiden tot een heel andere concurrentiepositie, bijvoorbeeld omdat klanten ineens aanbiedingen van concurrenten krijgen. 4
In het schema is te zien dat een hacker veel opties heeft. Elk met een andere aanpak en kansen. Toch is er één wet die geldt voor elke hack-poging: met elke vorm van actieve beïnvloeding nemen de kansen op ontdekking toe. Bij sabotage maakt dat bijvoorbeeld niet uit. Maar hoe kun je subtiel invloed uitoefenen en toch onontdekt blijven? Dat is waar de meeste hackers naar streven. Hieronder bekijken we hoe hackers dat voor elkaar kunnen krijgen.
4 Hoe werkt de hack? De in dit whitepaper beschreven hack vindt u in het schema onder: SEPA-withoutrehashing. Om deze poging succesvol uit te voeren, heeft de hacker zelfs geen directe toegang tot SAP nodig. Hij maakt echter wel gebruik van de SAPinfrastructuur. Hoewel niet de hacker maar de onwetende medewerker de schuld krijgt in het beschreven scenario, valt de hack nog steeds onder ‘hit and run’. Na dit voorval staat namelijk alles op scherp. Het kan echter nog erger. Bijvoorbeeld als de hacker in SAP de users overneemt en goede en kwaadwillende acties door elkaar lopen. Deze vorm van hacking is in het schema aangeduid als ‘vendor-selection’. Om te voorkomen dat organisaties in deze val lopen, hieronder een beschrijving hoe een dergelijke hack tot stand komt. Stap 1: netwerk toegang De hacker moet toegang hebben tot het interne bedrijfsnetwerk. De veronderstelling is dat hij daarvoor binnen het bedrijfsgebouw moet zijn. Dat klopt, maar tegelijkertijd ook weer niet. Een hacker kan bijvoorbeeld op een creatieve manier gebruikmaken van een netwerk-hub. Dit is een apparaat dat het netwerkverkeer van het bedrijf naar buiten brengt. Dat kan via een draadloze verbinding of via de bestaande elektrische bekabeling. Een hacker kan een hub ongezien inbouwen in een printer. Niemand die wat merkt. Heeft de hacker een werkende hub, dan kan hij via een willekeurige kwetsbare plek, op twee manieren zijn hack plaatsen: als SEPA-hack of als sabotage. Beide acties kan hij maar eenmalig uitvoeren. Het is zelfs mogelijk om via een kwetsbaarheid een nieuwe SAP-user aan te maken. Maar dat doet de hacker in dit geval niet, want hij wil onzichtbaar blijven. Een nieuwe SAP-user aanmaken, valt te veel op. Stap 2: verkennen Heeft de hacker alleen netwerktoegang, dan kan hij verkennen wat er aan netwerkverkeer is. Doorgaans hebben bedrijven namelijk de verbindingen van SAP GUI naar SAP toe niet versleuteld. Zo wordt data via het DIAG-protocol alleen compressed, maar niet versleuteld. Er bestaan decompressie-plug-ins voor bestaande network sniffers. Daarnaast stellen bedrijven hun Web GUI steeds vaker in op http, dus zonder enige vorm van SSL/TLS. Hierdoor worden passwords eenvoudig leesbaar. Het sniffen van een password is voor een hacker dan een fluitje van een cent. Stap 3: toegang tot SAP Zodra de hacker een password van een bestaande SAP-user heeft, kan hij toegang tot SAP krijgen via SAP GUI. Liever nog krijgt hij toegang via de Netweaver Business Client (NWBC) of de Web GUI omdat dit http-gebaseerd is. Vanaf dit punt kan de
5
hacker meer gegevens inzien en downloaden. Om welke gegevens dit precies gaat, is afhankelijk van de rechten van de gehackte user. Stap 4: identiteitsdiefstal Eigenlijk heeft de hacker de identiteit van een user al gestolen. Hij kan immers inloggen onder een bepaalde gebruikersnaam. Waarom zou hij dan nog verder gaan? Omdat een verbetering van de identiteitswissel hem nog meer voordeel oplevert. Natuurlijk loopt de hacker meer risico als hij verder gaat, een gebruiker kan bijvoorbeeld zijn password veranderen. In dat geval moet de hacker het password opnieuw zien te achterhalen. Maar dit risico neemt de hacker voor lief. Wanneer hij het overnemen van een user verder verbetert, kan hij namelijk veel langer onontdekt blijven. Worden er dan pas onregelmatigheden geconstateerd, dan verandert een organisatie of user meestal eerst alle wachtwoorden. Hierbij sluit een organisatie dan vaak meteen uit dat er users overgenomen kunnen worden. Dat is nou net wat de hacker wil. Hij kan namelijk wel users overnemen via de Single Sign-On (SSO). SSO is bedoeld om het gebruikers makkelijk te maken. In plaats van een lange lijst wachtwoorden voor verschillende systemen, logt een gebruiker maar één keer in. Zo kan hij op alle aangesloten systemen komen. Dit bespaart de gebruiker veel gedoe. Bovendien is het veiliger omdat hij niet meer hele lijsten met wachtwoorden op zijn pc hoeft te bewaren. Iedereen gaat er vanuit dat deze gebruiker op alle systemen dezelfde user is. Het is echter mogelijk, als je dit zo instelt, om van user A op systeem X, user B op systeem Y te maken. Deze constructie wordt soms doelbewust gebruikt in bepaalde applicaties. Een voorbeeld daarvan is een workflow-applicatie die tijdelijk onder een andere user werkt om te voorkomen dat een gebruiker te veel rechten krijgt. Om deze reden stelt een bedrijf vaak SSO user change (SSO-UC) in – de mogelijkheid om het eenmalig ingevulde wachtwoord te veranderen. Een hacker kan zo dus een wachtwoord veranderen, zonder dat iemand dit door heeft. De combinatie van SSO-UC met users met veel rechten, betekent voor de hacker de jackpot: hij kan users overnemen vanaf een ander systeem zonder een password. Wat wil een hacker nog meer? Hierdoor kan hij bijvoorbeeld het scenario ‘vendorselection’ in gang zetten.
5 Wat is de oorzaak? De hierboven beschreven stappen tonen aan dat een dergelijke hack buitengewoon realistisch is. Het is zeker geen rocket science en met beperkte middelen en kennis uitvoerbaar. Hierbij zit de kern van het probleem in SAP. SAP is niet onveilig, maar SAP wordt vaak onveilig gebruikt. SAP blinkt namelijk uit in het bieden van verschillende functionaliteit. Dat is goed, want het maakt SAP tot een Zwitsers zakmes. Elke specifieke functionaliteit heeft echter ook zijn eigen kwetsbaarheden die vaak onbekend zijn bij het bedrijf. Daarnaast bedenken bedrijven met SAP vaak constructies die weer leiden tot nieuwe kwetsbaarheden. Het niet raar dat hierbij voor hackers ongekende mogelijkheden ontstaan. Wederom geldt hierbij dat niet SAP zelf onveilig is, maar dat het bedrijf zelf bewust of onbewust onveilig constructies maakt. De laatste jaren is het belangrijk geworden om heel voordelig een ICT-systeem te bouwen of te onderhouden. Met minder personeel, minder training voor het 6
overgebleven personeel en vooral het outsourcen van SAP-beheer als gevolg. Wees nou eerlijk, als u de kans hebt om voor een derde van de prijs een goed functionerend systeem aan te schaffen, laat u die niet liggen. Vanzelfsprekend testen de meeste bedrijven of hun nieuwe systeem of oplossing werkt, maar dat is alleen een functionele test. Lean, Agile en Scrum zijn goede technieken die kostenefficiënt resultaten opleveren en vooral focus toevoegen. Dit sluit niet uit dat er ook goede security komt. Vaak denkt een bedrijf wel aan security maar alleen op een lokaal niveau. Dat is een valkuil, want goede security bestaat altijd uit verschillende lagen. En alleen lokale security kan leiden tot beveiligingslekken en kwetsbaarheden. Dat illustreert het beschreven scenario ook. Hier gebruikt de hacker kwetsbaarheden uit onder andere het netwerk, SAP en kennis van het operationele gedrag van de organisatie. Met andere woorden: in het scenario heeft niemand meer het overzicht hoe de security als geheel werkt. Om het overzicht terug te krijgen, is er een bijzondere rol weggelegd voor de architectuur. In de eerste plaats kan een bedrijf met een gestructureerde en toekomstvaste architectuur een wildgroei aan constructies tegengaan. In de tweede plaats kan het bedrijf zo controleren of er tussen ketens geen zwakheden ontstaan. Het gaat echter te ver om te stellen dat de architect dan maar verantwoordelijk moet zijn voor de volledige integrale security. Hij kan niet weten hoe een programmeur iets codeert, noch kan hij dat controleren. Security is het beste geborgd als het in elke laag terug komt: ontwerp, architectuur, ontwikkeling en beheer. Tot slot is het raadzaam om het overzicht te bewaren bij het uitbesteden van ketens, zodat hierbij geen nieuwe kansen voor hackers ontstaan. De optelsom is snel gemaakt: organisaties die de bouw en het beheer van een ICTomgeving uit handen geven, slechter overzicht hebben van hun ICT-infrastructuur en security, plus de toename van staten en radicale groeperingen die het gemunt hebben op geld of sabotage. Dat opgeteld, betekent een toename van het aantal security-gerelateerde incidenten, zoals de hierboven beschreven hack. Dit scenario is niet alleen realistisch en relatief eenvoudig, maar ook bijzonder ernstig omdat onschuldige werknemers hierbij de schuld krijgen.
6 Verdedigingsmaatregelen tegen hackers Hoe is een hack te voorkomen? Dat is de achterliggende vraag in dit whitepaper. Om dit vraagstuk te kunnen oplossen, moeten we eerst de verdediging opsplitsen in structurele en technische maatregelen. Op basis daarvan kunnen we specifieke security-maatregelen aanstippen. Structurele maatregelen Outsourcing is vaak onafwendbaar. De kostenreductie is voor de meeste organisaties eenvoudigweg te belangrijk. Tooling zoals SAP GRC, CSI-AA zijn goed, maar beslaan echter ook maar een specifiek gebied, in dit geval rechten in de SAP applicatie. Naar de infrastructuur wordt niet gekeken. Hier bestaat weer andere tooling voor van bijvoorbeeld Virtualforge (SAP infra en code) en Onapsis (SAP infra). Tooling kan een oplossing bieden mits naar alle security relevante aspecten wordt gekeken. Dit betekent altijd verschillende tools. De licentiekosten moeten dan wel nog in verhouding staan tot het afdekken van risico’s. Duidelijk is dat als security niet integraal bekeken wordt, er kwetsbare plekken kunnen ontstaan waar tooling niets 7
meer aan kan veranderen. In het geval van outsourcing kan dat nog verergeren omdat niet de hele keten overzien kan worden. Denk na over passende tooling, maar laat ook geregeld een onafhankelijk kwetsbaarheidsonderzoek doen. De kosten van een kwetsbaarheidsonderzoek voor de infrastructuur en SAP zijn eenmalig. Daarnaast levert een dergelijk onderzoek veel inzicht op. Het is nodig omdat veel organisaties na verloop van tijd niet meer goed zien wat de zwakke security-plekken zijn. Een extern kwetsbaarheidsonderzoek ondervangt dit gevaar. Dat is dan ook het meest belangrijke aspect van een kwetsbaarheidsonderzoek. Dit onderzoek moet breed opgezet zijn: het moet gericht zijn op de netwerkinfrastructuur, SAP-infrastructuur en de SAP-custom code. Maar dat is nog niet alles: de grootste fouten worden altijd nog gevonden in bedrijfsspecifieke oplossingen, zoals de eigen interfaces en eigen ABAP-code. Dit komt omdat ‘kostenefficiënt bouwen’ bij veel organisaties nog steeds prioriteit heeft. Dat is op zich niet fout, maar de kostenefficiëntie slaat vaak door naar de gedachte: ‘zodra het werkt is het af’. In dit paper heeft u kunnen lezen, dat dit zelden het geval is. Dus zorg altijd dat security een onderdeel is van elk project. Externe toetsing is zeker niet onverstandig. Technisch maatregelen Zoals uit het voorbeeld blijkt, is de end-to-end controle van hashes van SEPAbestanden geen overbodige luxe. Zorg voor overdracht van de hash naar de bank op een andere manier dan het SEPA-bestand met automatische afwijzing aan de kant van de bank bij afwijkingen. Zorg dat re-hashing geen aanvalsoptie is. Geef niemand standaard toegang tot interfaces op het niveau dat inhoudelijke wijzigingen mogelijk zijn. Implementeer de door SAP voorgestelde security-maatregelen voor SAP RFC Gateway. Implementeer SSO maar zonder dat er een mogelijkheid bestaat dat users overgenomen worden. Dat geldt ook voor interfaces. Zorg dat er geen ongebruikte poorten en services in SAP open staan. Zorg voor voldoende netwerksegmentatie. Het mag bijvoorbeeld niet mogelijk zijn om vanuit een guest netwerk bij SAP te komen. Zorg bij elk interface met SAP ervoor dat de interface-component uniek geïdentificeerd kan worden. Het mag niet mogelijk zijn om op een interface in te kunnen breken Gebruik de security-aanbevelingen die SAP geeft in de implementation guides. Maak gebruik van SNC-versleuteling tussen de SAP-backend en SAP GUI. Gebruik HTTPS voor de Web GUI.
7 Conclusie De security van SAP-oplossingen is geen sinecure. Al helemaal wanneer u in ogenschouw neemt dat er vaak een grote hoeveelheid processen plus oplossingen op een of andere manier te maken hebben met SAP. En er is altijd wel een achterdeurtje dat open staat: een onoplettende user, de security van een infrastructuuronderdeel die over het hoofd is gezien of ongebruikte SAP-services. Kortom, een wereld aan mogelijkheden voor slimme hackers. Ook al kunt u een hack niet 100% voorkomen, u kunt het hackers wel zo moeilijk mogelijk maken. Bijvoorbeeld door een aantal structurele en technische maatregelen door te voeren. 8
Maar vooral door te denken als een hacker: ze hebben de tijd om te wachten en willen graag zo lang mogelijk onontdekt worden. Hopelijk heeft dit whitepaper u inzicht in de denkwijze van een hacker verschaft. En heeft het u de ogen geopend dat security een continu, belangrijk proces is en constante aandacht vereist in elke laag van uw ICT-systeem – de menselijke factor ook meegerekend. Wanneer u dat beseft, hebt u de eerste stap richting een hackvrije ICT-omgeving met SAP gezet!
Dit artikel is geschreven door Mark Deiss. Mark is SAP Security Expert bij Sogeti. Hij implementeert SAP-autorisatiemodellen en voert SAP security audits uit waarbij de nadruk ligt op misbruik van bestaande functionaliteit. Op basis van zijn kennis van beide onderwerpen geeft Mark security awareness-trainingen. Meer weten over security voor SAP-omgevingen en/of een security awareness-training volgen?
[email protected] telefoon +31 6 5089 1631
9
