Tag: bottom-up

Beveiliging SharePoint veelal omzeild

  door

Uit onderzoek blijkt dat bijna de helft van SharePoint-gebruikers gevoelige of vertrouwelijke documenten kopieert naar niet beveiligde hard-drives, usb-sticks, of deze zelfs naar een externe mailt. (bron)

Nu kunnen we natuurlijk hele discussies voeren over Sharepoint en hoe veilig we Sharepoint wel of juist niet kunnen maken. Dan komen we al snel op vragen als: wie mag vanuit welke rol bij welke informatie en op welk moment dan? Hoe gaan we ons autorisatiemanagement inrichten en hoe vaak gaan we de rechten van gebruikers controleren.

Allemaal hartstikke belangrijke vragen waarop we nog belangrijkere antwoorden zullen moeten vinden. Maar daarmee zijn we er nog niet. Nee, hier blijkt maar weer eens uit dat we echt niet kunnen zonder een integrale aanpak op basis van risicomanagement.

We moeten dus uitgaan van die risico’s. En natuurlijk kunnen we dan technische risico’s voor Sharepoint benoemen. De kans en de impact van een ongeautoriseerde toegang tot het systeem. Uiteraard moeten we daar maatregelen tegen nemen. Maar hoe zit het nu met die geautoriseerde toegang?

Hoe voorkomen we nu dat medewerkers die geautoriseerd zijn er met onze gegevens vandoor gaan (bewust of onbewust). Het risico is dus naast ongeautoriseerde toegang juist ook de risico’s die je loopt met de informatie. Daar gaat het om. Dus wat is de kans en de impact als onze informatie bijvoorbeeld verloren gaat omdat die bij iemand lokaal op zijn laptop staat?

Maar ook hier kunnen we nog niet stoppen. Die informatie is ondersteunend aan onze bedrijfsprocessen. Daar verdienen we immers ons geld mee. We moeten dus kijken welke informatie van belang is voor de bedrijfsprocessen. We moeten nagaan wat de kans en impact voor het stil vallen van die processen is als gevolg van het verloren gaan van informatie.

Als die informatie echt zo belangrijk is voor de ondersteuning van onze bedrijfsprocessen dan moeten we er dus voor zorgen dat die informatie niet zomaar verloren kan gaan. En als we vervolgens besluiten om die informatie via Sharepoint te delen dan moeten we ook nagaan hoe we ongeautoriseerde toegang gaan voorkomen.

Van een bottom-up benadering naar een top-down benadering dus en in dit geval gebruikten we Sharepoint even als voorbeeld, maar er is meer dan Sharepoint, er is meer dan informatie, er is meer dan bedrijfsprocessen. We komen toch weer terug op de continuïteit van onze organisatie. En alles dat bijdraagt aan die continuïteit moeten we serieus nemen.

Beveiliging: centraal of decentraal

  door

Gisteren hebben we al gezien dat het wiel dat we uitvinden rond is en dat we er daarom ook voor kunnen kiezen om te gaan werken met een basis beveiligingsniveau. Bovenop dat basisniveau implementeren we dan de aanvullende maatregelen die komen uit onze risico analyse (want die doen we, toch?).

Maar als we er dan toch voor kiezen om een aantal maatregelen standaard te implementeren. Dan is de volgende vraag een logisch vervolg:
Is vastgesteld welke beveiligingsmaatregelen centraal en/of decentraal genomen (moeten) zijn?

Gaan we werken vanuit een basisniveau, corporate security framework, beveiligingspolicy of weet ik welke naam er binnen jouw organisatie aan gegeven is, dan kunnen we ook onderscheid gaan maken in de maatregelen die we centraal of juist decentraal moeten nemen.

Een beleidsdocument dat geldt voor de gehele organisatie is logischerwijs natuurlijk al snel een centrale maatregel die we eventueel op lokaal (decentraal) niveau door kunnen vertalen naar de specifieke eisen, wensen, wet- en regelgeving. Stel dat we in het beleid bepalen dat we aan toegangsbeveiliging tot ons gebouw gaan doen, dan kunnen we lokaal kijken of we dat doen met een toegangscontrole systeem op basis van toegangspasjes of dat we er toch liever voor kiezen om een gewapende wacht met een kalashnikov voor de deur te zetten.

Je zult zien dat het abstractieniveau nodig is omdat we niet voor iedere locatie, ieder land, ieder systeem dezelfde maatregel voor kunnen schrijven. Die gewapende wacht met een kalashnikov is in het buitenland misschien heel normaal, maar in Nederland is het niet toegestaan. Daarmee zouden we dus de wet overtreden.

Maar het gaat om meer dan de wet overtreden. We haalden eerder al het voorbeeld aan waarbij we ervoor kozen om te werken met een inlognaam, pincode en toegangspas. Maar kunnen alle systemen daar wel mee over weg? Hebben we niet wat, inmiddels verouderde, systemen staan die met pijn en moeite met inlognaam en wachtwoord werken? Naast de mogelijke overtreding van wetgeving moeten we er dus ook naar kijken wat (technisch) haalbaar is.

Juist daarom is het dus de kunst om het abstractieniveau zodanig te kiezen dat het algemeen toepasbaar is, maar niet zo algemeen dat het niet meer de richting voor beveiliging aangeeft. Hebben we dat gedaan en komen we uit op allerlei standaard maatregelen die we minimaal implementeren dan kunnen we daarbij ook kijken wat we daarvan centraal beleggen en wat we aan de lijnorganisatie over laten.

Laten we teveel in de lijn liggen dan is er weinig uniformiteit en bestaat het risico dat het een allegaartje wordt. Doen we echter teveel op centraal niveau dan zal er in de organisatie weinig betrokkenheid bij het afdekken van risico’s ontstaan. Willen we het goed doen dan moeten we kijken naar de cultuur van de organisatie en kunnen we kijken naar hoe we het op andere vlakken hebben ingericht. Is voor P&O zaken bijvoorbeeld veel belegd op decentraal niveau, dan is dat misschien een goed voorbeeld voor de aanpak van beveiliging.

In de praktijk lijkt het er op dat een top-down benadering van beveiliging veelal wat meer centraal aangestuurd wordt, terwijl een bottom-up benadering juist meer activiteiten in de lijn belegd. Hoe is jouw organisatie ingericht en zegt ons dat al iets over de wijze waarop we beveiliging daarin in kunnen passen? Het advies is om het vooral niet anders in te richten dan de rest van de zaken in de organisatie, beveiliging is al lastig genoeg, dus we zitten niet op allerlei organisatorische afwijkingen te wachten, toch?