Patroon voor interne koppelvlakken met beheer en audit
- Onderdeel van
- Thema's
- Contact
- Guus van den Berg
- Guus.vandenberg@cip-overheid.nl
- Status
- Dit thema wordt momenteel opnieuw bekeken door de Expertgroep Beveiliging
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.
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.
- 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.
- 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.
- 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.
- 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.
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.
 |
 |
 |
 |
 |
| |
|---|---|---|---|---|---|---|
| 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.