Development

Security
verveeld

Weinig ontwikkelaars zien veiligheid als hun verantwoordelijkheid

Onduidelijkheid wie eindverantwoordelijk is, ontwikkelaar, business of IT-beveiligingsexpert.

© CC BY-SA 2.0 - Flickt Kevin Hale
19 februari 2020

Onduidelijkheid wie eindverantwoordelijk is, ontwikkelaar, business of IT-beveiligingsexpert.

Nog geen derde van de ontwikkelaars bevraagd in een Europees onderzoek, zegt de veiligheid van het geleverde werk helemaal tot de eigen verantwoordelijkheid te rekenen.

De bevraagde organisaties maken zich als geheel geen zorgen over de veiligheid van de bij hen gemaakte software, blijkt uit een onderzoek uitgevoerd door NoSQL-databaseproducent MongoDB. Van de ontwikkelaars zegt 92 procent dat daartoe afdoende voorzorgsmaatregelen zijn getroffen. Bij de beslissers uit de 'business' vindt 88 procent dat. Maar het blijkt dat allerminst duidelijk is wie nu eigenlijk de verantwoordelijkheid daarvoor heeft.

Van de ontwikkelaars zegt 29 procent die verantwoordelijkheid te hebben, 22 procent zegt dat die verantwoordelijkheid ligt bij de securityspecialist en 18 procent wijst naar de executive die het project leidt. 16 procent zegt dat er een gedeelde verantwoordelijkheid bij het hele team ligt en 14 procent zegt helemaal geen idee te hebben.

Van de betrokkenen uit de business vindt 21 procent de veiligheid van software een zaak is voor ontwikkelaars. Meer dan een kwart (28 procent) legt die verantwoordelijkheid bij een security specialist en 21 procent vindt het een taak voor de business zelf. 10 procent weet het niet.

Spanning tussen ontwikkelaars en business

Volgens Lena Smart - chief information security officer bij MongoDB -, die ZDNet sprak, blijkt uit het onderzoek dat er een spanning is tussen ontwikkelaars en business met betrekking tot de veiligheid van apps. Zij suggereert dat het vooral een gemeenschappelijke verantwoordelijkheid is die duidelijker wordt door het instellen van DevSecOps-teams. Daarbij moet beveiliging ingebakken worden in het project omdat ontwikkelaars voortdurend onder druk staan om op tijd te leveren, volgens specificaties en veilig. De meest cruciale requirements met betrekking tot veiligheid moeten heel vroeg in het project worden benoemd en informatie moet open gedeeld worden onder teamleden.

Lees meer over Development OP AG Intelligence
3
Reacties
P.J. Weserhof LL.M MIM 19 februari 2020 15:33

Merkwaardig dat deze discussie nog steeds speelt, maar op zich niets nieuws.
Merkwaardig, omdat we nu toch zaken hebben als ASL, BiSL, ITIL architecturen, maar vooral Security-by-Design en Security-by-Default.
Niets nieuws, want ownership en opdrachtgeverschap is nog steeds een stiefkindje.

Iemand wordt maandelijks betaald om zijn verantwoordelijk als manager waar te maken, maar doet dat niet.
Dat is laf, vooral als je bij elke consequentie van je nalatigheid 'cyber-attack!' begint te kraaien.
Het is even goed laf - maar vooral onprofessioneel - van ontwikkelaars om ondermaatse requirements te accepteren, in plaats van deze terug te gooien in de boardroom waar het vandaan kwam.

'Meebewegen met de opdrachtgever' mag commercieel verstandig zijn, maar is dat alleen op korte termijn. Op langere termijn ga je samen met de falende opdrachtgever de bietenbrug op.

Atilla Vigh 19 februari 2020 12:37

Hij is nog breder dan dit. Wat ik de dagelijkse praktijk zie, is dat beleidsverantwoordelijken vanuit hun eigen discipline (Security & Privacy, Datamanagement, Beheer etc...) niet de vertaalslag kunnen maken naar technologie. Tegelijkertijd zie ik ook dat ICT-ers geen idee hebben wat ze met de relatief abstracte eisen en wensen aan moeten. Het vertalen van beleid in mijn optiek leidt tot functies en standaarden, vervolgens naar technologische componenten.
Je ziet in veel organisaties dat niet opgepakt worden: het is specialistisch detail werk en vereist een hoge mate van vakvolwassenheid. Tevens dien je sterk objectief te handelen. ICT-ers hebben de neiging persoonlijke voorkeuren te hebben en beleidsmakers zien technologie als eenvoudig. Het is zeker geen architectuurrol ofzo. Architectuur heeft een hoger abstractieniveau en kan helpen bij het aggreren van al deze eisen en wensen. Het is het detailniveau dieper zodat uiteindelijk tot implementatie overgegaan kan worden.

Heel kort: je kunt wel roepen tegen een aannemer "doe maar huis" en dan heel hard wegrennen, maar dat gaat hem nooit worden. De aannemer heeft al meer huizen gebouwd, en komt met de variant "de standaardcatalogus woning" aanzetten. Van hoog-over tot in detail is helaas gewoon noest arbeid, accept it or leave the game!

Reactie toevoegen
De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.