1 на 100: праектныя групы для ліквідацыі прабелаў у бяспецы

1 на 100

Нават калі вы працуеце ў буйной арганізацыі, ёсць верагоднасць, што вы запомніце імёны ўсіх супрацоўнікаў службы бяспекі, якія працуюць у ІТ. Паводле нядаўняга апытання, стаўленне распрацоўшчыка да ўзроўню бяспекі складае 100: 1 (адно і тое ж даследаванне паказвае адносіны распрацоўшчыка да аперацыйнай сістэмы 10: 1). У папярэдніх даследаваннях паведамлялася пра суадносіны 100: 3 да 100: 6, таму быў дасягнуты пэўны прагрэс, але гэта не так хутка.

Гэта не з'яўляецца добрым знакам здольнасці гэтых арганізацый прымаць рашэнні аб маючых адбыцца рэгламентах па абароне дадзеных, такіх як GDPR Еўрапейскага Саюза, і спыняць дадзеныя, якія рэгулярна распаўсюджваюцца ў навінах у апошнія гады. Сёння няма дастаткова кваліфікаваных ахоўнікаў, каб запоўніць гэты прабел. Для паспяховага ўкаранення практыкі бяспечнай распрацоўкі і эксплуатацыі патрабуецца не толькі глыбокае тэхнічнае разуменне, але і ўменне мець зносіны, пераконваць і балансаваць, каб атрымаць перавагу сярод каманд распрацоўкі і (у асноўным) кіраўніцтва.

Мы па-ранейшаму знаходзімся ў зачараваным коле, дзе спецыялізацыя ў сферы бяспекі недастаткова прывабная, паколькі кампаніі ў мінулым не надавалі прыярытэтнага пытання бяспекі. У тых жа кампаній зараз узрастае патрэба ў паляпшэнні гульняў у бяспеку, але ў іх няма супрацоўнікаў.

Якія варыянты мы маем, каб закрыць гэтую ўразлівасць?

Па-першае, дасць зразумець, што аўтаматызацыя базавых праверак бяспекі (напрыклад, уразлівасцяў іншых вытворцаў) і інструкцый па кадаванні, а таксама інтэграцыя бяспекі ў канвеер разгортвання не павінны быць праблемай для любой каманды распрацоўшчыкаў прадуктаў у нашы дні. Набор інструментаў у DevSecOps пастаянна пашыраецца, і патрабаванні супольнасці і прадпрыемства добра выконваюцца.

Дык дзе разрыў? Менавіта ў "хакерскім мысленні" пастаянны пошук новых патэнцыйных вектараў нападаў у нашых дадатках ("невядомае невядомае"). А таксама складаная задача правесці змястоўны аналіз рызык і мадэляванне пагроз і ўвасобіць іх у меры і прыярытэты. Для іх неабходна глыбокае мысленне ў сферы бяспекі і веды. Каманды па распрацоўцы прадуктаў не могуць запатрабаваць прыняць гэты дадатковы пазнавальны цяжар у дадатак да іх існуючых абавязкаў.

Праца, якую мы з Мэцью Скелтанам рабілі, каб даследаваць, каталагізаваць і растлумачыць, як розныя тапалогіі DevOps могуць гуляць важную ролю ў прасоўванні або блакаванні прыняцця DevOps, добра адпавядае праблемы, якая ўзнікае.

Ёсць дзве розныя (і, магчыма, дадатковыя) тапалогіі каманды:

A) Цалкам размеркаваны абавязкі па бяспецы

Б) Бяспека як актывавальная каманда

У чым адрозненні, перавагі і недахопы асобных падыходаў?

Цалкам агульныя абавязкі па бяспецы азначаюць, што кожная група па распрацоўцы прадуктаў аб'ядноўвае па меншай меры аднаго члена каманды, арыентаванага на бяспеку. Такі падыход падыходзіць, калі арганізацыя накіравана на шматфункцыянальныя і аўтаномныя каманды па распрацоўцы прадуктаў. Супрацоўнік службы бяспекі павінен мець магчымасць перавесці складаныя пагрозы бяспецы ў дзеючыя справаздачы па бяспецы і крытэрыі прыняцця, якія каманда можа зразумець і рэалізаваць з тэхнічнага пункту гледжання.

