Een veilige infrastructuur in vijf stappen

In veel organisaties is er helaas niet echt sprake van een gestructureerde manier van toepassing van IT security maatregelen, ook wel security architectuur genoemd. Informatie beveiliging bestaat bij de meeste bedrijven voor een groot deel uit de volgende stappen:

 

  1. Het plaatsen van firewalls en IDS/IPS systemen in te infrastructuur, voor de detectie van en preventie tegen ongewenste datastromen in het netwerk.
  2. Om te bepalen welke websites wel of niet bezocht mogen worden en om te zorgen dat er geen malware met websessies mee komt wordt er meestal een proxy server met malware filtering gebruikt voor het web verkeer.
  3. Malware en SPAM worden via een mail-proxy tegen gehouden.
  4. End-point protectie in de vorm van malware en virus detectie en preventie.
  5. Bedrijven die echt alles willen doen aan het beveiligen van hun infrastructuur, installeren een honeypot om cybercriminelen te lokken om hun IDS/IPS camouflage af te gooien, of ze installeren een SandBox om verdachte software te testen op malware.
  6. De kers op de taart is het gebruik van een Security Information Event Management (SIEM) oplossing, die alle security feeds bijeenbrengt en intelligente analyse en correlatie kan toepassen op die feeds.

En dan gaat men lekker achteroverleunen, want men denkt alles voor elkaar te hebben ten aanzien van de beveiliging van hun infrastructuur. Als het dan toch mis gaat is men vaak hoogst verbaasd en is er in de meeste gevallen geen enkel scenario voor handen om de gerezen problemen op te lossen en de schade zo veel mogelijk te beperken. De lange lijst van geslaagde aanvallen op diverse grote internationale bedrijven zijn hiervan helaas een triest voorbeeld.

Dit zien we in de praktijk

IDS/IPS systemen missen bepaalde acties, of geven zo veel false positives dat er niet meer gereageerd wordt op meldingen. Malware wordt tegenwoordig zo geavanceerd ontwikkeld dat ze proxy servers kunnen misleiden. End-point protectie systemen blijken in de praktijk in eerste instantie maar iets van 30% tot 50% van de malware te detecteren. Via cloud mechanismen worden deze oplossingen snel op de hoogte gebracht van gemaskeerde malware, waardoor binnen enkele uren de protectie weer afdoende is, maar dan passen de aanvallers hun malware weer aan, waardoor de hele cyclus opnieuw kan beginnen.

Het feit blijft dat geen enkele IT infrastructuur 100% veilig is een geen enkel security component 100% afdoende bescherming biedt. De vraag is niet of je gehacked kan worden, maar wanneer je gehacked gaat worden.

Je kan wel zo veel mogelijk beschermingsconstructies opwerpen, waardoor het niet meer economisch haalbaar is voor een aanvaller om de aanval uit te voeren. Helaas betekent dat wel in de meeste gevallen veel ongemak voor de goedwillende gebruikers, want hoe log je nu in als je je RSA token net niet bij hebt, of als je SMS authenticatie niet werkt omdat je geen bereik hebt met je mobiele telefoon? Hoe weet je bovendien op welk niveau van beveiliging je geen economisch interessante target meer bent? Vaak gebruiken hackers een minder beveiligde omgeving als bruggenhoofd voor de aanval op een goed beveiligde infrastructuur. Een firewall inspecteert meestal wel uitgebreid verkeer van een verdachte regio zoals China, maar zullen de alarmbellen niet zo snel afgaan als een verdachte actie afkomstig is van een “vertrouwde” bron.

Wat is de beste aanpak?

Wat moeten organisaties dan wel doen om een gestructureerde security architectuur neer te zetten en de gevolgen van een geslaagde aanval te minimaliseren?

Stap 1 – Risico inventarisatie

Risico inventarisatie is vaak de eerste stap die fout gaat bij de meeste IT beveiliging projecten. Veel bedrijven weten niet wat hun kritische systemen zijn en waar hun kritische data zich bevindt, als ze al weten wat hun kritische data is. Resultaat is veelal dat IT security generiek toegepast wordt voor alle IT componenten, zonder dat er onderscheid gemaakt wordt in de maatregelen voor de individuele systemen. In de praktijk bestaat over het algemeen maar 10% van de IT systemen uit systemen die essentieel voor de bedrijfsvoering zijn en waarbij de confidentialiteit en integriteit van de data op die systemen optimaal gewaarborgd moet zijn. Voor dat soort systemen is de combinatie van firewall, IDS/IPS en SIEM in de meeste gevallen al niet meer voldoende. Wel voor de detectie natuurlijk, maar niet voor het tegenhouden van een aanval.

Na dat er gekeken is welke systemen kritisch zijn voor de bedrijfsvoering, moeten er zogenaamde aanval scenario’s opgesteld worden. Op welke wijze kunnen hackers die systemen benaderen en een aanval starten. Op basis van die scenario’s ga je de instellingen van IDS/IPS systemen en firewalls configureren.

Stap 2 – Applicatie en database beveiliging

