Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

Security: de keuze tussen tools en tijd

 

Expert

drs. Jako Boonekamp CISSP
Solution Consultant, Orange Business Services. Expert van voor het topic .

Iedereen weet dat het uitvoeren van een goed securitybeleid een combinatie is van drie factoren: producten, mensen en processen. De vraag is alleen, waar de nadruk op moet liggen en hoe het securitybudget door de chief security officer of chief information officer verdeeld wordt. Er zal een balans gevonden moet worden tussen de drie.

Grote bedrijven worden de laatste tijd steeds meer geconfronteerd met regelgeving en compliance. Fraude zoals bij Enron, Madoff, AOL, Qwest, Arthur Anderson en lokaal Ahold heeft een sterke drang naar meer controle en regelgeving veroorzaakt.

Vanuit de securitywereld uit zich dit in kreten als de Code van Informatiebeveiliging, ISO 27001 (voorheen ISO 17799 / BS 7799), SOx (Sarbanes-Oxley), etc. Bedrijven die genoteerd zijn aan de beurs of actief zijn in de farmaceutische wereld zijn genoodzaakt om dit soort regelgeving te volgen. De aandeelhouders, leveranciers of klanten verlangen dit vanwege transparantie om de risico's te beperken. Sarbanes Oxley schrijft bijvoorbeeld voor (bron Wikipedia: http://nl.wikipedia.org/wiki/Sox):

----------------------
De belangrijkste artikelen zijn artikel 302 en 404.

- Artikel 302 handelt over de controle op de verspreiding van informatie (disclosures). De leiding van een bedrijf dient periodiek te rapporteren over de effectiviteit van de controles op twee niveaus: ontwerp/opzet van controles (design effectiveness) en werking (operating effectiveness).

- Artikel 404 stelt regels voor de interne controle en de financiële rapportering. Het management wordt verplicht om jaarlijks expliciet een uitspraak te doen over de betrouwbaarheid van de interne controles die in het bedrijf gehanteerd worden. De ceo (chief executive officer, algemeen directeur) en de cfo (chief financial officer, financieel directeur) moeten een plechtige verklaring afleggen dat alle controles waterdicht zijn en de auditor (accountant) moet naast zijn gebruikelijke taak op het gebied van de financiële verslaglegging, een expliciete verklaring toevoegen omtrent het akkoord zijn met de uitspraken van de cfo en de ceo.
----------------------

Er dient dus expliciet een uitspraak gedaan te worden over de interne controle. Dit vertaalt zich in het weten wat er allemaal in de ict-organisatie gebeurt. Bedrijven moeten dus over alles logging gaan bijhouden, verzamelen en beoordelen. Bij grote multinationals kan dit een dagtaak worden van meerdere mensen die de logging van duizenden systemen moet bekijken, beoordelen wat voor consequenties alle events hebben (let wel een enkel intrusion prevention-systemen kan bij grote bandbreedte makkelijk duizenden berichten per seconde uitsturen). Door die overvloed aan informatie valt er eigenlijk niet goed te werken aan het bekende adagium Plan-Do-Check-Act (Deming).

Dan komt een security officer met de vraag: Kun je een overzicht maken van hoe de security er binnen ons bedrijf voorstaat?

En kijk niet verbaast als deze vraag maandelijks kan langskomen. Vaak laten bedrijven dit versloffen en hebben geen idee hoe hun security ervoor staat. Of er wordt een syslog-server ingericht om alle logging op één plek te verzamelen. Hoe ga je dan rapportages hierover maken? De securitymarkt heeft deze vraag onderkend en zijn met zogeheten Security Event & Incident Management-oplossingen gekomen. Vaak met vooringerichte templates voor ISO 27001 en SOx. Het is dan makkelijk om een rapportage te maken. Deze oplossingen richten zich op correlatie van events (meerdere losse gebeurtenissen hoeven niets te betekenen, maar gecombineerd zou te zien zijn dat een hacker bezig is), incidentmanagement, classificatie en rapportage. Bedenk ook dat er nagedacht moet worden over hoe lang deze logs bewaard moeten worden, danwel uit het oogpunt van regelgeving of forensisch activiteiten. Let er wel op dat de oplossing die gekozen wordt alle devices ondersteund. Veelal is op de website van de fabrikant een supported device list te zien, waar de eigen componenten hiermee vergeleken kunnen worden.

