Beveiligingsvereisten voor ontwikkelingsplanning aannemen

In dit artikel worden de belangrijkste imperatieven voor het integreren van beveiliging in ontwikkelprocedures gedefinieerd als onderdeel van de Ontwikkelingsbeveiligingsdiscipline.

Moderne organisaties zijn afhankelijk van snelle softwareontwikkeling om innovatie te leveren, te voldoen aan zakelijke vereisten, concurrentievoordeel te behouden en te reageren op veranderende bedrijfsbehoeften. Hoewel DevOps deze flexibiliteit mogelijk maakt, worden er ook nieuwe beveiligingsrisico's geïntroduceerd wanneer code-, infrastructuur- en implementatieprocessen sneller worden ontwikkeld.

Om DevOps-procedures veilig te kunnen gebruiken, moeten organisaties beveiliging integreren in ontwikkelingsstrategie, werkstromen en leveringsprocessen, en DevSecOps-procedures gebruiken die de levering van toepassingen gedurende de hele levenscyclus beveiligen.

Resultaten

Door de plannings imperatieven in dit artikel te gebruiken, kunnen organisaties het volgende doen:

• Verminder het introduceren van beveiligingszwakheden in productieworkloads.
• Verbeter de consistentie van beslissingen over productiegereedheid.
• Verminder wrijving tussen ontwikkeling, beveiliging en bewerkingen.
• Verbeter de tolerantie van toepassingen en de leveringsinfrastructuur.
• Behoud het innovatietempo terwijl u beveiligings- en operationele risico's beheert.

Het bereik van de ontwikkelbeveiliging herkennen

Ontwikkelbeveiliging is van toepassing op meer dan toepassingscode. Organisaties moeten beveiligingsvereisten en -activiteiten definiëren voor alle onderdelen die betrokken zijn bij het ontwerpen, bouwen, implementeren en uitvoeren van workloads.

Organisaties moeten rekening houden met beveiligingsrisico's in:

• Toepassingslogica en -services
• Implementaties van infrastructuurautomatisering/infrastructure as code (IaC)
• Build- en release-pijplijnen
• Uitrolconfiguraties en operationele scripts
• Ontwikkelomgevingen en service-identiteiten
• Afhankelijkheden en onderdelen van de toeleveringsketen van derden

Door dit volledige bereik te herkennen, kunnen organisaties beveiligingsvereisten definiëren die aangeven hoe moderne workloads worden geleverd, in plaats van de beveiliging te beperken tot de beoordeling van toepassingscode die te laat in de levenscyclus is uitgevoerd.

Houd rekening met belangrijke risico's

Organisaties moeten expliciet de volgende risico's opnemen bij het definiëren van vereisten:

Deze risico's informeren de planningsvereisten die in dit artikel zijn gedefinieerd en moeten worden aangepakt door middel van ontwerp-, proces- en governancebeslissingen.

Deze risico's zijn van invloed op zowel toepassingsworkloads als de infrastructuur die wordt gebruikt om ze te bouwen en te gebruiken.

Beveiliging integreren in strategie/levenscyclus

Beveiliging moet worden opgenomen in de ontwikkelingsstrategie, niet toegepast als een controle na de release.

Organisaties moeten naast functionele vereisten beveiligingsvereisten definiëren en deze afstemmen op:

• Ontwikkelingsstrategie
• Architectuurplanning
• Leveringswerkstromen
• Operationele ondersteuningsmodellen

Beveiligingsresultaten zijn gedeelde verantwoordelijkheden die eigendom zijn van engineering- en operationele rollen, ondersteund door beveiligingsspecialisten.

Beveiliging maakt innovatie mogelijk, het is geen poort die na levering wordt toegepast.

Organisaties moeten een continue SDL-benadering (Secure Development Lifecycle) hanteren die het volgende omvat:

• Beveiligingsvereisten vroeg in het ontwerp definiëren.
• Beveiligingsvereisten afstemmen op architectuur en implementatie.
• Beveiliging integreren met infrastructuurautomatisering.
• Continue beveiligingsvalidatie uitvoeren.
• Beveiligingsresultaten bijhouden.
• Prioriteit geven aan herstel.
• Beveiligingsresultaten toepassen op beslissingen over releasegereedheid, zodat beveiligingsproblemen zo nodig worden behandeld als productieblokkeringen.

