In 2025 totaal wereldwijde gegevenscreatie zal 181 zettabytes bereiken. Voor ondernemingen zijn die gegevens een troef, waardoor ze een verscheidenheid aan technologieplatforms kunnen inzetten om zeer gepersonaliseerde klantervaringen te creëren die loyaliteit bevorderen en nieuwe klanten aantrekken. Deze ervaringen zijn echter afhankelijk van cloudinfrastructuren die gedeelde beveiligingsmodi gebruiken. Dat is waar het risico ligt, en het wordt groter naarmate de technologie groeit en een nieuw leger van burgerontwikkelaars omvat die low-code- en no-code-platforms gebruiken.
De erfenismentaliteit begrijpen en overwinnen
Gartner schat dat in 2025 70% van de bedrijfsapplicaties gebouwd zal zijn op low-code en no-code platforms zoals Salesforce en ServiceNow. Reageren vanuit een op erfenis gebaseerde mentaliteit is een zekere manier om meer dan tweederde van de bedrijfsapps op een mislukking uit te laten lopen.
‘Erfelijkheidsmentaliteit’ is een treffende omschrijving voor de problemen waarmee de infrastructuur te kampen heeft. Het doet denken aan rijke, verwende kinderen die volledig afhankelijk zijn van het geleverde werk en de mensen die hen voorgingen. Dat is geen goede manier om een erfenis op te bouwen, en het is een even slechte manier om een systeem op te bouwen.
Als je een legacy-mentaliteit hebt, ga je ervan uit dat de infrastructuur klaar is. Het platform is veilig en de beveiliging is ingebouwd. Vertrouwen wordt verondersteld simpelweg omdat de technologie er al was vóór de beheerder.
Deze overervingsmentaliteit plaagt low-code- en no-code-platforms. Gebruikers vertrouwen op de veiligheid van een platform om ze door de volledige bedrijfsinfrastructuur te loodsen. In plaats daarvan zou de beveiliging van dat platform alleen op dat platform moeten gelden.
Laten we zeggen dat Salesforce-ontwikkelaars een geautomatiseerd toewijzingsprogramma voor nieuwe leads maken. Ze gebruiken het binnen Salesforce voor interne opdrachten, en dat gaat prima. Zij kunnen vertrouwen op de veiligheid van het platform. Ze besluiten het uit te breiden om de automatisering te verbeteren. Ze verbinden dat programma met een extern gerichte CRM zoals ServiceNow, SAP of Oracle. De erfenismentaliteit neemt het over: Salesforce is veilig. ServiceNow, SAP of de derde partij is veilig.
Dus Salesforce + derde partij = veilig.
Maar er zit veel onbekends in dat plusteken. Hoe verbindt u op veilige en conforme wijze het interne programma dat in Salesforce is gemaakt met het externe programma dat op het platform van derden is gemaakt? Er is veel ruimte voor fouten in dat ene personage.
En dat is slechts één verband. Veel programma's die in Salesforce zijn gemaakt, raken honderden andere programma's. Dat zijn honderden onbekenden die als het hierboven beschreven plusteken worden behandeld door mensen die weinig tot geen ontwikkelingservaring hebben.
De enige oplossing is om die ontwikkeling weer met beide benen op de grond te nemen en terug te keren naar de DevSecOps-principes.
Het opzetten van het DevSecOps-framework
DevSecOps raamwerken zijn geschreven, herschreven en opnieuw geschreven sinds het concept werd gecreëerd. Het is niet nodig om het wiel opnieuw uit te vinden bij het opzetten ervan, vooral niet wanneer SAFECode en de Cloud Security Alliance heeft zes pijlers opgebouwd:
- Collectieve verantwoordelijkheid: Beveiliging is de verantwoordelijkheid van iedereen in de onderneming, maar mensen kunnen niet voldoen aan normen die ze niet kennen. Er moeten leiders worden toegewezen om het cyberbeveiligingsbeleid te sturen en ervoor te zorgen dat dit binnen de hele onderneming wordt verspreid.
- Samenwerking en integratie: Kennis moet gedeeld en overgedragen worden. De helft van de reden dat bedrijven in de legacy-mentaliteit vervallen, is dat iedereen die het oude systeem kende, verdwenen is. Continue kennisuitwisseling helpt dit probleem te elimineren.
- Pragmatische implementatie: Een pragmatische implementatie sluit aan bij de ontwikkelaarservaring. Processen die moeilijk, alledaags en log zijn, worden niet lang gevolgd. Beveiliging moet worden ingebed in ontwikkelingspraktijken; dat wil zeggen dat elke regel code een testregel vereist. Een goed presterende onderneming zou nog een stap verder gaan door een tool te gebruiken om elke regel testcode te automatiseren.
- Naleving en ontwikkeling: Compliance-eisen moeten het ontwikkelingsproces zodanig sturen dat ontwikkelaars er niet van kunnen afwijken. Een ontwikkelaar voor een financiële instelling zou bijvoorbeeld werken aan een platform dat is ontworpen om te voldoen aan de Gramm-Leach-Bliley Act. De ontwikkelaar hoeft de individuele ins en outs van de wet niet te kennen om compliant te zijn, omdat deze in het platform zijn ingebouwd.
- Automatisering: Taken die voorspelbaar, herhaalbaar en hoogvolume zijn, moeten waar mogelijk worden geautomatiseerd om de last voor ontwikkelaars weg te nemen en het risico op menselijke fouten te verkleinen.
- Monitor: Moderne cloudinfrastructuren veranderen en groeien. Het is essentieel om dit in de gaten te houden – idealiter via een of andere vorm van orkestratie die een in één oogopslag mogelijk overzicht geeft van alle verschillende onderlinge verbindingen.
In een low- of no-code milieu zijn deze pijlers niet zo eenvoudig als je zou verwachten. De mensen die deze tools gebruiken zijn vaak bedrijfsexperts met weinig bekendheid met de basisprincipes van DevSecOps.
Het samenbrengen van mensen, processen en technologie
Het gebruik van low-code en no-code platforms kan daadwerkelijk helpen deze vaardigheidskloof te dichten. Medewerkers willen nieuwe vaardigheden leren. Bedrijven kunnen dit ondersteunen door een DevSecOps-framework op te zetten dat zich richt op mensen, processen en technologie.
- Processen: In een zero-trust-omgeving hoeven low-code- en no-code-ontwikkelaars zich geen zorgen te maken over het maken van verbindingen die de systeemintegriteit in gevaar brengen, omdat ze hiertoe niet in staat zijn. Ze hebben geen basisautoriteit buiten hun geïsoleerde systeem.
- People: Een cultuur van verantwoordelijkheid is iets anders dan een cultuur van schuld. Verantwoording betekent dat individuen zich op hun gemak voelen bij het naar voren brengen van een probleem of fout, omdat de focus op het probleem ligt en niet op de persoon.
- Technologie: Technologie is de grootste barrière voor een correcte implementatie van DevSecOps-principes, omdat deze buiten de handen van de ontwikkelaars ligt. Ze moeten gebruiken wat de organisatie hen geeft. Als die technologie niet werkt, zullen ontwikkelaars oplossingen bedenken die noch veilig, noch veilig zijn. In wezen wordt de technologie één grote schaduw-IT-generator.
We leven in een spannende tijd voor ontwikkeling. Steeds meer mensen hebben de mogelijkheid om software te bouwen, strategieën te testen en de bedrijfswaarde te verbeteren. Maar dat brengt risico met zich mee. Bedrijven die manieren zoeken om dat risico op de technologie af te wentelen, zullen hun ontwikkeling nuchter houden en tegelijkertijd ruimte laten voor onderzoek.
