Patroon voor interne koppelvlakken met beheer en audit

Uit NORA Online
Ga naar: navigatie, zoeken

Op 19 juni 2017 zijn de Afgeleide Principes die raken aan het thema Beveiliging gewijzigd (zie nieuwsbericht). De beheersmaatregelen, implementatierichtlijnen en beveiligingspatronen uit de oude 'Katern' Beveiliging hangen hiermee beter in het bredere kader van de NORA-afspraken. De komende periode zal hieraan nog de ISOR (Information Security Object Repository) van het Centrum Informatiebeveiliging en Privacybescherming (CIP) worden toegevoegd. Contactpersonen: Annemieke de Wit & Ruud de Bruin

Ruud.deBruijn@uwv.nl;annemieke.dewit@cip-overheid.nl



Context

Overal vanuit de infrastructuur moeten koppelingen zijn gemaakt met de beheer- en auditomgeving. Koppelvlakken zijn handmatig of online gekoppeld met het beheerdomein. Zowel in het productie- als het ontwikkeldomein vindt infrastructuurbeheer plaats, maar doorgaans gescheiden van elkaar. Ook bij werkzaamheden voor Beheer en Audit worden functies gescheiden van elkaar uitgevoerd. Kort samengevat is het beheerkoppelvlak het koppelpunt tussen de handmatige of geautomatiseerde beheerhandeling ‘ergens in het productienetwerk’ en het te beheren doelsysteem. Dit geldt ook voor ontwikkelomgevingen.

Omgeving beheerkoppelvlakken

Probleem

De belangrijkste koppelvlak-gerelateerde problemen die voor infrastructuurbeheer en –audit opgelost moeten worden zijn 1, 2, 3 en 5 uit de probleembeschrijving van het themapatroon koppelvlakken. Daar komt bij dat audits slechts van waarde zijn wanneer beheerders de verkregen beveiligingsinformatie uit de systemen niet kunnen manipuleren.

  1. Het verschil in vertrouwensniveau van de zones vervalt bij een rechtstreekse (netwerk)koppeling, waardoor het effectieve vertrouwensniveau gelijk is aan het laagste vertrouwensniveau van alle gekoppelde zones. Daardoor kan de vertrouwelijkheid van de informatie in zones met een oorspronkelijk hoger vertrouwensniveau niet meer worden gewaarborgd.
  2. Rechtstreekse koppelingen van zones impliceert dat de individuele zones samengevoegd worden tot één logische zone. Daarbij vervalt de scheiding van verantwoordelijkheden voor de beveiliging binnen de individuele zones.
  3. Met een rechtstreekse (netwerk)koppeling is er geen controle op- of beheersing mogelijk van de integriteit, validiteit of classificatie van de uitgewisselde gegevens tussen de gekoppelde zones.
  1. Informatie kan weglekken bij de opening die gemaakt is in de zones en onderweg van de ene naar de andere zone.

Oplossing

De oplossing van dit patroon richt zich met name op Infrastructuurbeheer. De communicatie van de beheerorganisatie met de te beheren platformen kan door ontwikkelingen in de markt in toenemende mate geautomatiseerd plaatsvinden.

Koppelvlakken voor infrastructuurbeheer

Geautomatiseerd configuratiebeheer is noodzakelijk geworden door de complexiteit van IT infrastructuren. De overheid van de VS zet druk op standaardisatie van beheerprotocollen. De beheerkoppelvlakken moeten deze protocollen ondersteunen. Via dezelfde interfaces kan vanuit de IT-infrastructuur zowel beheer- als beveiligingsinformatie worden verzameld door een Event Manager, die zijn data doorgeeft aan een rapportagetool, of een Securitymanagement-datawarehouse. Auditors hebben toegang tot deze informatie.

