1 на 100: Как да проектираме екипи за преодоляване на пропуските в сигурността

1 на 100

Дори и да работите за голяма организация, има вероятност да запомните имената на всички хора по сигурността, работещи в ИТ. Това е така, тъй като съотношението на разработчиците към сигурността е 100: 1, според скорошно проучване (същото проучване показва съотношение 10: 1 на devs към ops). Предишни проучвания отчитат съотношения от 100: 3 до 100: 6, така че има известен напредък, но не достатъчно бърз.

Това не е полезно за способността на тези организации да се справят с предстоящите регламенти за защита на поверителността на данните, като GDPR на Европейския съюз и да спрат разпространението на данни, които се появяват редовно през последните години. Няма достатъчно квалифицирани хора по сигурността днес, за да запълнят празнината. Успешното възприемане на практиките за сигурно развитие и операции изисква не само задълбочено техническо разбиране, но и критично притежаване на умения за комуникация, убеждаване и балансиране за постигане на купуване от екипи за разработка и (по-често от не) от висшето ръководство също.

Все още сме в един порочен цикъл, в който специализацията по сигурността не е достатъчно привлекателна, защото исторически компаниите не са дали достатъчно приоритет на сигурността. Същите тези компании са изправени пред нарастваща нужда от повишаване на сигурността си, но им липсват хора.

И така, какви опции трябва да преодолеем тази пропаст в сигурността?

Първо да изясним, че автоматизирането на основните проверки за сигурност (като уязвимости на трети страни) и указанията за кодиране и интегрирането на сигурността в тръбопровода за доставка трябва да бъде безпроблемно за всеки екип за разработка на продукти днес. Наборът от инструменти в DevSecOps продължава да се разширява и изискванията на общността и на предприятието са добре обслужвани.

И къде е разликата? Той е в „хакерското мислене“, постоянно търсене на нови потенциални вектори за атака в нашите приложения („неизвестните неизвестни“). Освен това е в тежката задача за смислен анализ на риска и моделиране на заплахите и превръщането му в действия и приоритети. Те изискват задълбочено мислене за сигурността и предисторията, не може да се изисква от екипите за разработване на продукти да поемат като допълнително познавателно натоварване на базата на съществуващите си задължения.

Работата, която Матю Скелтън и аз извършихме, проучвайки, каталогизираме и обясняваме как различните топологии на DevOps могат да играят важна роля за прогресиране или блокиране на приемането на DevOps, се вписва добре с проблема, който съществува.

Две различни (и евентуално допълващи се) екипни топологии идват на ум:

А) Напълно споделени отговорности по сигурността

Б) Сигурност като екип за активиране

Какви са разликите, плюсовете и минусите на всеки подход?

Напълно споделени отговорности по сигурността означава, че всеки екип за разработка на продукти интегрира поне един член на екипа, фокусиран върху сигурността, T-образна форма. Този подход е подходящ, когато организацията се стреми към многофункционални екипи за автономно разработване на продукти. Лицето по сигурността трябва да може да преобразува сложни заплахи за сигурността в действителни истории за сигурност и критерии за приемане, които екипът може да разбере и приложи от техническа гледна точка.

Те трябва също така да могат да съобщават рисковете и потенциалните разходи за организацията (спазване, приходи и репутация) по начин, който собствениците на фирми могат да разберат и да приоритизират. От друга страна, те трябва да са готови да изпълняват задачи, които не са свързани със сигурността, когато е необходимо. С течение на времето собствеността върху анализа и прилагането на сигурността трябва да се разпространи в екипа, докато Т-образното лице за сигурност може да поддържа експертен опит по отношение на това да бъде на върха на най-добрите практики за сигурност, нови методи и инструменти, улесняващи свързаните със сигурността семинари и водеща сигурност на продуктите стратегия.

Целта не е човекът по сигурността да разпределя цялата работа по сигурността, в противен случай просто преместваме силоз на макро ниво (изолиран екип по сигурността) към микро ниво (изолиран член на екипа).
Всеки екип от продукти - изобразен като жълт кръг - със 7 до 9 членове на екипа, където най-малко един е охранителен човек с форма на Т - изобразен в зелен кръг - но други хора също участват в работата по сигурността

