Security architectuur Lean & Mean

Op het gebied van structureel omgaan met informatie in organisaties zijn de afgelopen jaren veel ontwikkelingen geweest op technisch en organisatorisch terrein. Deze ontwikkelingen hebben voor een deel te maken gehad met het benaderen van informatieverwerking op een hoger abstractieniveau. Daarbij bleek de vertaling van businessdoelen naar verwerkingsstructuur lastig te zijn, omdat beide begrippen uit verschillende werelden afkomstig zijn. Architectuur is het verzamelbegrip voor de interface tussen die werelden. Daarin wordt zichtbaar gemaakt hoe de eisen van de ene kant omgezet worden in functies aan de andere kant.

Wat is security (informatiebeveiliging)?

Security is een breed begrip, dat varieert van fysieke toegangsbeveiliging tot en met het beschermen van websites tegen hackers. Soms komt het zelfs in contact met safety, waarmee persoonlijke beveiliging bedoeld wordt. In dit artikel beperken we ons tot de bescherming van informatie en informatieverwerking. Omdat informatie een drager nodig heeft om bruikbaar te zijn, wordt die in dit geheel meegenomen, of dat nu papier, computergeheugen of het netwerk is.

Iedere organisatie gebruikt informatie. Zonder die informatie kunnen organisaties niet werken. Het is dan ook noodzakelijk ervoor te zorgen dat die informatie juist is en op tijd beschikbaar is. Soms is het daarbij van belang de informatie te beschermen tegen ongeoorloofd gebruik. Dat bij elkaar betekent dat er eisen gesteld worden aan de informatie, de media en de verwerking van de informatie. Daarna kunnen die eisen geïmplementeerd worden in informatiebeveiligingsmaatregelen.

De verzameling van informatiebeveiligingsmaatregelen vormt security. Om daarmee voldoende ‘veiligheid’ te creëren, gebruikt men een managementsysteem (Information Security Management Systeem) zoals dat bijvoorbeeld in ISO standaarden en ITIL documenten beschreven is¹. Dit managementsysteem stelt de organisatie in staat om security op maat te krijgen en te houden bij veranderende interne of externe omstandigheden.

Wat is een security architectuur?

Een veelvuldig gebruikte definitie voor security architectuur luidt als volgt:

Een Security Architectuur is een voorschrijvend document dat door middel van een set samenhangende modellen en principes efficiënt en flexibel richting geeft aan de invulling van het informatiebeveiligingsbeleid van een organisatie.²

Een security architectuur bestaat dus uit een samenhangend overzicht van modellen, principes, uitgangspunten en condities waarmee een concretere invulling wordt gegeven aan het (informatie)beveiligingsbeleid. Een security architectuur gaat echter niet over de concrete oplossingen.

Een architectuur toont namelijk de realisatie van de eisen op een hoger abstractieniveau. Niet alle details zijn daarbij ingevuld, zodat het mogelijk is om een overzicht te vormen van de realisatie. Het is een oplossing op hoofdlijnen aan de hand waarvan zichtbaar is dat aan de eisen van de opdracht is voldaan. Dit is het primaire doel van het gebruik van architecturen.

Door weg te blijven van realisatiedetails ontstaan twee fundamentele mogelijkheden die de voornaamste reden vormen om iets met architectuur te willen doen:

• Vrijheid - omdat de realisatiemethode niet vastligt, bestaat de mogelijkheid om de realisatie te blijven optimaliseren. Het is nog mogelijk om op elk gewenst moment bij de realisatie een keuze te maken voor concrete oplossingen en producten die het meest geschikt zijn.
• Flexibiliteit - door de oplossing op hoofdlijnen te beschrijven blijft het mogelijk, zonder last te hebben van implementatiedetails, snel een wijziging in de eisen te vertalen naar de oplossing.