Яны таксама павінны мець магчымасць паведамляць пра рызыкі і магчымыя выдаткі для кампаніі (захаванне, продаж і рэпутацыя) такім чынам, каб прадпрымальнікі маглі зразумець і расстаўляць прыярытэты. З іншага боку, пры неабходнасці яны павінны быць гатовыя да выканання задач, якія не звязаны з бяспекай. З цягам часу адказнасць за аналіз і ўкараненне бяспекі каманды павінна распаўсюджвацца, у той час як чалавек, які займаецца Т-вобразнай формай бяспекі, будзе валодаць ноу-хау перадавой практыкі, новых метадаў і інструментаў, а таксама дазволіць семінарам па бяспецы і весці стратэгію бяспекі прадуктаў. .

Мэта складаецца ў тым, каб не прысвоіць усёй працы па бяспецы асобе бяспекі. У адваротным выпадку мы перамесцім сілас толькі на макраўзроўні (ізаляваная каманда бяспекі) на мікраўзровень (ізаляваны член каманды).
Кожная каманда прадуктаў - паказаная ў выглядзе жоўтага круга - з 7 да 9 членаў каманды, прынамсі адзін з якіх з'яўляецца Т-вобразнай асобай бяспекі - паказаны зялёным кружком, - але іншыя людзі таксама ўдзельнічаюць у працы па бяспецы.

Вядома, у арганізацыі па-ранейшаму ёсць важнае месца для цэнтралізаванага гледжання бяспекі ў розных прадуктах і сферах бізнесу. Абмен вопытам, падыходамі і вынікамі мае вырашальнае значэнне. Аднак гэта можа быць у выглядзе супольнасці практыкі альбо гільдыі (на мове Spotify) ад матываваных людзей, якія рэгулярна збіраюцца замест адданага калектыву (хаця гэта можа спрацаваць, калі ў вас ёсць рэсурсы).

Перавагі

  • Адказнасць за бяспеку каманды ўзрастае, што прыводзіць да больш хуткага (нетрывіяльнага) рашэння інцыдэнтаў у сферы бяспекі і, магчыма, яшчэ важней, навучання іх, каб пазбегнуць таго, каб боль не паўтаралася ў будучыні.
  • Паколькі групы маюць натуральны ліміт памеру (8–9 чалавек), стаўленне ІТ-персаналу да супрацоўнікаў органаў бяспекі (Т-вобразнае) павінна з часам узрастаць з тапалогіяй гэтай каманды 10: 1. Разнастайнасць тэхнічнай падрыхтоўкі толькі прынясе перавагі ў вырашэнні праблем і прыярытэтаў.
  • Пераход да гэтай тапалогіі пашле бясспрэчны сігнал усім у арганізацыі пра тое, што бяспека ў нашых прадуктах з'яўляецца грамадзянінам першага класа.

Недахопы

  • Выдаткі на пошук і найму (якія могуць запатрабаваць шчодрых пакетаў) і запуску гэтых дадатковых 9 ахоўнікаў (у арганізацыі са 100 распрацоўшчыкамі) стануць сур'ёзнай праблемай (пра што гаворыцца ва ўступе да гэтай пасады). Чакайце, што гэты пераход зойме некаторы час. За гэты час неабходна выкарыстоўваць розныя мадэлі (некаторыя аўтаномныя групы прадуктаў і іншыя, якія ўсё яшчэ залежаць ад цэнтральнай каманды), і разгледзець, якія каманды трэба выбраць першымі. Напрыклад, пачніце з прысваення больш вопытнага супрацоўніка службы бяспекі камандам, якія працуюць на больш рызыкоўных прадуктах вашай кампаніі.
  • Магутныя аўтаномныя каманды грунтуюцца на стабільнасці і веданні моцных і слабых бакоў адзін аднаго. Любая змена складу каманды, нават калі прысутнічае толькі адзін чалавек, непазбежна прывядзе да перабояў. Каманда можа адчуваць, што яны прадастаўляюць менш і становяцца менш прадуктыўнымі, разглядаючы новы аспект бяспекі. Важна, каб усе разумелі, што гэта нармальна і прынята.
  • З пункту гледжання бяспекі няма цэнтральнай кантактнай кропкі. У прыватнасці, кіраўнікі маглі адчуць, што ў дэцэнтралізаванай структуры ніхто не знаходзіцца за рулём бяспекі. Тут можа быць карысна пераканацца, што каналы сувязі даступныя і што людзі могуць перасылаць запыты на інфармацыю пра бяспеку патрэбным камандам (альбо супольнасці практыкі).