De tweede fout die vaak gemaakt wordt is dat er voor bepaalde systemen niet voldoende gekeken is waar het systeem kwetsbaar voor is, en welke aanvullende maatregelen je moet treffen. In een ERP systeem moet je precies weten welke processen en stappen in de verwerking van gegevens een aanvullende analyse behoeven. Geen enkele IDS/IPS oplossing ziet dat in het ERP systeem de rechten om een retourboeking te doen, waarbij een klant geld terugkrijgt, gewijzigd zijn. Of dat een rekening nummer gewijzigd is in een buitenlands IBAN nummer. Dat soort analyses zou je wel met een SIEM oplossing kunnen doen door de logfiles van het ERP te analyseren, maar de logica dat het wijzigen van een rekeningnummer een potentieel risico kan zijn, moet je wel in de SIEM oplossing aanbrengen. Hetzelfde geldt natuurlijk voor alle andere applicaties, die vaak gebruik maken van een generieke database. In de applicatie zijn vrijwel altijd de autorisaties goed geregeld. Als de onderliggende database echter niet goed beveiligd is en door een database administrator rechtstreeks benaderd kan worden en die daar vervolgens wijzigingen in kan aanbrengen, dan is de applicatie security niets meer waard.

De ervaring leert dat de meeste kritische systemen een aanvullende database of applicatie monitoring tool nodig hebben, waarin alle logica zit om een aanval te detecteren en/of te stoppen. Hiervoor is uitgebreide kennis van de bedrijfsprocessen nodig, naast kennis van de tooling om de security events te kunnen monitoren. Deze kennis is in de meeste gevallen niet voorhanden bij de traditionele security leveranciers, maar zit in de eigen organisatie. In veel gevallen ook nog verdeeld over verschillende personen.

Stap 3 – Communicatiestromen vastleggen

Veel organisaties hebben geen goed beeld van de externe verbindingen die hun IT infrastructuur heeft met de buitenwereld. Daarnaast heeft men geen exact beeld waar de bedrijfsdata opgeslagen is. Mensen maken gebruik van Windows 365, Dropbox, VPN clients naar privé systemen, andere netwerken of cloud services. Deze sessies gaan meestal via een van de netwerk poorten die standaard toegestaan worden door een firewall, zoals poort 80 (HTTP) of 443 (HTTPS) Je kan dat soort sessies alleen blokkeren door slimme filtering op datastromen toe te passen. Filteren op basis van IP reputatie is niet voldoende, omdat je dan te maken krijgt met het feit dat kwaadwillenden gebruik kunnen maken van systemen met een IP adres uit een vertrouwde regio. Andersom maken bedrijven van naam en faam gebruik van IP adressen in regio’s zoals Oekraïne, Bulgarije en Roemenië, die traditioneel gebruikt worden als thuisbasis voor cybercrime.

Vastleggen van de verbindingen die zijn toegestaan en continue monitoring op sessie’s die verdacht kunnen zijn, lost het probleem op van ongeautoriseerde verbindingen. Een goed data classificatiebeleid dat aangeeft welke data buiten de eigen infrastructuur bewaard mag worden is de eerste stap in het beschermen van bedrijfsgegevens. Analyse van het verkeer dat de infrastructuur verlaat middels een Data Leakage Preventie tool is daarbij de volgende stap. 

Stap 4 – Security tooling selectie

Op basis van de risico analyse heb je een overzicht van je kritische systemen en de mogelijke aanval scenario’s. Op basis daarvan kun je de benodigde security tooling selecteren. Helaas worden aankopen nog te veel gedaan op basis van adviezen van leveranciers en niet op basis van requirements die tot stand zijn gekomen na een analyse van alle mogelijke risico’s. Het is van belang dat er een duidelijke lijst van eisen is waar de tooling aan moet voldoen en welke risico’s er moeten worden afgedekt.

Stap 5 – Reactie op aanvallen

Ik ken weinig organisaties die exacte scenario’s hebben klaar liggen die actief worden bij een geslaagde hack van hun infrastructuur. Dit varieert van de opvolging van de detectie dat een systeem is besmet met malware tot het feit dat de company website gecompromitteerd is. Nu kun je natuurlijk niet alle mogelijke scenario’s voorzien, maar veel zaken wel. Zo kan je een procedure inbouwen dat mensen van de helpdesk een besmette PC, zo snel mogelijk van het bedrijfsnetwerk afhalen, om verdere besmetting te voorkomen. Ten aanzien van een gehackte website kan je een procedure opstellen die er voor zorgt dat er een alternatieve website beschikbaar is, waar al het internetverkeer wat niet afkomstig van de aanvaller, naar toe wordt geleid. Het SANS institute heeft een goede training waarin vrijwel alle aspecten van het zogenoemde Computer Emergency Response vakgebied aan bod komen.

Bij gebruik van een SIEM oplossing is het in deze stap ook van belang om te bepalen welke actie’s een SIEM oplossing zal initiëren en wie die acties moet gaan opvolgen, binnen of buiten de organisatie.

Aldus mijn recept van vijf simpele stappen, die in mijn optiek de basis zouden moeten zijn voor elk informatie beveiligingstraject.