Разбира се, все още има важно място за централизиран поглед върху сигурността в множество продукти и бизнес области в организацията. Споделянето на опит, подходи и резултати е изключително важно. Но това може да бъде под формата на общност от практики или гилдия (на езика Spotify) на мотивирани индивиди, които се събират редовно, а не на специализиран екип (въпреки че това може да работи и ако имате средства).

Професионалисти

  • Притежанието на екипната сигурност ще се увеличи, което ще доведе до по-бързо (нетривиално) разрешаване на инциденти със сигурност и, може би по-важното, учене от тях, за да не се повтаря болката в бъдеще.
  • Тъй като екипите имат естествено ограничение на размера (8–9 души), съотношението на ИТ персонала към персонала на сигурността (Т-образна форма) трябва с времето да се приближи до 10: 1 с тази топология на екипа. Разнообразието само в техническия фон ще донесе ползи по отношение на подхода към проблемите и приоритетите.
  • Преминаването към тази топология ще изпрати неоспорим сигнал на всички в организацията, че сигурността вече е първокласен гражданин в нашите продукти.

Против

  • Цената за намирането и наемането на персонал (които може да изискват щедри пакети) и увеличаването на тези допълнителни 9 лица по сигурността (в органа със 100 разработчици) ще бъде сериозен проблем (според въвеждането на тази публикация). Очаквайте този преход да отнеме значително време, през което трябва да разполагате с комбинация от модели (някои автономни продуктови екипи и някои все още в зависимост от централизиран екип) и да помислите за стратегия за избор на кои отбори да отидат първи. Например, започнете, като присвоите по-опитните хора по сигурността на екипите, работещи по по-рисковите продукти във вашата организация.
  • Високопроизводителните автономни екипи се основават на стабилността и познаването на силните и слабите страни един на друг. Всяка промяна в състава на екипа, дори и един човек, неизбежно ще доведе до някои смущения. Екипът може да почувства, че доставя по-малко и става по-малко продуктивен, докато поеме в новия ъгъл на сигурност. Важно е всички да разбират, че това е нормално и прието.
  • Липса на централизиран център за контакт по съображения за сигурност. По-специално старшите мениджъри може да смятат, че „никой не е в колелото на сигурността“ в децентрализирана структура. Уверете се, че има комуникационни канали и хората, които могат да насочват искания за информация за сигурност към правилните екипи (или към общност от практики), могат да помогнат тук.

евристики

  • Дали вашата организация вече има създадени многофункционални екипи, интегриращи собственици на бизнес и отговорности за QA и мониторинг и стартиране на разработените от тях приложения?
  • Дали продуктите (или услугите) показват много различни рискови профили?
  • Продуктите (или услугите) работят ли на хетерогенни технологични стекове и инфраструктура?

Ако отговорът на още един от горните въпроси е утвърдителен, то тази топология може да се окаже подходяща за отстраняване на пропуските в сигурността.

Сигурността като екип за разрешаване означава, че специализиран екип по сигурността осигурява подкрепа и насоки (например, създаване на указания за сигурна разработка) на екипите за разработване на продукти.

Важното е, че централизираният екип за сигурност не извършва действителната работа по анализа на сигурността и внедряването, вместо това го популяризира и ръководи, когато е необходимо.

Също толкова важно е този екип да се включи от самото начало на проекта или изданието, за да помогне на екипа на продуктите да разгледа последиците, подходите и практиките за сигурността на всеки етап от жизнения цикъл.

Един напречен екип за сигурност - изобразен вертикално в сиво - поддържа три продуктови екипа - изобразени хоризонтално в оранжево - което води до споделена отговорност за сигурността - изобразени като светло зелен кръг

Много организации са възприели този подход, включително Spotify и Sportradar. Това изисква много по-малко драстична структурна промяна от традиционния „силозен екип за сигурност“, тъй като по същество изместваме отговорностите на този екип (насоки и подкрепа, а не прилагане). Но това може да затрудни останалата част от организацията да осъзнаят напълно, че се очаква екипите на продуктите да поемат по-голяма собственост върху сигурността на своите системи.