De business case voor dit oplossingen is vrij eenvoudig gemaakt. Kijk hoeveel mensen er in de security-organisatie rondlopen en hoeveel tijd ze kwijt zijn aan dit soort taken. De tijd die ze besparen kan gebruikt worden als investering voor dit soort oplossingen. Gezien het continue tekort aan goede securityprofessionals kan dit tevens kosten aan externe security-experts besparen.

Bedrijven kunnen er ook voor kiezen om securitycomponenten uit te besteden aan een service provider en te vragen om dit soort taken voor zich te verzorgen. Kies hierbij uit co-managed of volledig gemanaged. Bedrijven krijgen dan een portal waar ze zelf dit soort rapportages kunnen maken over hun eigen omgeving.

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/2950730). © Jaarbeurs IT Media.

?


Lees meer over


 

Reacties

Interne controle kan plaatsvinden op diverse niveau's in de ICT-infrastructuur, zoals:
- toegang tot informatie (applicatie logging)
- toegang tot systemen (server logging)
- toegang tot netwerken (netwerk logging)

De wet- en regelgeving in het kader van informatiebeveiliging heeft als doel om informatie en de toegang tot informatie veilig te stellen.
Feitelijk gaat het dus om vertrouwelijke informatie. En de controle hierop.

Naar mijn mening, zijn we soms doorgeschoten in het monitoren en loggen van allerlei activiteiten op systemen en netwerken. Vele organisaties hebben nog Internet proxy-servers, waarop duizenden regels logging worden bijgehouden.
Om te kunnen loggen welke medewerker welke Internet-site heeft bezogd. Dat is toch niet meer van deze tijd? Met prive breedband Internet, PDA's met Internet, mobieltjes met Internet?

Routers, firewalls, intrusion prevention systemen: ze hoesten dagelijks vele miljoenen regels logging. Vaak niet leesbaar. Of met onzinnige informatie, waar niemand iets aan heeft.

Maar wie vraagt zich af: waarom doen we dit eigenlijk? Wie heeft hier eigenlijk om gevraagd?
Als we dan vervolgens intern in de organisatie naar de bron van deze vraag zoeken, komen we vaak op een dood spoor. Niemand weet eigenlijk nog, wie erom gevraagd heeft en waarom we het doen.
"We doen het, omdat we het altijd al zo doen".
Uitbesteden! is een vaak gehoorde oplossing. Maar als we zelf niet in staat zijn om onze eigen vraag te definieren, hoe moet in hemelsnaam de provider de juiste logging op kunnen leveren?

Mijn mening: stop onmiddelijk met al dat loggen op netwerk en server niveau. Zorg voor effectieve logging in de applicatie en/of database.


De kunst is om security management zo in de organisatie te implementeren dat de business er weinig tot geen hinder van ondervindt. Uiteraard zal het altijd merkbaar zijn omdat personen zich nu eenmaal moeten bewegen binnen de kaders die wet en regelgeving opleggen maar door het begrijpelijk te maken en door de medewerker bewust te maken van zijn of haar rol in security kun die regels als een vanzelfsprekend iets in het dagelijks functioneren worden. Alle technische maatregelen ten spijt, logging / monitoring, analyses van applicaties en systemen, de mens blijft de sleutel in het security proces. Uitgangspunt bij het opzetten en invoeren van een beleid of architectuur moet dan ook de medewerker en het bedrijfsproces zijn, dan komen de weten, regels en de techniek vanzelf aan de orde. Technische security en tooling zijn wel noodzakelijk maar mogen nooit leidend worden. Als dit wel het geval is bestaat het risico dat security wordt gezien als een beperkende factor en niet als een kans om de business robuuster en sterker te maken.