Эўрыстыка

  • Ці ёсць у вашай арганізацыі шматфункцыянальныя каманды, якія аб'ядноўваюць уладальнікаў бізнесу, нясуць адказнасць за забеспячэнне якасці, кантралююць і запускаюць распрацаваныя імі прыкладанні?
  • Ці паказваюць тавары (ці паслугі) зусім іншыя профілі рызыкі?
  • Працуюць прадукты (ці паслугі) на разнастайных тэхнічных стэках і інфраструктуры?

Калі адказ на адно ці некалькі вышэйпералічаных пытанняў станоўчы, гэтая тапалогія можа апынуцца добрым спосабам закрыць уразлівасць.

Бяспека як актывавальная каманда азначае, што спецыялізаваная група па бяспецы падтрымлівае і падтрымлівае каманды па распрацоўцы прадуктаў (напрыклад, створаныя рэкамендацыі па бяспечнай распрацоўцы).

Важна, каб цэнтралізаваная група бяспекі не праводзіла фактычны аналіз і ўкараненне бяспекі, а, хутчэй, садзейнічала і вядзе яе пры неабходнасці.

Не менш важна, каб гэтая каманда ўдзельнічала ў праекце ці публікацыі з самага пачатку, каб каманда прадуктаў разглядала наступствы бяспекі, падыходы і практыку на кожным этапе жыццёвага цыклу.

Папярочная група бяспекі, паказаная вертыкальна ў шэрым колеры, падтрымлівае тры групы прадуктаў, якія гарызантальна адлюстраваны аранжавым колерам. Гэта прыводзіць да агульнай адказнасці за бяспеку, якая адлюстроўваецца як светла-зялёны круг

Шмат арганізацый абралі такі падыход, у тым ліку Spotify і Sportradar. Значна менш радыкальныя структурныя змены ў параўнанні з традыцыйным "сіласам каманды бяспекі" патрабуюцца, паколькі мы па сутнасці перакладаем абавязкі гэтай каманды (кіраўніцтва і падтрымка, а не рэалізацыя). Тым не менш, гэта можа зрабіць больш цяжкім для астатняй кампаніі ўсведамленне таго, што, як чакаецца, каманды каманд будуць лепш кантраляваць бяспеку сваіх сістэм.

Пабла Джэнсен, тэхнічны дырэктар ад Sportradar, нядаўна распавёў пра ролю сваёй спецыялізаванай групы па інфармацыйнай бяспецы ў прасоўванні палітыкі бяспекі і кіруючых прынцыпаў у цесным супрацоўніцтве з прадуктавымі групамі. Адзін з варот іх жыццёвага цыкла праекта - "Прыдатнасць для пачатку развіцця", якое патрабуе адабрэння групы бяспекі, каб наступствы бяспекі былі ўлічаны і праца была запланавана адпаведна. Гэтая каманда падпарадкоўваецца непасрэдна генеральнаму дырэктару і ў выпадку неабходнасці спыняе запуск прадукцыі.

Роля цэнтралізаванай службы бяспекі, якая не бярэ на сябе працу па бяспецы прадуктаў, але парады (крыніца: Пабла Джэнсен, тэхнічны дырэктар ад Sportradar - слайды з яго прэзентацыі на QCon London 2018)