Een security architectuur reduceert net als een “gewone” architectuur een complex probleem tot te bevatten modellen, principes, richtlijnen en deelproblemen. Hierbij wordt doorgaans gezocht naar antwoorden op de vragen: wat, waar, wanneer, hoe, waarmee en door wie. De modellen, principes en richtlijnen geven aan waar je welk type beveiligingsmaatregelen neemt, wanneer de principes van toepassing zijn en hoe ze samenhangen met andere principes.

De scope van een security architectuur ligt niet vast en kan sterk afhankelijk zijn van het doel of het probleem dat opgelost moet worden. Een scoping issue kan zijn; welke kwaliteitsaspecten van informatiebeveiliging neem ik mee? Vertrouwelijk en integriteit of hoort beschikbaarheid daar ook bij? Daarnaast is het onderwerp beveiligingsniveau of rubriceringniveau ook van belang; gaat het om interne vertrouwelijke informatie of is er ook hoog gerubriceerde informatie van bijvoorbeeld het niveau ‘staatsgeheim confidentieel’ of ‘staatsgeheim zeer geheim’.

Beveiliging van zeer geheime militaire informatie kan voor een defensie organisatie relevant zijn, maar voor een industriële omgeving totaal niet. En de ene organisatie kan zich beperken tot algemene richtlijnen voor informatiebeveiliging met ruime vrijheid om dit in te vullen, terwijl een andere organisatie de keuze van informatiebeveiligingsmaatregelen in veel meer detail wil vastleggen. In veel gevallen ligt de focus op een verbijzondering van die eisen uit het informatiebeveiligingsbeleid die op een of andere manier in de ICT omgeving of de bijbehorende organisatie en processen geïmplementeerd moeten worden.

Wat is een security architectuur niet

Een security architectuur zegt niets over de oplossingsmiddelen, of de te gebruiken producten of af te nemen beveiligingsdiensten van derde partijen. Het definieert wat er op het gebied van informatiebeveiliging moet gebeuren, en geeft richtlijnen op de wijze waarop het moet gebeuren. De invulling, het hoe, is de verantwoordelijkheid van een realisatieproject en dikwijls van productmanagers van producten in organisaties.

De businesscase voor security (architectuur)

In de ICT is men bekend met het opstellen van business cases voor met name de operationele en investeringsuitgaven vanuit beheer en projecten gezien. Dit zijn de kwantitatieve elementen van de businesscase. De businesscase voor security ligt doorgaans op de kwalitatieve elementen. Deze elementen zijn:

• Het voldoen aan wet- en regelgeving / compliancy.
• Risicomanagement - het beheersen van de businessrisico’s, het definiëren van een risk appetite en het inrichten van het risicomanagement proces.
• Sneller en met minder inspanning realiseren van nieuwe diensten. Flexibiliteit en time-to-market van nieuwe producten en diensten wordt steeds belangrijker en kan businessvoordelen opleveren.
• Beperking van kapitaalvernietiging door onevenwichtige en incompatibele maatregelen. Een onbalans van maatregelen kan veel kosten tot gevolg hebben en toch onvoldoende veiligheid bieden.
• Realiseren van een meer uniform en beter aantoonbaar niveau van beveiliging.
• Voorkomen van imagoschade als gevolg van problemen met informatie of informatieverwerking.

Voor een security architectuur kunnen daar de volgende elementen aan toegevoegd worden:

• Inzichtelijk maken hoe business eisen ten aanzien van beveiliging, zoals risicomanagement en compliancy worden doorvertaald naar maatregelen.
• Inzicht geven hoe informatiebeveiliging in samenhang gerealiseerd kan worden.
• Een sturingselement voor de daadwerkelijke realisatie van informatiebeveiliging doordat een security architectuur een roadmap bevat van de wijze waarop en in welke volgorde aan de beveiligingsdoelstellingen uit het informatiebeveiligingsbeleid voldaan kan worden.
• De architectuur bevat richtlijnen om te voorkomen dat security puntoplossingen ontstaan die lastig te beheren zijn.
• Een communicatiemiddel om aan derde (auditors) aan te geven hoe de organisatie het “in-control” realiseert.