De figuur geeft een voorbeeld van de communicatie van beheer- en auditinformatie vanuit de doelsystemen in de zones: DMZ, FO, BO en de Kluis. De Domein Element Manager (DEM) bundelt systeemspecifieke gegevens en stuurt deze naar de Centrale Element Manager (CEM). Een centrale rol in het geheel vervult de Configuratie Management Database (CMDB). Via een portaal op deze database krijgen bevoegde functionarissen toegang tot de betreffende beheerfuncties op de doelsystemen.

De IB-functies in het beheerkoppelvlak 14 zijn van veel factoren afhankelijk, o.a. of beheerders via een inband of outband netwerkverbinding communiceren. Inband is communiceren via een LAN productiesegment, op basis van TCP/IP waar ook andere systemen op gekoppeld zijn. Outband is een fysiek van het LAN gescheiden, veelal synchrone of asynchrone point-to-point verbinding tussen het beheerwerkstation en het te beheren systeem of de centrale beheertool. Voor outband communicatie is een beveiligd koppelvlak niet nodig. Beheerwerkzaamheden via deze interface worden in de directe nabijheid van het systeem uitgevoerd. Als maatregel resteert dan logging in het doelsysteem (Syslog). Centrale beheersystemen voor meerdere platformen communiceren vrijwel altijd inband. Voor inband communicatie via het LAN gelden de risico’s zoals hierboven genoemd. De maatregelen daarvoor zijn samengevat in onderstaande tabel. De meest gebruikte protocollen voor inband communicatie zijn: Simple Network Management (SNMP) en Security Content Automation (SCAP). Outband communicatie is leverancierspecifiek, op basis van synchrone of asynchrone communicatie via een bussysteem.

In de tabel worden de maatregelen voor beheerkoppelvlakken weergegeven.

IcoonContinuiteit.png IcoonZonering.png IcoonFiltering.png IcoonVastleggenGebeurtenissen.png IcoonAlarmering.png IcoonSysteemintegriteit.png
14 Inband & outband koppeling Inband koppeling
Outband koppeling
Fysieke scheiding
Poortfiltering
Geautoriseerde protocollen:
SNMP, SCAP
Van policy afwijkend communicatiegedrag Ongeautoriseerde beheerhandelingen Hardening
Patches

Afwegingen

De beheerzone is geen fysiek of logisch aaneengesloten zone zoals het zoneringsmodel suggereert. In de praktijk zullen er rond de verschillende platformen, zoals Windows, Midrange en Mainframe beheerclusters gevormd zijn die als gescheiden beheerdomeinen fungeren. Per situatie moet bekeken worden wat voor de afscherming van beheer- en productiewerkzaamheden de beste zonering is. Soms hebben organisaties separate LAN segmenten voor beheerwerkzaamheden ingericht, waarbij de systemen aan de ‘achterkant’ zijn gekoppeld met het beheernetwerk en aan de ‘voorkant’ met het productie-LAN. Wanneer een centraal beheerplatform is ingericht zoals geschetst in de bovenstaande figuur, dan bestaat het beheercluster om de systemen heen nog steeds. Het cluster dient in dat geval als ‘uitwijk’ en voor beheerhandelingen, die (nog) niet ondersteund worden door het centrale platform.

Voorbeelden

In elke organisatie zijn koppelingen gemaakt tussen IT-systemen en beheersystemen.

Implicaties

Beheerinfrastructuur en -protocollen en beheerinterfaces op doelplatformen zijn in beperkte mate gestandaardiseerd. Organisaties zullen keuzes moeten maken welke risico’s het zwaarst wegen voor de doelplatformen en in hoeverre men een strategie kiest voor inrichting van een CMDB. Informatiebeveiliging kan niet zonder beheer en voor grote en/of complexe infrastructuren is een actuele CMDB met de daaraan gekoppelde beveiligingsplatformen zoals een SIEM onmisbaar! Het ontwikkeldomein heeft vanwege functiescheiding bij voorkeur gescheiden beheer ten opzichte van het productiedomein. Voor releasemanagement hebben grote ontwikkelorganisaties een separate CMDB, waardoor het beheer goed is te scheiden.

Gerelateerde patronen