Beveiliging moet continu worden geëvalueerd en verbeterd naarmate toepassingsarchitecturen, risico's en leveringsmodellen zich ontwikkelen.

Minimale criteria voor productie-levensvatbaarheid definiëren

Workloads moeten voldoen aan minimale criteria voor inzetbaarheid voordat ze voor productie worden vrijgegeven. Deze criteria bepalen of een workload veilig, compatibel en operationeel gereed is voor productiegebruik in drie dimensies:

• Ontwikkeling (dev): Belanghebbenden van ontwikkeling definiëren minimale functionele vereisten die nodig zijn om te voldoen aan bedrijfsbehoeften en klant-/gebruikerswaarde.
• Beveiliging (sec): beveiligingsbelangen definiëren minimale vereisten die nodig zijn om te voldoen aan wettelijke verplichtingen, het handhaven van de beveiligingspostuur van de organisatie en het ondersteunen van detectie en reactie van actieve bedreigingen.
• Bewerkingen (ops): Belanghebbenden van operations definiëren minimale vereisten voor prestaties, kwaliteit en ondersteuning die nodig zijn om de workload betrouwbaar te laten werken in productieomgevingen.

Criteria voor productie-levensvatbaarheid:

• Zorg ervoor dat workloads veilig kunnen worden geïmplementeerd en beheerd in productieomgevingen.
• Dienen als input voor releasebeslissingen en moeten consequent worden afgedwongen in ontwikkelworkflows.

Criteria voor productie-levensvatbaarheid veranderen op basis van wijzigingen in:

• Leveringsmodellen voor toepassingen.
• Bedreigingsvoorwaarden.
• Tolerantie voor organisatierisico's.
• Nalevingsvereisten.

Beveiliging integreren in ontwikkelwerkstromen

Beveiliging moet rechtstreeks worden ingesloten in ontwikkelings- en leveringsprocessen. Organisaties moeten:

• Definieer beveiligingsvereisten binnen ontwikkelwerkstromen.
• Beveiligingsactiviteiten integreren in:
  • Ontwerpprocessen
  • Pijplijnen bouwen
  • Implementatiewerkstromen (CI/CD)
• Beveiligingsvalidatiemechanismen implementeren, zoals:
  • Code scannen
  • Afhankelijkheidsvalidatie
  • Configuratiecontroles

Beveiligingsresultaten moeten hetzelfde worden behandeld als productiefouten en moeten worden opgenomen in releasebeslissingen.

Beveiligingsvalidatie moet continu plaatsvinden via de levering, niet alleen bij releasecontrolepunten.

Balans en geharmoniseerde vereisten

Organisaties moeten definiëren hoe de ontwikkelings-, beveiligings- en operationele vereisten in balans zijn in beslissingen over softwarelevering. Productieworkloads moeten voldoen aan de vereisten op de volgende gebieden:

• Bedrijfsfunctionaliteit.
• Beveiligingstolerantie.
• Snelheid van innovatie.
• Operationele betrouwbaarheid en prestaties.

Organisaties moeten gedeelde leveringsdoelstellingen en prestatiemetrieken definiëren die:

• Afstemmen op gedeelde prestatie- en leveringsdoelstellingen voor ontwikkeling, beveiliging en bewerkingen.
• Vermijd overheersing door één domein.
• Resultaten prioriteren op basis van:
  • Tolerantie voor organisatierisico's.
  • Wettelijke verplichtingen.
  • Zakelijke verantwoordelijkheid.

Het evenwicht moet zich aanpassen naarmate bedreigingsomstandigheden zich ontwikkelen, leveringsmodellen veranderen en de prioriteiten van de organisatie veranderen.

Gedeelde aansprakelijkheid instellen

Effectieve DevSecOps vereist gedeeld eigendom voor ontwikkelings-, beveiligings- en operationele teams met het oog op:

• De verantwoordelijkheid voor de criteria voor productiegeschiktheid afstemmen.
• Het afstemmen van leveringsdoelstellingen in verschillende disciplines.
• Het verminderen van silo's en ongezonde frictie die beveiligingslacunes, leveringsvertragingen en operationele instabiliteit veroorzaken.

Pas beleidsgestuurde beveiligingsmaatregelen toe

Beleidgestuurde kaders moeten controles afdwingen zonder overmatige wrijving. Richtlijnen moeten het volgende bevatten:

• Identiteits- en toegangsvereisten.
• Configuratie- en nalevingsstandaarden.
• Implementatie- en releasemaatregelen.

