Secure by design and default

Er zijn van die zinnen in de techwereld die klinken alsof ze meteen waar zijn, puur omdat ze goed in een PowerPoint passen. “Secure by design” is er zo eentje. Het voelt als een warme belofte: we hebben erover nagedacht, het zit in het ontwerp, u bent veilig, slaap zacht.

Alleen: “secure by design” zonder dat “by default” er aangeplakt is vaak hetzelfde als zeggen: “Deze auto is ontworpen met remmen… maar u moet ze wel zelf installeren, activeren en bij elke rit opnieuw configureren.”

En dan kijken we verbaasd dat mensen tegen dingen aan rijden.

“By design” gaat over bedoeling. “By default” gaat over werkelijkheid.

Secure by design betekent: in het ontwerp is rekening gehouden met security. Denk aan:

• threat modeling,
• scheiding van rechten,
• veilige architectuurkeuzes,
• encryptie-mogelijkheden,
• auditeerbaarheid.

Dat is de intentie. Het plan. De blauwdruk. Een gevoel...

Secure by default betekent: wanneer je het product installeert of uitrolt, staat het meteen redelijk veilig. Zonder dat je eerst:

• 27 instellingen hoeft te vinden in een verborgen menu,
• een handleiding van 140 pagina’s moet lezen,
• of een consultant moet inhuren die “hardening” zegt met een ernstig gezicht.

By default is hoe echte systemen de wereld in gaan: met standaardinstellingen, want mensen zijn druk, teams zijn onderbemand, en iedereen denkt dat iemand anders dit “later” wel goed komt.

Als je security alleen in het ontwerp zit, maar niet in de standaardconfiguratie, dan heb je security gebouwd voor het ideale universum. In dat universum:

• wordt elke feature correct geconfigureerd,
• zijn alle admins senior,
• en heeft niemand haast.

In ons universum worden instellingen vaak gedaan door:

• een beheerder op vrijdagmiddag,
• een ontwikkelaar die “even snel” iets wilde testen,
• of een cloud-template dat ooit is gekopieerd uit 2019.

Daarom is “default” niet optioneel. Default is hoe de meeste ellende ontstaat.

Het verschil tussen “kan veilig” en “is veilig”

Veel leveranciers zijn briljant in “secure by design”-taal, wat vaak betekent:

Het kan veilig worden ingericht.

Dat is technisch waar. Een kluis kan ook veilig zijn, zelfs als hij open staat. Hij heeft de potentie.

Maar secure by default betekent:

Het is veilig genoeg als je hem uit de doos haalt.

Niet perfect. Niet onbreekbaar. Maar ook niet standaard open.

“Kan veilig” is een marketingclaim.
“Is veilig” is een ontwerpkeuze die je omzet in standaard gedrag.

En dat is precies het verschil tussen:

• een product dat veiligheid aanbiedt,
• en een product dat veiligheid afdwingt.

Default is waar je de massa redt

De meeste gebruikers zijn geen security-experts. Ze zijn gewoon mensen die iets willen laten werken. In cybersecurity is “laten werken” vaak de vijand van “veilig laten werken”, want werken heeft directe beloning, veiligheid heeft uitgestelde beloning.

Als je security afhankelijk maakt van opt-in, dan krijg je opt-out op schaal.

Voorbeelden die we allemaal kennen, ook al doen we alsof we ze niet kennen:

• Admin accounts die standaard aan staan “voor gemak”
• Default wachtwoorden (ja, nog steeds)
• Open management interfaces “want anders kun je er niet bij”
• Loggingsystemen die uit staan omdat het “resources kost”
• Cloud storage dat per ongeluk publiek staat, omdat “delen” zo lekker eenvoudig was

By default is het moment waarop je besluit of je de wereld beschermt tegen zichzelf.

“By default” dwingt je om moeilijke keuzes te maken (en dat is precies waarom het zeldzaam is)

Secure by default is lastig, want het botst met:

• usability,
• verkoop,
• supportkosten,
• “time to first value”.

Een product dat standaard alles open zet, voelt meteen toegankelijk. Het doet het altijd. Het maakt demo’s makkelijk. Sales glimt. Support krijgt minder boze telefoontjes van mensen die per ongeluk zichzelf hebben buitengesloten.

Een product dat secure by default is, zegt vaker:

• “Nee, dat mag niet zonder toestemming.”
• “Zet MFA aan.”
• “Maak een rol aan.”
• “Kies expliciet wie toegang heeft.”
• “Dit endpoint staat niet publiek totdat jij dat echt wilt.”

En dat voelt voor sommige mensen als “gedoe”. Totdat het misgaat. Dan blijkt dat “gedoe” eigenlijk “volwassenheid” heet.

Secure by design zonder secure by default creëert schijnveiligheid

Dit is het venijnige deel: wanneer iets “secure by design” heet, gaan mensen aannemen dat het ook veilig staat.

Maar als je dan in de praktijk:

• logging handmatig moet aanzetten,
• encryption optioneel is,
• least privilege iets is wat je “later wel doet”,
• en de beheerinterface per ongeluk aan internet hangt,

dan is “secure by design” vooral een goed gevoel met een slecht resultaat.

Het is alsof je zegt: “We hebben een brandalarm ontworpen,” maar de batterij zit er niet in en je moet hem zelf kopen, installeren en activeren. En dan verbaasd zijn dat er brand was zonder piep.

Waar zit dan precies de nuance?

Secure by design = security ingebouwd in de architectuur en ontwikkelkeuzes.
Secure by default = security geactiveerd in de standaardconfiguratie, met veilige baselines en minimale blootstelling.

Belangrijke verschillen:

• Focus:
  • Design: hoe het gebouwd is
  • Default: hoe het geleverd wordt / start
• Risico:
  • Design: fouten in architectuur leiden tot fundamentele kwetsbaarheden
  • Default: misconfiguraties en gemak leiden tot massale exposure
• Afhankelijkheid van menselijk gedrag:
  • Design: minder afhankelijk van juiste keuzes later
  • Default: expliciet ontworpen om menselijke luiheid en haast op te vangen
• Effect op schaal:
  • Design: beschermt het systeemconcept
  • Default: beschermt de gemiddelde installatie in het wild

En “in het wild” is waar je product leeft. Niet in je testomgeving. Niet in je demo. In het wild, waar iemand ooit een poort openzet en het vergeet.

Daarom rakkers, de volgende keer als je weer op een powerpoint enkel "secure by design" tegen komt. Heel hard roepen: HET IS SECURE BY DESIGN AND DEFAULT!