Buiten houden wat buiten hoort.
CC6.6 is het SOC 2-criterium over bescherming tegen bedreigingen van buiten je systeemgrenzen: de perimeter. Het vereist dat je toegangcontroles plaatst tussen de buitenwereld en je systemen, zodat wat alleen bereikbaar moet zijn vanaf binnen, niet open op het internet staat. Het grootste deel van die perimeter is tegenwoordig infrastructure-as-code: een beveiligingsgroep, een firewall-regel, een netwerkbeleid, wat betekent dat het in een pull request wordt besloten en in één wijziging verruimd kan worden.
The shapes the same control failure takes.
CC6.6 verzwakt wanneer een wijziging de grens opent, meestal om iets snel bereikbaar te maken. De terugkerende vormen:
Een firewall of beveiligingsgroep staat open voor de wereld
De bron van een ingress-regel wordt verruimd naar 0.0.0.0/0 (of ::/0), zodat een poort die alleen bereikbaar was vanaf binnen, nu bereikbaar is vanaf het hele internet.
Een beheerde resource wordt publiek toegankelijk
Een database, cache of bucket schakelt van privé naar publiek (een vlag voor publiek toegankelijk, een publiek subnet), zodat deze direct vanaf buiten bereikbaar is in plaats van alleen via de applicatie.
Een admin- of beheerpoort wordt blootgesteld
SSH, RDP, een databasepoort of een admin-console wordt geopend naar het internet in plaats van bereikbaar te zijn via een bastion of VPN.
Een allowlist wordt verruimd
Een restrictief bronbereik wordt verbreed, een enkel adres wordt een heel bereik, of een allowlist krijgt een wildcard, zodat meer van buiten naar binnen kan.
Een grenscontrole wordt omzeild
Een nieuw pad omzeilt de load balancer, gateway of WAF die voor het systeem staat, zodat extern verkeer een interne service direct bereikt.
Een beveiligingsgroep die een database opent naar het internet.
Een beheerde Postgres, die op een publiek routeerbaar eindpunt staat, moet bereikbaar zijn vanaf de laptop van een engineer voor een eenmalige migratie, dus de bron van de ingress-regel wordt verruimd om het werkend te krijgen. De snelle wijziging blijft staan, en nu accepteert de beveiligingsgroep verbindingen vanaf elk adres, niet alleen vanaf het subnet van de applicatie, op een database die een pad heeft vanaf het internet.
resource "aws_security_group_rule" "db_ingress" { from_port = 5432- cidr_blocks = [var.app_subnet_cidr]+ cidr_blocks = ["0.0.0.0/0"]}Dit verwijdert de bronbeperking op de databasepoort, zodat de beveiligingsgroep nu ingress vanaf elk adres toestaat; op een database die een pad heeft vanaf het internet, is dat het hele internet. CC6.6 gaat over bescherming tegen bedreigingen van buiten je systeemgrens, en een database die vanaf overal bereikbaar is, is precies de blootstelling waar het op gericht is. Beperk de bron tot het subnet of de beveiligingsgroep van de applicatie, of bereik deze via een bastion voor eenmalige toegang, in plaats van 0.0.0.0/0.
De perimeter wordt gecontroleerd op wat daadwerkelijk bereikbaar is.
Een auditor neemt 'we hebben een firewall' niet voor waar aan; ze kijken naar de daadwerkelijke grens: welke poorten openstaan, naar welke bronnen, en of iets wat intern moet zijn, bereikbaar is vanaf buiten. Een beveiligingsgroep die openstaat voor 0.0.0.0/0, een database die publiek toegankelijk is, of een admin-poort die blootgesteld is aan het internet, is het soort uitzondering dat een bevinding wordt, en die komt meestal in één infrastructurele wijziging binnen. Het opvangen bij de diff houdt de blootstelling buiten de omgeving die de audit beoordeelt.
Een review, geen netwerkscan.
heygrc markeert wijzigingen die CC6.6 raken en citeert het criterium, zodat de oplossing in de pull request plaatsvindt. Het scant je perimeter niet en voert je cloud-posturetooling niet uit. Het vangt het moment op waarop een wijziging de grens opent, bij de diff.