Пабло Йенсен, технически директор в Sportradar, наскоро говори за ролята на техния специализиран екип за сигурност на информацията за насърчаване на насоките и политиките за сигурност в тясно сътрудничество с продуктовите екипи, изслушвайки техните отзиви и итерации във времето. Една от портите на жизнения им цикъл на проекта е „годност за стартиране на разработката“, която изисква одобрение от екипа по сигурността, че е разгледано достатъчно внимание на последиците за сигурността и работата, която е планирана съответно. Този екип се отчита директно на изпълнителния директор и има право да спира пускането на продукти, ако е необходимо.

Роля на централизиран екип по сигурността, който предоставя насоки, а не да върши работа по сигурността на продуктите (Кредит: Пабло Йенсен, технически директор в Sportradar - слайдове от неговата презентация на QCon London 2018)

Професионалисти

  • По-кратка времева рамка за преминаване към модел за активиране от традиционен изолиран екип по сигурността, който извършва по-голямата част от работата по сигурността.
  • Няма да изисква голям брой нови наемания, като по този начин се избягват всички свързани усилия и прекъсване на потенциалния екип. Тук трябва да се съсредоточи вниманието върху осигуряването на необходимия екип като всички меки умения, необходими на техническите умения.

Против

  • Този екип трябва да овладее ефективната комуникация, което само по себе си е добро нещо. Това е умение, което трябва да бъде усъвършенствано във времето, като по този начин първоначално може да се изисква инвестиране във външна или вътрешна помощ за определяне на комуникационните стратегии и съдържанието на куратите.
  • Преминаването към този модел изпраща слаб сигнал за промяната в фокуса върху сигурността. Сигналът трябва да се усилва и може да изисква повторение за дълго време, докато не потъне като част от орга културата.
  • Въвеждането на нови отговорности, практики и инструменти може да бъде предизвикателство за екипите за разработка на продукти, които вече са в пика на техния капацитет. Екипът за централизирана помощ може да се затрупа с молби за помощ и да бъде подложен на натиск, за да помогне за внедряването на сигурността на продуктите, което би разгромило цялата цел на модела.
  • С течение на времето фокусът върху сигурността вътре в екипите на продуктите може да избледнее, без човек от охраната да участва в планирането на изданието / спринта на екипа и ежедневните промени. Необходимо е да се въведе някакъв вид управление, за да се избегне този ефект.

евристики

  • Има ли малък брой екипи за разработка на продукти (позволяващи по-тясно сътрудничество с екипа по сигурността)?
  • Членове на продуктовия екип проявяват ли интерес към теми за сигурност и апетит да се учат (например да посещават технически конференции или срещи)?
  • Разрешаването на инциденти, свързани със сигурността в производството, включва ли естествено хора, свързани със сигурността и развитието (за разлика от играта на вината, при която всяка страна се отказва от отговорност)?

Ако отговорът на още един от горните въпроси е утвърдителен, то тази топология може да се окаже подходяща за отстраняване на пропуските в сигурността.

заключение

DevSecOps повдигна профила на сигурността в ИТ и редовният поток от сериозни нарушения на данните разкрива пропастта в сигурността в повечето организации. В тази публикация представих няколко възможни подхода за преодоляване на тази пропаст (напълно споделена отговорност за сигурността срещу сигурността като благоприятен екип), заедно с техните плюсове и минуси и евристика, базирана на контекста.

Не забравяйте, че дизайнът на екипа не трябва да е статичен. Организациите, хората и процесите се развиват естествено с течение на времето и това, което днес е най-добре, може да бъде утре пречка за по-бърз и безопасен софтуер. Възможно е организацията първо да премине от традиционния подход за силозен охранителен режим към модел „сигурност като екип, който дава възможност за сигурност“, и от време на време да премине към структура на „напълно споделени отговорности за сигурността“, тъй като осведомеността и експертизата по сигурността се разпространяват в продуктовите екипи.

Какви други екипи от топологии и стратегии за сигурност сте виждали във вашите организации или клиенти? Моля, коментирайте по-долу или ми пишете на:

мен в manuelpais точка нето