Projecten, in detail

• Eén gedeelde core bevat de gemeenschappelijke tooling; elke organisatie krijgt een eigen instantie.
• Werk komt branch per branch binnen, nooit ter plekke.
• Elke branch doorloopt een onafhankelijke review, een automatische scan die organisatiegegevens blokkeert en een door de eigenaar goedgekeurde merge.

• Onafhankelijke reviewers zijn gebonden aan de exacte commit, zodat wat beoordeeld is ook is wat wordt opgeleverd.
• Een markeringsscan blokkeert organisatiegegevens.
• Zware taken draaien een voor een, zodat gedeelde middelen voorspelbaar blijven.

• Hij meldt hostfeiten: belasting, geheugen, schijven, services, openstaande updates en luisterende poorten. Alleen feiten, geen geheimen en geen bestandsinhoud.
• Hij voert alleen commando’s uit van een vaste toelatingslijst die in zijn eigen lokale configuratie is vastgelegd, en beperkt de uitvoer die een commando teruggeeft. Al het andere wordt geweigerd en gemeld.
• Commando’s zijn ondertekend en hebben een vervaldatum; een verlopen commando, of een dat al eerder gezien is, wordt genegeerd.
• Eén sleutel per host, beperkt tot de eigen paden van die host. Een versiebeheerrepository dient als transport en er is geen inkomende poort: de host neemt contact op en niets bereikt hem van buitenaf.
• Uitrol in volgorde: eerst alleen feiten en alleen-lezen op één echte host, commando’s als laatste.

Het ontwerp is zoals hierboven beschreven. Waartegen het niet beschermt:

• Een gecompromitteerde host. De eigen sleutel van de host laat een aanvaller valse feiten voor die host sturen; de schade blijft beperkt tot de paden van die host.
• Compromittering van de ondertekeningssleutel aan de verzendende kant. Dat zou elk toegestaan commando mogelijk maken op elke host die die sleutel vertrouwt. Hoe de sleutel wordt bewaard en hoe commando’s worden ondertekend, zijn nog open ontwerppunten.
• Een slechte toelatingslijst. De commando’s zijn maar zo veilig als de lokale configuratie die de hosteigenaar schrijft.

• Zones groeperen de agents, hosts en platformen.
• Een legendafilter toont of verbergt soorten dingen.
• Een tekstweergave geeft dezelfde informatie zonder het beeld.

• Een beheersmaatregel is gekoppeld aan de kaders waaraan hij voldoet, de risico's die hij beperkt, het bewijs dat hem ondersteunt en de audits waarin hij is getest.
• Kaders, vereisten en beheersmaatregelen zijn onderling gekoppelde records, geen platte lijsten; audit- en testrecords verbinden bevindingen met de geteste beheersmaatregelen.
• Beleid, issues, incidenten, leveranciersrisico, privacy, bedrijfscontinuïteit, regelgevende verplichtingen en opleidingen bevinden zich in dezelfde graaf.
• Workflows en dashboards worden opgebouwd uit herbruikbare stappen, triggers en weergaven.
• De rol van elke gebruiker bepaalt welke schermen voor hem bestaan. Tenants zijn gescheiden, met toegangsbeheer dat standaard weigert.
• Wijzigingen worden vastgelegd als gestructureerde gebeurtenissen (wie wat wijzigde, van welke waarde naar welke) en records bewaren gedateerde versies, zodat de vraag "hoe zag dit er toen uit" kan worden beantwoord.

• Een hiërarchisch, flexibel GRC-kader op basis van de CSA Cloud Controls Matrix, bedrijfsbreed uitgerold.
• Geautomatiseerde koppeling van beheersmaatregelen en taakworkflows voor ISMS-audits.
• Interne beveiligingsbeoordelingen op dezelfde basis.

• De methodologie van de grond af ontworpen en getest in een pilot.
• Interne en externe IT-audits daaromheen gecoördineerd.
• Een documentbeheerkader, ontworpen op drie kern-ITIL-processen.

• Een intern beheersingssysteem en een risico-beheersingsmatrix opgezet.
• Processen voor het beheer van bevoorrechte accounts ontwikkeld.
• IT-audits gecoördineerd.