Alvorens een CSO/CIO moet gaan denken aan hoe hij het budget verdeelt over mensen, middelen, en processen moet hij eerst een stapje terug doen en kijken waarom hij een security budget heeft. In principe zijn er een aantal ?business drivers? zoals regelgeving, dreiging, eisen vanuit de markt, maar ook kansen om je marktpositie te versterken. Afhankelijk van het bedrijf zal de ene ?driver? belangrijker zijn dan de andere. Maar een gezond bedrijf moet dit blijven evalueren en op basis hiervan ook het security budget beoordelen. Het herverdelen van een security budget op basis van mensen, middelen, en processen levert geen sluitend security systeem. Het risico waar tegen beveiligd moet worden bepaald in hoge mate de keuze voor een bepaalde beveiligingsstrategie. Deels is daarbij technologie nodig (de middelen), en een ander deel zal door operationele taken moeten worden afgedekt (de mensen en processen). Een herverdeling (of balanceren) van een budget lijkt mij alleen leiden tot gaten in de security. De balans tussen de drie genoemde factoren bestaat volgens mij niet. Wil je een bepaald veiligheidsniveau handhaven dan zijn kostenbesparingen op een van de factoren alleen mogelijk als de andere factoren het ontstane beveiligingsgat vullen, of als een van de factoren aan beveiligingskracht wint bij gelijke of lagere kosten. In de praktijk lukt dit laatste zelden waardoor beveiligingsbudgetten stijgen. Vervolgens ontstaat er een onbalans tussen de business drivers en de kosten waardoor het budget gelimiteerd wordt en men pragmatisch het beschikbare geld gaat herverdelen op basis van de prioriteit van de dag. Ik denk dat dit niet gaat leiden tot een oplossing die het gewenste niveau van beveiliging biedt binnen organisaties die traditioneel goed op de justificatie van uitgaven hebben gelet.

Ik ben het eens met Jako Boonekamp dat bij het opstellen en uitvoeren van securitybeleid er altijd een balans gevonden moet worden tussen de factoren producten, mensen en processen. Ik zou er echter een element aan toe willen voegen en dat is het documentformaat zelf. Veel aandacht bij beveiliging gaat uit naar het beveiligen van de infrastructuur. Dit werkt ook prima voor de veiligheid van documenten binnen de eigen organisatie (lakse, domme of malafide werknemers daargelaten) maar daarmee heb je nog steeds geen grip op de ?boze buitenwereld?. Met andere woorden, documentbeveiliging op infrastructuurniveau is niet persistent buiten de eigen infrastructuur. Toch zullen veel documenten vroeg of laat die veilige thuishaven moeten verlaten, en wat dan?

Een plausibele aanpak is om gegevens op te slaan en te versturen in een goed beveiligde en applicatieonafhankelijke 'container', zodat er voor alle gegevens slechts ??n beveiligingsmethode vereist is. Een voorbeeld van zo'n container is de nieuwste versie van PDF, een open bestandsformaat dat audio, video (Flash) en tekst kan bevateen en naast wachtwoorden ook digitale handtekeningen en gepersonaliseerde autorisatie ondersteunt. Daarmee is het niet alleen mogelijk om de toegang tot informatie te koppelen aan iemands digitale identiteit, die ttp's (trusted third party) moeten verifi?ren op basis van bijvoorbeeld een hardwaretoken, maar ook om elke geautoriseerde gebruiker verschillende lees-, schrijf- en printrechten te geven.

Op dezelfe applicatie- en platformonafhankelijke PDF container valt ook te werken met DRM. DRM is technologie waarmee bepaald kan worden wie, wat, wanneer met een document kan doen. De oplossing is charmant vanwege zijn eenvoudigheid. Op serverniveau wordt het beleid van een document ingesteld, bijvoorbeeld hoelang het document geopend kan worden en door wie, welke wijzingen er wel of niet zijn toegestaan en of er wel of niet geprint mag worden. Bij het openen van een dergelijke PDF wordt altijd verbinding gezocht met de server, deze controleert de rechten die zijn toegekend en handelt daar vervolgens naar. Stel dat een dergelijk document onbedoeld op straat komt te liggen. Er is in dat geval niets aan de hand omdat alle rechten in dat geval op serverniveau worden ingetrokken waardoor het document domweg niet meer te openen is. Deze technologie is breed toepasbaar, bijvoorbeeld voor de bescherming van intellectueel eigendom en zeker ook voor het beschermen van uiterst gevoelige informatie.

Uit de reacties lees ik dat velen inhoudelijk in het security beleid en uitvoering zijn gedoken in plaats van de daadwerkelijke strekking van het verhaal van Jako. Zelf lees ik dat Jako wil benadrukken om een afweging te maken tussen de tijd die men kwijt is om handmatig logs te bekijken van verschillende systemen of een investering te doen in een tool. De titel luid daarom ook de keuze tussen tools en tijd.