Stakeholders voor security architectuur

In architectuur worden stakeholders (belanghebbenden) onderkend waarvoor de architectuur een antwoord geeft op hun vragen. Voor een security architectuur is dit eveneens zo. Voor security worden onder andere de volgende primaire doelgroepen van stakeholders onderkend:

• Business managers - zij financieren de beveiliging, stellen de eisen en kunnen uit de architectuur op hoofdlijnen opmaken hoe hun business informatie wordt beveiligd. Door gestructureerd te werken volgens een security architectuur kunnen zij beter verantwoorden dat zij stelselmatig werken aan een goede bescherming van bedrijfsinformatie en informatieverwerkende systemen.
• (ICT) Architecten - zij hebben de security principes nodig om de juiste bouwstenen op de juiste plaats te kunnen definiëren met high-level security eisen.
• Ontwerpers - zij hebben de security principes nodig om bouwstenen en services te ontwerpen volgens deze principes in de context van de security architectuur.
• Security specialisten - zij gebruiken de architectuur om de organisatie consistent te adviseren over security eisen waar services en systemen aan moeten voldoen.

Een secundaire doelgroep is:

• Auditors - zij kunnen de architectuur gebruiken als toetsingsinstrument tijdens hun controles.

Relatie met andere soorten architecturen

Een enterprise architectuur kent vaak een indeling in deelarchitecturen zoals de bedrijfs(business)-, informatie-, applicatie- en technische architectuur (zie figuur 1). Naast deze (deel)architecturen kent de enterprise architectuur ook dikwijls een indeling die gebaseerd is op een lagenmodel bestaande uit een conceptuele laag (met daarin de business context), een logische laag en een fysieke laag. De conceptuele laag zegt wat er moet gebeuren, de logische laag vertelt hoe het moet gebeuren en in de fysieke laag wordt aangegeven waarmee dit moet gebeuren. Door het onderkennen van deze (deel)architecturen of lagen kan voor ieder gebied getoond worden hoe de invulling van de eisen eruit ziet. In elk van deze (deel)architecturen of lagen bevinden zich elementen die een relatie hebben met informatiebeveiliging en / of risicomanagement.

Figuur 1: (deel)architecturen en lagen

In de praktijk wordt security nog veelvuldig los van andere architecturen of lagen ontwikkeld. Bij die aanpak ontstaat een separate security architectuur die het volledige speelveld van security in een oogopslag definieert. Het voordeel hiervan is een security view over het geheel. Een nadeel hiervan is het feit dat de security los van andere business ontwikkelingen tot stand komt en de integratie met andere architecturen of lagen nu niet geborgd is. Het verdient voorkeur om geen losse security architectuur te ontwikkelen, maar security als onderdeel van de andere architecturen of lagen te ontwikkelen waarbij het totaal overzicht middels een view te realiseren is. Dit totaal overzicht kan dan de security architectuur genoemd worden.

In dit artikel zal de indeling in lagen gehanteerd worden om de security architectuur toe te lichten.

De business(context) laag

De business(context) laag beschrijft de basis aannames, uitgangspunten en overtuigingen die afgeleid zijn van de organisatie doelstelling en missie, waarden en normen en (besturing) governance principes van de organisatie. Daarnaast beschrijft het op hoofdlijnen de organisatie specifieke business principes, business kansen, compliance-eisen, de geldende wet- en regelgeving en bedreigingen die voor de specifieke business onderkend worden. Dreigingen variëren sterk afhankelijk van de locatie of zone waar informatie verwerkt wordt, de aard van de business en de waarde van de informatie. Daarom is het nodig dreigingen specifiek te maken voor bepaalde omgevingen en voor de verschillende soorten business processen die een organisatie heeft.