Перавагі

  • Больш кароткі час для пераходу да мадэлі актывацыі з традыцыйнай ізаляванай групы бяспекі, якая выконвае вялікую частку бяспекі.
  • Не патрабуе вялікай колькасці новых супрацоўнікаў і, такім чынам, пазбягае звязаных намаганняў і магчымых збояў у калектыве. Пры гэтым асноўная ўвага павінна быць нададзена забеспячэнню каманды, якая ў цэлым мае ўсе неабходныя навыкі "мяккага", акрамя тэхнічных навыкаў.

Недахопы

  • Гэтай камандзе трэба асвоіць эфектыўную камунікацыю, што добра само па сабе. Гэта навык, які з часам трэба ўдасканальваць. Таму можа спатрэбіцца спачатку інвеставаць у знешнюю ці ўнутраную дапамогу, каб вызначыць камунікацыйныя стратэгіі і распрацаваць змест.
  • Пры пераходзе на гэтую мадэль будзе падавацца слабы сігнал для змены фокуса бяспекі. Сігнал павінен быць узмоцнены і, магчыма, прыйдзецца паўтарацца на працягу доўгага часу, перш чым пагрузіцца ў рамках арга-культуры.
  • Увядзенне новых абавязкаў, практыкі і інструментаў можа стаць складанай задачай для каманд па распрацоўцы прадуктаў, якія ўжо на піку. Каманда цэнтралізаванага актывізацыі можа быць перагружана і аказана ціск, каб атрымаць дапамогу ў рэалізацыі бяспекі прадукту, што адмяняе агульнае прызначэнне мадэлі.
  • З цягам часу фокус на бяспецы ў камандзе прадуктаў можа змяншацца без удзелу бяспекі ў планаванні выпуску / спрынту і штодзённых выпрабаваннях каманды. Пазбягайце такога кшталту дзяржаўнага кіравання.

Эўрыстыка

  • Ці існуе невялікая колькасць каманд па распрацоўцы прадуктаў (якія дазваляюць больш цесна супрацоўнічаць з групай бяспекі)?
  • Ці дэманструюць члены групы прадуктаў цікавасць да тэм бяспекі і гатоўнасць вучыцца (напрыклад, на тэхнічных канферэнцыях і сустрэчах)?
  • Зразумела, ці ўплывае на вытворчасць інцыдэнт, звязаны з бяспекай, як на супрацоўнікаў бяспекі, так і на развіццё (у адрозненне ад гульні вінаў, у якой кожны бок дыстанцуецца ад адказнасці)?

Калі адказ на адно ці некалькі вышэйпералічаных пытанняў станоўчы, гэтая тапалогія можа апынуцца добрым спосабам закрыць уразлівасць.

Выснова

DevSecOps узмацніла ўзровень бяспекі ў ІТ, і рэгулярны паток сур'ёзных парушэнняў дадзеных выявіў разрыў у бяспецы ў большасці кампаній. У гэтым пасце я прадставіў некалькі магчымых падыходаў, каб пераадолець гэты прабел (цалкам размеркаваны адказнасць за бяспеку супраць бяспекі як каманды пашырэння правоў), а таксама іх перавагі і недахопы і эўрыстыку, якія грунтуюцца на кантэксце.

Памятайце, што дызайн каманды не павінен быць статычным. Арганізацыі, людзі і працэсы развіваюцца натуральна з цягам часу. Што лепш за ўсё падыходзіць сёння, можа стаць перашкодай для больш хуткага і бяспечнага праграмнага забеспячэння заўтра. Цалкам магчыма, што кампанія можа першапачаткова перайсці ад традыцыйнага падыходу да сілавой бяспекі да мадэлі "бяспекі як актывацыі каманды" і з цягам часу да структуры з "цалкам агульнымі абавязкамі ў сферы бяспекі", як інфармаванне аб бяспецы і змяненне ведаў. да каманд прадуктаў.

Якія яшчэ тапалогіі каманды і стратэгіі бяспекі вы бачылі ў сваіх арганізацыях ці кліентах? Калі ласка, пракажыце ніжэй альбо адпраўце мне ліст на адрас:

мяне на Manuelpais расставіць