De tijd die men dagelijks kwijt is aan het handmatig bekijken van de logging door de systeembeheerders en de individule rapportage kan je omzetten in geld. Het bedrag wat daaruit komt is het budget voor een tool en dat is dan snel terug verdiend want het is eigenlijk onmogelijk om dit handmatig uit te voeren. Alle logs bekijken voor incidenten in een bepaalde tijdsperiode en daar conclusies uittrekken en dan nog een rapport hierover maken.

Hier is de kosten/baten analyse van toepassing.

De tool(Security Event en Incident Management Systeem) verwerkt al deze logs en genereert hieruit rapportages om te laten zien wat voor incidenten er uiteindelijk zijn geweest om een compleet overzicht te hebben waar en of er een incident heeft voorgedaan. Aan de hand van de rapportage kan je inzoomen op de incidenten en de oorzaken en daarop je maatregelen nemen. Uiteraard is het belangrijk om de juiste logging toe te passen en niet loggen om te loggen.

Deze rapportage kan dan gebruikt worden voor compliance doeleinden zoals PCI en de beschreven SOX.

Rapportage is belangrijk omdat het een meet gegeven is. Vroeger op school werd al gezegd "meten is weten" en dat geld hier ook bij. Als je niet meet weet je uberhaupt niet of de investeringen in security producten of processen valide zijn geweest en efficient. Wat weer te herleiden is in de Plan Do Act Cycle van de ISO27001 norm.

Dan komt de balans in het security beleid terug. Securitybeleid is een toepassing op combinatie van de genoemende elementen van processen, produkten en mensen plus de daarbij behorende investering en het verlies als je het beleid niet uitvoert. Het is niet de verdeling van het budget over deze elementen.

Al met al security is en staat met risico's en de acceptatie van risico's.

Jako heeft de focus op Events die gegenereerd worden door een veelheid van systemen. En terecht merkt Jako op dat het een ondoenlijke zaak is om dit manueel te verwerken, de balans ligt dan niet goed.

Er zijn een punten die ik wil aanvullen.
- Systemen: welke systemen vallen binnen het blikveld? Colin noemt terecht E-DRM zoals met PDF en RMS. Maar ook events uit de fysieke beveiliging en de fysieke infrastructuur kunnen als onderdeel van een analyse of forensics rond informatiemisbruik erg belangrijk zijn.
- Aantallen: Als we over grote aantallen spreken denk ik dat we niveau te laag zitten. Ik wil tenslotte ook niet elke retry horen die mijn TCP/IP connectie doet, ik wil weten of ik beschik over een betrouwbare verbinding. Dat is een verschil van duizenden events of 1 gekleurd bolletje.
- Automatische Acties: We doen de rapportage primair om onze omgeving veiliger te maken, daarom is de "act" stap cruciaal. Dat zou een ge?ntegreerd proceselement moeten zijn, zo mogelijk geautomatiseerd. Dat voorkomt niet alleen werk maar maakt de omgeving veel veiliger want het voorkomt vooral een veelheid van nieuwe security incidenten.

IT Security 2.0 moet een oplossing zijn die niet alleen automatisch events van verschillende securitycomponenten correleert maar ook toegang heeft tot aanvullende informatie vanuit het betreffende platform en het recht heeft om preventieve en corrigerende acties te ondernemen en componenten aan te sturen. Die nieuwe generatie is vanzelfsprekend ook in staat om een gecorreleerde rapportage te doen over alle componenten heen en inderdaad in staat doorlopend antwoord kunnen geven op de vraag ?hoe staat het met de veiligheid van onze infrastructuur?.

Zo?n oplossing zou natuurlijk goed ge?ntegreerd moeten zijn met het platform zelf maar tegelijkertijd breed open moeten staan voor elke partij die aan wil haken om events te rapporteren maar ook om informatie in te winnen zodat elk component een bredere kijk krijgt en er slimmer van wordt.

Van alle de fraudegevallen wordt 75% door interne medewerkers gepleegd, dus het aspect ?mensen? moet vaak zeer sterk gerelateerd worden aan de medewerkers van het bedrijf. Zij ervaren de opgelegde security?protocollen als hinderlijk en werken er omheen. Security-beleid kan echter wel worden afgedwongen met inzet van technologie, op voorwaarde dat deze technologie procesverbeteringen aanbrengt ?n draagvlak cre?ert vanuit de werknemers. Voorbeeld hiervan is de implementatie van strong authentication in combinatie met single sign-on. Gebruikers hoeven niet langer verschillende wachtwoorden uit hun hoofd te kennen, maar zijn wel verplicht om zich aan te melden met een pasje of via biometrie.