De inhoud van de business(context) laag heeft een sterke relatie met het informatiebeveiligingsbeleid. Het informatiebeveiligingsbeleid wordt immers als uitgangspunt overgenomen in de security architectuur. Dit beleid is gebaseerd op de geldende wet- en regelgeving waaraan de organisatie moet voldoen.

De security architectuur geeft een gestructureerde invulling van dat beleid. Indien tijdens het opstellen van de security architectuur blijkt dat beleidsuitspraken ontbreken, waardoor er geen goede invulling kan worden gemaakt in de architectuur, dan is het beter deze beleidsuitspraken niet in de architectuur vast te leggen, maar alsnog aan het informatiebeveiligingsbeleid toe te voegen of deze als voorlopige aannames in de architectuur expliciet te beschrijven.

De conceptuele laag

Op basis van de in het beleid gedefinieerde informatie en waardeobject classificatie beschrijft deze laag modellen en concepten met informatiestructuren, -stromen en -objecten. Per classificatie worden de security principes en beveiligingsnormen voor deze informatie aangegeven. Het beveiligingsniveau bepaalt de maatregelen die getroffen moeten worden. Een beveiligingsniveau bestaat uit een combinatie van de aspecten: vertrouwelijkheid, integriteit en beschikbaarheid. Deze aspecten kunnen als volgt omschreven worden:

• Vertrouwelijkheid - De mate waarin de toegang tot gegevens of functionaliteit beperkt is tot diegenen die daartoe bevoegd zijn.
• Integriteit - De mate waarin gegevens of functionaliteit juist ingevuld zijn.
• Beschikbaarheid - De mate waarin gegevens of functionaliteit op de juiste momenten beschikbaar zijn voor gebruikers.

In onderstaand kader wordt een voorbeeld gegeven van een beveiligingsniveau gebaseerd op verschillende aspectgebieden.

 

Beveiligingsniveau aspecten

 

 

In bovenstaande figuur is een voorbeeld gegeven van een beveiligingsniveau gebaseerd op verschillende aspectgebieden.

 

Beschikbaarheid wordt vaak uitgedrukt in percentages per tijdsinterval. Zo is in dit voorbeeld BASIS24 gedefinieerd als werkdagen van 08:00-18:00 uur met een beschikbaarheid van bijvoorbeeld 99,5 %.

 

Vertrouwelijkheid wordt uitgedrukt op basis van een classificatie of rubriceringregeling. In dit voorbeeld is het VIR-BI Voorschrift Informatie beveiliging - Bijzondere Informatie met rubriceringniveaus als departementaal vertrouwelijk, staatsgeheim etc. in combinatie met interne en openbare informatie gebruikt.

 

De wet bescherming persoonsgegevens (wbp) in dit voorbeeld hanteert risicoklassen voor het beveiligen van informatie. Deze indeling is in feite het treffen van maatregelen voor vertrouwelijkheid en integriteit.

 

De architectuur kan verschillende beveiligingsniveaus ondersteunen. Met de indeling naar verschillende beveiligingsbehoefte van informatie vindt op hoofdlijnen een eerste schifting plaats van de maatregelen die nodig zijn voor adequate beveiliging.

De logische laag

Binnen de architectuur beschrijft de logische laag op een gestructureerde manier de controls die nodig zijn voor verschillende aspectgebieden. Aangegeven moet worden welke controls nodig zijn, waar welke controls ingezet moeten worden, onder welke condities, wie verantwoordelijk is voor beheer van de controls etc. Het is wenselijk de security controls daarbij te groeperen naar beveiligingsfuncties. Voorbeelden van deze beveiligingsfuncties zijn:

• Identificatie en authenticatie - Voorzien in het vaststellen van de identiteit van personen of systemen.
• Autorisatie - Voorzien in de toekenning van bevoegdheden aan personen of systemen.
• Isolatie - Voorzien in de afscherming van groepen gegevens, systemen en/of gebruikers van andere groepen van gegevens, systemen en/of gebruikers. Voorzien ook in het creëren van een gesloten werkomgeving voor gebruikers en beheerders en het optimaal (beveiligingstechnisch) configureren van systemen.
• Beveiliging transport en opslag - Voorzien gegevens van beveiliging tijdens transport en opslag door middel van de toepassing van cryptografische technieken.
• Bewijs en bewaar - Voorzien in onweerlegbaarheid van digitale handelingen, de archivering van digitale gegevensbestanden, functies ter waarborging van de integriteit van digitale handelingen en digitale bestanden.
• Inbraakpreventie- en detectie - Voorzien in de preventie en detectie van ongeautoriseerde toegangspogingen.

De logische laag specificeert niet welke technische middelen nodig zijn, maar wel waar ze functioneel en kwalitatief aan moeten voldoen. Bijvoorbeeld: Zo wordt beschreven wanneer sterke authenticatie nodig is, waarbij zowel kennis als een vorm van bezit wordt vereist, en wanneer zwakke authenticatie voldoende is, waarbij alleen kennis wordt vereist. Met welke technische middelen sterke authenticatie moet worden gerealiseerd wordt hierbij niet vastgelegd. Dit is iets voor de fysieke laag.

Bij het maken van afwegingen om te komen tot de invulling van de beveiligingsfuncties, dienen zaken als gebruiksgemak meegenomen te worden. Het is immers niet erg handig om een brandweerman die met dikke handschoenen werkt een PDA met inlogcodes te geven.

De beveiliging in de logische laag zal iets van de eigen organisatie vergen maar ook van de gebruikers en de partners waarmee samengewerkt wordt. De logische laag dient dit expliciet aan te geven.

De fysieke laag

Soms zijn er redenen om ook de implementatie van logische functies specifieker te definiëren uit oogpunt van bijvoorbeeld kostenbesparing door standaardisatie of vereiste interoperabiliteit. Zo kan het zijn dat een organisatie een speciale keuze van sterke authenticatie consequent wil doorvoeren of specifiek vereist dat uitsluitend bepaalde goedgekeurde versleutelalgoritmes gebruikt moeten worden. Dit zijn zaken die in deze lagen beschreven kunnen worden. Risico van te veel diepgang en detail in een security architectuur is dat het als een bureaucratische hindernis ervaren kan worden en niet als nuttig hulpmiddel. Naarmate een architectuur gedetailleerder en omvangrijker is, wordt de kans groter dat gebruikers niet de tijd hebben of de motivatie hebben de belangrijke aspecten hiervan tot zich te nemen. Ook dienen veranderingen in technologische mogelijkheden dan regelmatig bekeken te worden op hun impact voor de security architectuur.

In het artikel ‘informatiebeveiliging bouwen onder architectuur’³ is een voorbeeld beschreven vanuit de praktijk bij het opstellen van een ICT beveiligingsarchitectuur in de veiligheidssector.

Security principes

Architecten zijn gewend om met principes te werken, voor security geldt dit ook. De vraag die opkomt is: zijn security principes anders dan de “gewone”architectuurprincipes? Met de inzet van ICT om de strategische doelen te behalen, komen specifieke concerns over bijvoorbeeld de vertrouwelijkheid van de informatie aan bod. Deze concerns vragen om principes die dit adresseren. De rol en plek van security principes in de security architectuur is gelijk aan die van principes in de enterprise architectuur, alleen de concerns die ze adresseren zijn anders. Een enterprise architectuur is niet compleet zonder de security te adresseren. Met de ontwikkeling van het security vakgebied zijn algemeen bruikbare principes, patronen en controls verzameld en gedocumenteerd⁴.

Het abstractieniveau hiervan is erg verschillend, waardoor ordening noodzakelijk is. Er zijn diverse manieren om ordening aan te brengen. Voorbeelden van principes zijn weergegeven in de General Accepted Information Security Principles (GAISP)⁵. GAISP kent een indeling op drie niveaus:

• Pervasive principles (PP’s) of fundamentele principes zijn gericht op beheersing van de organisatie en geven richtlijnen op strategisch niveau.
• Broad functional principles (BFP’s) zijn meer gedetailleerd en definiëren aanbevolen tactieken vanuit het perspectief van management.
• Detailed security principles (DSP’s) leveren specifieke en gedetailleerde aanpakken, geschreven voor de security en audit professionals en gericht op operationele beveiliging en risicomanagement.

Maatregelen worden bepaald aan de hand van concerns en principes. De relatie hiertussen is weergegeven in figuur 2.

Figuur 2: Van concerns naar maatregelen

Ontwikkelproces van de security architectuur

Het proces van totstandkoming van een security architectuur kan het beste vormgegeven worden door security als integraal onderdeel op te nemen in de enterprise architectuur. Een mogelijke procesflow voor het opstellen van de security architectuur is weergegeven in figuur 3.

Figuur 3: Ontwikkelproces security architectuur

Governance van de security architectuur

Security vraagt om een governance structuur waarbij zich naar de business andere stakeholders bevinden. Voor security zijn dit met name de CSO (Corporate Security Officer), CRO (Corporate Risk Officer) of de CISO (Corporate Information Security Officer). Security architectuur dient met name een samenhangend geheel van maatregelen op te leveren in de architectuur die in lijn is met het informatiebeveiligingsbeleid.

Hoe de security architectuur te onderhouden

De security architectuur dient net als een EA onderhouden te worden. Triggers die vragen om onderhoud zijn:

• Een gewijzigd dreigingsbeeld voor de organisatie.
• Reorganisatie en fusies.
• Gebruik van nieuwe technieken.
• Cloud computing en andere sourcingstrajecten.
• Lekken in de beveiliging.

Pitfalls

De belangrijkste pitfalls van een security architectuur zijn:

• Teveel diepgang in de architectuur waardoor deze door security mensen niet begrepen wordt.
• Onafhankelijk van andere architecturen ontwikkelen van een security architectuur.
• Teveel voor 100% beveiliging te gaan.

Security architectuurstandaarden

Standaarden, methoden en aanpakken op het gebied van security architectuur zijn zeer beperkt aanwezig in de markt. De belangrijkste methode op dit moment is SABSA⁶. SABSA is een business gedreven information security architectuur. De aanpak is gebaseerd op o.a. het Zachman framework. 

SABSA heeft een business insteek voor security en gaat uit van de business doelstellingen en zoekt daar op basis van business attributen de security elementen bij die noodzakelijk zijn om te realiseren. Aan deze attributen zijn KPI’s te koppelen, zodat security ook meetbaar gemaakt kan worden. SABSA is een uitgebreide methode die door haar omvang nog wel eens afschrikt. SABSA moet gebruikt worden op dezelfde wijze als ITIL. Neem hetgeen eruit wat je kunt gebruiken en ga er pragmatisch mee om. Architectuurmethoden zoals DYA en TOGAF kennen geen specifieke invulling voor security, iets wat vanuit het vakgebied informatiebeveiliging nog steeds een probleem is. Binnen de Open Group wordt gesproken over een mogelijke integratie van TOGAF en SABSA.

Op het gebied van security architectuur en security patronen is de NORA⁷ en de OSA (Open Security Architecture)⁸ een belangrijke ontwikkeling. De OSA ontwikkelt security patterns; deze zijn vrij technisch van aard, maar geven een goed overzicht van de wijze waarop beveiliging ingeregeld kan worden. De link naar de business requirements vanuit de OSA patronen is erg lastig.

In de NORA is een onderdeel informatiebeveiliging en de aanpak van informatiebeveiliging architectuur beschreven. Op dit moment worden security patronen ontwikkeld door een werkgroep van het PvIB; deze patronen zijn gebaseerd op de normen die door de NORA zijn gedefinieerd. De verwachting is dat deze normen begin 2011 onderdeel kunnen gaan uitmaken van de NORA informatiebeveiliging aanpak.