Richtlijnen moeten zijn:

• Geïntegreerd in platformfundamenten (bijvoorbeeld landingszones).
• Ingesloten in werkstromen voor ontwikkeling/implementatie.
• Automatisch afgedwongen indien mogelijk.

Deze aanpak zorgt ervoor dat beveiligingsvereisten consistent worden toegepast terwijl de leveringssnelheid wordt gehandhaafd.

Voor een evenwichtige benadering van beveiliging en snelheid van innovatie moet u de acceptatie beoordelen met behulp van beleidgestuurde kaders.

Behouden en verbeteren

Beveiliging blijft niet effectief als een statische set besturingselementen en moet zich in de loop van de tijd ontwikkelen.

Organisaties moeten de beveiligingsprocedures voor ontwikkeling continu evalueren en bijwerken als reactie op wijzigingen in:

• Bedreigingsvoorwaarden en gedrag van aanvallers.
• Toepassingsarchitecturen en leveringsmodellen.
• Wettelijke verplichtingen.
• Tolerantie voor organisatierisico's.
• Criteria voor productie-levensvatbaarheid.
• Ontwikkelingsleveringsprocessen.
• Praktijken voor beveiligingsgovernance.

Beveiligingsprocedures moeten zich ontwikkelen naast de systemen die ze beveiligen.

Uitlijningstechnieken

Teams moeten aansluiten op:

• Algemene doelstellingen definiëren: ontwikkelings-, beveiligings- en operationele leiders moeten gezamenlijk leveringsdoelstellingen en prestatiemetrieken definiëren voor de levering van workloads, ter ondersteuning van consistente releaseplanning.
• Dominantie van beslissingen met één domein voorkomen: leveringsbeslissingen moeten rekening houden met ontwikkelings-, beveiligings- en operationele vereisten om onbalansen te voorkomen die een negatieve invloed kunnen hebben op de betrouwbaarheid, naleving of bedrijfsfunctionaliteit van de werkbelasting.
• Prioriteit geven aan continue verbetering ten opzichte van statische releasecriteria: beveiligingsprocedures voor ontwikkeling moeten na verloop van tijd iteratief worden verfijnd naarmate toepassingsleveringsmodellen, bedreigingsvoorwaarden en organisatieprioriteiten zich ontwikkelen.
• Een gedeelde leveringscontext tot stand brengen voor rollen van belanghebbenden: Ontwikkel-, beveiligings- en operationele teams moeten een gedeeld begrip van:
  • Zakelijke urgentie en levertermijnen
  • Relevante bedreigingsomstandigheden en risicoblootstelling
  • Vereisten voor operationele beschikbaarheid en ondersteuning
• Controleer de leveringswrijving die is geïntroduceerd door beveiligingsvereisten: Beveiligingsvereisten kunnen leiden tot wrijving bij de levering. Leiders moeten evalueren of deze wrijving bijdraagt aan risicovermindering (bijvoorbeeld door een eerdere identificatie van beveiligingsproblemen mogelijk te maken) of onnodig de levering van werkbelastingen uit te stellen zonder dat de productietolerantie aanzienlijk wordt verbeterd.
• Ontwikkelbeveiliging opnemen in planning en resourcetoewijzing: Beveiligingsvereisten voor toepassingsworkloads moeten worden opgenomen in ontwikkelingsplanning en resourcetoewijzing, naast functionaliteits- en operationele ondersteuningsvereisten.
• Definieer prestatiedoelstellingen voor gedeelde levering: prestatie- en successtatistieken voor toepassingsworkloads moeten de resultaten van ontwikkeling, beveiliging en operationele levering weerspiegelen.

Werkstromen afstemmen op beveiligingsvereisten

Beveiliging moet worden uitgevoerd via ontwikkelwerkstromen. Organisaties moeten werkstromen definiëren en uitlijnen voor:

• Architectuurontwerpactiviteiten.
• Bouw- en implementatieprocessen.
• Werkstromen voor probleemregistratie en -oplossing.

Beveiligingsbevindingen moeten zijn:

• Prioriteit gegeven en bijgehouden.
• Beheerd naast productiefouten.
• Meegenomen in beslissingen over releasegereedheid.

Werkstroomuitlijning zorgt ervoor dat beveiligingsvereisten consistent worden afgedwongen tijdens de levering.

Volgende stappen 

Meer informatie over ontwikkeling met behulp van Zero Trust-principes