Voordat je bij de keuze tussen tools en tijd komt, dien je eerst een andere essenti?le stap te nemen. Bepaal vooraf wat je zelf wilt weten over je eigen bedrijfsvoering en wat je moet weten om te voldoen aan regels. Te veel bedrijven maken hier geen duidelijke keuze en zetten automatisering in om een overvloed aan informatie te verzamelen. Twee zaken moeten duidelijk eerst geregeld zijn:

Slechts een klein deel van de bedrijfsinformatie is werkelijk belangrijk voor het bedrijf. Denk aan 5% tot 15% van de data. Hier dienen de controles op gericht te worden. Als we deze informatie kunnen isoleren, worden controles eenvoudiger. Goed beleid heeft dus informatieclassificatie ingevuld binnen het bedrijf, wat dan ook toegepast moet worden. Die toepassing vergt architecturale beslissingen over de inrichting van je processen en automatisering. Door dit goed te regelen maak je controles effici?nter.

Om vanuit meetresultaten te kunnen komen tot een goede afrekening bij de bedrijfstop (CEO en CFO), dient de organisatie van verantwoordelijkheden ook duidelijk belegd te zijn. Wie is verantwoordelijk voor wat? Als beveiligers vinden we het vooral interessant hoe de organisatie van security belegd is. Waar is de CISO voor verantwoordelijk, waar zijn de lijnmanagers voor verantwoordelijk, waar is IT voor verantwoordelijk? Door dit goed te regelen maak je de controles effectiever.

Daarna kun je effectief kijken waar en wat er gemeten moet worden en of het loont een SIEM applicatie in te zetten. In een redelijk groot bedrijf kan dan inderdaad vaak al snel geconcludeerd worden dat de kosten van het product wegvallen tegen de besparingen die het oplevert in tijd.

Onderdeel hiervan is ook het afwegen van de kosten van risico's ten opzichte van de kosten die gemaakt moeten worden om risico's te beheersen. Deze afweging wordt bemoeilijkt doordat de kosten die gemoeid zijn met het beheersen van risico's vaak eenvoudiger zijn te kwantificeren (denk hierbij aan investeringen in hard- en software en de ondersteunende operationele processen), maar de bedrijfsrisico's vaak minder eenvoudig (denk aan reputatieschade). Echter, als deze wel (zo goed mogelijk) zijn gekwantificeerd, kan een veel betere keuze worden gemaakt tussen de maatregelen die genomen zouden kunnen worden om deze risico?s te elimineren of te reduceren. Het zou dan heel goed kunnen blijken dat het veel effectiever is om (eerst) in te investeren in preventieve maatregelen dan meer reactieve (als bijvoorbeeld een SIEM oplossing), of juist eerst te investeren in het optimaliseren van de achterliggende (operationele) processen.

Ik ben het volledig eens met Jako. Indien je een tool kunt inzetten waarmee je in principe elke audit vraagstelling van een security officer direct met een real-time en online rapportage kunt beantwoorden, kun je veel tijd en ergernis besparen.
Ook een real-time bewaking van je security policy en een escalatie van security incidenten is een must bij bedrijven die te maken met security compliancy.

Ik vraag me echter wel af hoeveel security en/of IT medewerkers bij bedrijven die aan bepaalde wet- of regelgevingen moeten voldoen hier nu daadwerkelijk mee bezig zijn. Naar mijn idee wordt er wel over gesproken, maar zijn er maar weinigen die ook echt actie ondernemen. Heeft dat te maken met de lage of zelfs geen sancties als niet aan een bepaalde security rapportage kan worden voldaan? Of neemt men de tijd die een paar keer per jaar moet worden genomen om de gewenste audit rapportages samen te stellen dan maar gewoon voor lief?

Hoe dan ook ben ik van mening dat een dergelijk security & incident management oplossing alleen interessant is als je vanuit de security management oplossing direct de bewaking, rapportage en escalatie van de kritische bedrijfsprocessen kunt koppelen. Dan kun je namelijk ook meteen duidelijk maken welke business impact een security incident heeft of kan hebben. Dan ook krijgt een dergelijke tool meteen een veel hogere waarde voor een bedrijf. De ROI wordt korter en de visualibility naar de organisatie en directie wordt meteen een stuk duidelijker.

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×