Security Management

Centraal in IT Security staat het management. Naarmate het belang van informatiebeveiliging groeit en het aantal ingerichte oplossingen groeit, wordt het centrale karakter van het beheerplatform steeds belangrijker. Overzicht, efficiëntie en Total Cost of Ownership zijn punten die het belang van integratie vergroten.

De integratie van beheerplatformen maakt correlatie mogelijk. Dat wil zeggen dat de informatie uit verschillende systemen met elkaar vergeleken wordt om adequaat of zelfs geautomatiseerd op signalen te reageren. Is een systeem geïnfecteerd, haal het van het netwerk. We worden aangevallen, maar het aangevallen systeem is niet kwetsbaar voor dit type aanval. De tijd en energie die in IT Security wordt gestoken kan sterk worden verminderd indien dit soort actie / reactie scenario’s in 1 platform plaatsvinden. Daarnaast kan integratie in geval van calamiteiten veel tijdsbesparing opleveren en daarmee van groot belang zijn.

Buiten een geïntegreerde beheeromgeving is belangrijk dat de inspanningen in IT Security volgens een goed gecoördineerd plan verlopen. Juist die coördinatie is vaak moeilijk te realiseren en verdient dus nog aandacht. Het Security & Risk Management (SRM) concept is een breed geaccepteerde beschrijving van hoe IT Security in de praktijk zou moeten verlopen. Door dit concept in praktijk te brengen, kan de gewenste coördinatie worden bereikt.

De 10 stappen van SRM zijn als volgt:

1. Beleid. Allereerst en voordat enige stap gezet kan worden op gebied van IT Security is het bepalen van een beleid. Wat zijn de doelstellingen van IT Security en wie draagt de verantwoordelijkheid? Heel basaal is beveiliging een afweging tussen vrijheid en belemmering. Als de grenzen van de vrijheid onduidelijk zijn, of wie de knoop moet doorhakken in conflictsituaties onbekend is, dan kan nooit een gedegen IT Security worden gerealiseerd. De verantwoordelijkheid en competenties om lijnen uit te zetten ligt bij bestuurders en ook ten behoeve van IT Security zou daar gestart moeten worden. Een goede eerste niet-technische vraag die gesteld kan worden is: bewaken we met IT Security alleen de continuïteit of ook (bepaalde) bedrijfsgevoelige informatie?
2. Inventaris. De vervolgstap is om in kaart te brengen welke systemen in het netwerk voorkomen. Naast het herkennen van het besturingssysteem is daarbij ook belangrijk te weten welke software op een systeem draait aangezien in die software kwetsbaarheden aanwezig zijn die van wezenlijk belang zijn in IT Security. En dat overzicht moet ook regelmatig of zelfs liever continu up-to-date gehouden te worden. Als op een bepaald punt bijvoorbeeld besloten wordt dat anti-virus moet worden uitgerold dan is ten eerste belangrijk: op hoeveel systemen? En wat doen we met de Macintosh systemen? Zonder totaal inzicht in de systemen kan beleid niet aantoonbaar in praktijk worden gebracht en kan dus nooit een bepaald gevoel van veiligheid worden afgegeven.
3. Prioriteiten. Binnen de inventaris dienen prioriteiten aangegeven te worden. Het ene systeem is belangrijker dan het andere, en zal om die reden ook eerder behandeld moeten worden in geval van risico’s of calamiteiten. Welk type systeem belangrijk is, is grotendeels afhankelijk van de bedrijfsdoelstellingen. Al met al voorkomt een duidelijke prioterisering dat bij bijvoorbeeld een virusuitbraak eerst een relatief onbelangrijk werkstation wordt hersteld voordat een storageomgeving aan de beurt is.
4. Kwetsbaarheden. Het kennen van kwetsbaarheden is een doorlopende taak die bij iemand belegd zou moeten worden. Het gaat om kwetsbaarheden in de breedste zin van het woord, dus letterlijk kwetsbaarheden in software waar patches voor uitkomen of zoiets als een onveilig wachtwoord. Het kennen van kwetsbaarheden is één, maar natuurlijk moet ook gedegen onderzocht worden of de systemen in de inventaris deze kwetsbaarheid ook bevatten.
5. Bedreigingen. Een kwetsbaarheid kan in theorie heel kritisch zijn, aangezien het misbruiken ervan bijvoorbeeld direct volledige toegang tot een systeem mogelijk maakt. De vraag of er feitelijk misbruik van gemaakt wordt, bepaald in hoeverre snelle actie vereist is. Een voorbeeld is wanneer een kwetsbaarheid in software bekend wordt gemaakt. Wanneer de fabrikant van de software dat bekend maakt in het uitbrengen van een patch, dan wordt er op dat moment nog niet effectief misbruik van het lek gemaakt. Wanneer een derde partij het lek bekend maakt en de fabrikant nog moet beginnen een patch te ontwikkelen, dan is het speelveld heel anders. Ook de bedreigingen dienen dus bijgehouden te worden.
6. Risico’s. Met kennis van kwetsbaarheden en bedreigingen, en een indeling op prioriteiten van systemen, kan bepaald worden wat het risiconiveau van een organisatie is. Het risiconiveau bepaalt vervolgens hoe snel er in actie gekomen moet worden.
7. Beveiliging. Met kennis van de kwetsbaarheden kan bepaald worden welke beveiligingsstappen gezet moeten worden en op hoeveel systemen. Dit kan een configuratiewijziging inhouden, een update of extra technologie. In het laatste geval is de absolute waarde van de voorgaande stappen dat een gedegen telling gemaakt kan worden voor hoeveel systemen de extra technologie benodigd is, en dus aangeschat moet worden.
8. Afdwingen. Het aanschaffen van beveiliging of bedenken van een configuratiewijziging is 1, maar deze stappen moeten dan ook wel afgedwongen worden. Belangrijk hierin is dan ook, dat er een duidelijk pad is voor het maken van uitzonderingen. Als een bepaald stuk software op een bepaald systeem niet kan of mag draaien, wie geeft dan goedkeuring om voor dat systeem een uitzondering te maken?
9. Evalueren. Na het afdwingen van de beveiliging volgt de evaluatie: hebben de getroffen maatregelen het beoogde effect? Dus is het geconstateerde risico afgevangen? Dit gaat voor een groot gedeelte om rapportage en analyse, maar kan ook betekenen dat een echte test uitgevoerd wordt of de gevonden kwetsbaarheid inderdaad niet meer misbruikt kan worden.
10. Compliancy. Deze laatste stap dient ertoe om aan te tonen dat voldaan wordt aan het gedefinieerde beleid. Niet alleen voor interne doeleinden is dit van belang, maar ook om aan externe auditors te kunnen laten zien.

Al deze stappen kunnen leiden tot het bijsturen van het oorspronkelijke beleid. Daarom wordt SRM altijd weergegeven als een cirkel, wat het cyclische, doorlopend karakter van IT Security weergeeft.