Чтобы понять безопасность, надо думать как безопасник, вести себя как безопасник, стать безопасником. Барух jbaruch Садогурский и Леонид Игольник в своих докладах много рассматривали DevOps с разных сторон — и очередь дошла до вопросов Security. На нашей конференции DevOops они поговорили об этом, и поскольку зрителям понравилось, теперь мы сделали текстовую версию доклада.
Как и в «предыдущих сериях», оформлено всё в формате приключений Васи с Омского мясокомбината. Теперь новый Chief Information Security Officer ставит Васе новые задачи, создает новые заботы и новые проблемы. Или, может быть, проблемы были и раньше, просто теперь они стали более заметны? Понимание мира, в котором живет CISO, поможет Васе и вам вместе с ним понять, какие проблемы безопасности стоят перед современной DevOps-организацией и как решить эти проблемы, не выкапывая новые колодцы и не создавая новые барьеры.
Под катом делимся и текстовой версией доклада, и видеозаписью. Экспертом на докладе выступил консультант по информационной безопасности Денис Якимов.
Вася становится CIO
Леонид: Как положено в безопасности, доверяй, но проверяй. Чтобы мы не наговорили лишнего, с нами будет Денис, который будет напоминать нам, если мы рассказываем абсолютную чушь. У нас сегодня, как обычно, история про нашего любимого героя Васю. Те из вас, кто с нами с первой конференции DevOops, уже знакомы с Васей — он у нас живет еще с нашего оригинального выступления в Питере в 2017 году.
Вася появился в нашем рассказе про греческую трагедию в трех актах, мифическую компанию «Пентагон Инк». Вася был инженером, так же, как и я когда-то. В последующих итерациях Вася появлялся во многих наших докладах. Он был и разработчиком, и тестировщиком. У Баруха есть великолепный доклад на Heisenbug о том, как включать тестировщиков, которые раньше частично жили рядом с разработкой, но ближе, чем ребята, которые отвечают за безопасность, и о том, что же им делать с этой штукой, которая называется DevOps.
Это довольно релевантно тому, что мы будем обсуждать сегодня. Ребята из безопасности, как мы считаем, находятся примерно на той же стадии, что и тестировщики на зачатии движения DevOps, но иногда — ещё дальше от ключевых процессов. Есть интересные вещи, которые можно перенести из этого доклада на то, как их все-таки влить в эту движуху.
Не так давно Вася был в докладе на DevOops 2020 Moscow. Мы рассказывали о том, как Вася, будучи простым инженером, двигал DevOps в компании, помогал трансформироваться мясокомбинату вплоть до того, как он стал CIO Омского мясокомбината, — и это то, где мы находим Васю сейчас. Проведя свою техническую деятельность, Вася начинает смотреть, что происходит дальше. Эволюционное давление для тех, кто смотрел тот доклад, продолжается.
Например, в России есть ФЗ-152 «О персональных данных», а как мы знаем, у нас сейчас каждая компания — это software-компания. Наш мясокомбинат — не исключение, им надо продавать свои товары напрямую с веб-сайта, e-commerce. Нужно обрабатывать личные данные, и Вася начинает понимать, что раньше кто-то когда-то где-то делал всё, что связано с безопасностью, а сейчас он ничего не понимает. Также однажды Вася вспоминает о своем прошлом работодателе, Омском свечном заводе.
Тот тоже был software-компанией и тоже хотел продавать свечи в интернете, и их тоже хакнули, как это часто бывает не только с маленькими свечными заводами, но и с довольно большими организациями, которые вы все знаете. И тут Вася начинает задумываться.
Барух: Хаканья — они не только у абстрактных свечных заводиков, которые мы придумали на докладах. Нам иногда говорят: «Вы выдумываете, такого в реальной жизни нет». Вот, открываю я сегодня Telegram и смотрю прекрасное сообщение о том, что хакнули постаматы PickPoint. Я считаю, это совершенно гениальный хак, думаю, там лежало много PlayStation 5, если вы понимаете боль. Гениально, но, с другой стороны, очень-очень страшно для Васи.
Леонид: Репутационный риск для бизнеса — один из самых высоких приоритетов сегодня, потому что, действительно, это серьезная проблема. Потерять доверие клиента и его данные — это самое страшное, что может случиться с компанией.
Немного статистики
Барух: Но я думаю, что вам это всё не ново. Если вы смотрели наши доклады и разбираетесь в индустрии, то прекрасно знаете, какое отношение имеет безопасность к DevOps, насколько важно автоматизировать и релизить чаще и быстрее, потому что, как вы помните, реактивная security, то есть когда что-то случилось, состоит из трех этапов: обнаружить — починить — задеплоить. Мы об этом говорили очень много, и я надеюсь, что в этой части ничего нового для вас нет.
Леонид: И также одна из вещей, которую мы любим повторять, — причины происходящего и макротренды. Один из наших любимых репортов в этой области — это Accelerate State of DevOps.
Если смотреть на разницу между 2018 и 2019 годами, то количество компаний, которые попали в категорию «elite», увеличилось с 7% до 20%, а количество компаний, которые попали в «medium», увеличилось с 37% до 44%. Мы видим разделение на элиту и всех остальных. Это очень часто можно наблюдать на велогонке, когда группа лидеров начинает просто отрываться от остального состава.
И это довольно естественно, такое происходит в любой индустрии из-за эволюционного давления. Каждая компания сегодня — это software-компания, и быть лучшей software-компанией выгодно для бизнеса. Это значит не терять данные, быстрее внедрять фичи, не падать под нагрузкой на сервера в черную пятницу и так далее. И это эволюционное давление двигает всё в индустрии, потому что бизнес существует для того, чтобы быть бизнесом. Соревнование в интернете сильнее, чем когда-либо, потому что ты соревнуешься со всеми своими мировыми конкурентами, где бы они ни находились, а не только в Омске на местном рынке мяса, где мясокомбинат продавал раньше свою продукцию.
Благодаря этому эволюционному давлению мы и двигаемся вперед, и индустрия стала делать это довольно давно. Цикл «обнаружить — починить — задеплоить», который показывал Барух, мы уже научились делать. У нас есть инструменты, пайплайны и подходы. Мы как индустрия научились это делать быстро, но вот безопасность на сегодняшний день довольно долго оставалась незамеченной, и с точки зрения безопасности первые две стадии до сих пор находятся в стороне.
Вася ищет CISO
Барух: Вася, как вы помните, пришел из разработки, из тестирования, он человек технический. Он почитал, послушал, подучил, научился деплоить, а вот про «обнаружить» и «починить» Барух с Леней ничего особо не говорили. И тут Вася понимает, что он в этом ничего не понимает, нужен эксперт. В данном случае это — CISO (Chief Information Security Officer).
Вася понимает, что ему нужно нанять CISO. Для того, чтобы нанять человека, нужно хотя бы немного разобраться, какие у нас требования, что этот человек будет делать. Вася идет по стопам Владимира Ильича и начинает учиться. Как вы знаете, Вася начинает с источника всей правды — с Википедии. Он читает, что такое CISO, как это есть, где это искать и как с этим работать. Он продолжает ничего не понимать, открывает CISSP — это классификационный стандарт, по нему надо сдавать экзамен.
Вася думает: «Ладно, я, пожалуй, попробую посмотреть, что такое CISSP и что эти CISO должны сдать, чтобы его получить». Находит книгу, она обычно из двух частей: CISSP и материалы для экзамена по нему. Если внимательно посмотреть на эту книгу и её описание — это тысяча с чем-то страниц. Вася начинает съезжать в депрессию, понимая, что это всё долго изучать, а мясокомбинату надо трансформироваться и продолжать работать. Дальше он видит, что есть дополнительные книги, и начинает понимать, что он ничего не понимает.
Барух: В этих книгах какая-то ересь: какая-то паста, какой-то страйд, какой-то драйд — куча слов, которые не имеют отношения к тому, что он думал, о чем эта безопасность.
И он читает — паста, страйды, драйды — это методы для моделирования рисков. Потом он читает дальше и оказывается, что этих методов не три, а минимум 12, и названия там всё еще очень странные. Понятно, что ничего не понятно. Более того, оказывается, что CISO вообще бывает очень-очень разный.
Леонид: И тут Вася начинает общаться с рекрутерами, коллегами и не понимает, что происходит. С инженерами всё понятно: ты вырос, сначала был джуниор-инженером, мидл-инженером, стал сениором, затем тимлидом, архитектором, там все просто. Ты инженер, ты растешь, кодируя, если тестировщик — тестируя. Если ты в Ops, у тебя свой колодец. А тут он начинает понимать, что кандидаты в CISO у него вдруг появляются двух типов. Есть те, которых он понимает, которые выросли инженерами, что-то когда-то хакали и пришли к безопасности с этой стороны.
Но есть другая категория CISO — это как адвокаты в костюмах, и всё, что они могут рассказать, — как раз эти ФЗ. Они вообще не похожи на технарей. И Вася не знает, что с этим делать, и технарей CISO, которых он понимает, абсолютное меньшинство. И роль-то техническая, надо понимать, как это всё работает, как это чинить. Вася продолжает изучать, потому что он понимает, что в этой роли есть как знакомое, так и непонятное.
Барух: Вася приходит к выводу, что CISO — это многорукий Шива.
CISO должен понимать техническую и юридическую стороны, бизнес, должен быть экспертом по информационной безопасности, но, с другой стороны, он еще и C-level executive (руководитель высшего звена). Короче говоря, всё очень обильно, и эта обильность хорошо описана в CISSP.
Дисциплины CISSP
Леонид: Давайте глянем, что такое CISSP. Если поднять документ из книги про CISSP, там у нас есть много разных дисциплин.
Asset Security. Защита чего-то, что есть у организации. У любой организации есть активы, которые нужно защищать. Там рассказывают о том, какие бывают активы, как их надо классифицировать.
Software Development Security и Security Assessment and Testing. Это знакомо нам как инженерам: там надо защищать разработку, думать про безопасность разработки, и соответственно, как мы любим говорить, доверяй, но проверяй. Обычно это делают автоматическими инструментами, встроенными в пайплайны, или независимыми тестированиями на проникновение.
Communication and Network Security. У нас есть данные, которые двигаются между нашими системами, и им нужно обеспечивать доступ. Надо защищать все эти данные, нетворк, по которому они передвигаются. Как это делать и о чем надо подумать — это довольно большой раздел того, чем занимается CISO.
Security Engineering. Это как раз та самая безопасная разработка, выбор стандартов шифрования, архитектурных подходов и так далее.
Identity and Access Management. Более или менее знаком любому, кто работает в энтерпрайзе. Связан с тем, как мы идентифицируем и выдаем доступ к физическим системам, и покрывает всё от того, как работает ваш бейдж, чтобы зайти в офис, до того, как работает многофакторная аутентификация на вашем VPN, решение, делать ее через какой нибудь OAuth-ключ, физический токен или через SMS.
Security Operations — менее понятный большинству раздел, используется в больших компаниях. Это всё, что связано с реагированием на инциденты. В больших и средних компаниях есть NOC (Network Operations Center) — ребята сидят, как в NASA, с мониторами, смотрят на большие экраны, серьезно наблюдают за системой и пытаются понять, на что надо нажать, если что-то упадет. Обычно такая же дисциплина и такой же Operation Center появляется и для безопасности. Прописываются процессы и то, о чем надо бы подумать и что сделать, чтобы у вас были нормальные Security Operations.
Security and Risk Management. Мы в самом начале говорили, что CISO появляются в компаниях, где занимаются безопасностью, потому что есть риски, если этим не заниматься. Там довольно стандартно и качественно описывается, как думать об этих рисках, и мы с экспертом поговорим об этом.
Вот что нужно знать кандидату, чтобы получить сертификацию. У каждого раздела есть свой процентный вес. Есть проходной балл, чтобы сдать любой экзамен, и здесь тоже. У каждой секции есть своя весовая оценка, мы смотрим сейчас на нее. 10% — на Asset Security, 13% — на Identity and Access Management и так далее. При помощи этой методологии индустрия безопасности образовывает своих кандидатов и помогает им развиваться.
Ж-shaped person
Барух: Вася на это всё смотрит и слегка офигевает, потому что из этой всей белиберды ему понятны два пункта: Software Development Security, как мы не делаем SQL-инъекции в нашем коде, и Security Engineering, как мы прикручиваем JFrog Xray и начинаем сканировать third-party dependencies. Он-то думал, он понимает в безопасности, а оказывается, всё, что он понимает, — это 22% от огромного мира, в котором он не понимает ничего. И тут Вася соображает, что когда он наймет себе CISO, то он своими руками создает новый колодец. Потому что этот CISO будет делать что-то, из чего он понимает пятую часть. Он будет что-то делать, а вся остальная организация, начиная с Васи, в этом ничего не понимает.
Леонид: Вася, сидя довольно высоко в организации, это осознает, потому что он боится репутационных рисков, и он видел, как его предыдущего работодателя хакнули и украли кучу кредитных карт. Но Вася вспоминает, как он трансформировал DevOps снизу организации. И прекрасно понимает, что его индивидуальным инженерам, которые еле успевают чинить баги и палить новые фичи, будет абсолютно не до того, как, о чем думает и о чем хочет пообщаться новый CISO Петя. И это довольно знакомая ситуация для Васи. Вася вспоминает, что, чтобы эффективно слить эти колодца, надо что-то делать, и он это уже делал. И мы будем говорить о том, как взять это важное, глубокое и сложное из колодца и интегрировать его в ваш product delivery pipeline так, чтобы оно не было колодцем и не сидело где-то с краю. Это та же трансформация, которую прошла наша индустрия до этого между Development, Operations Development и QA.
Барух: Итак, Вася офигевает от того, чем, оказывается, должен заниматься CISO. Но, с другой стороны, он знает, что такое Ж-shaped person.
У него руки формы Ж, и это очень знакомо, потому что это же DevOps. Вы же помните, что это команды, состоящие из Ж-shaped людей, у которых есть своя специализация, но, тем не менее, они понимают мир другого человека. И тут Вася вступает на путь понимания мира CISO.
The Cohen-Bradford IWA Model
Леонид: И делает он это через ту самую the Cohen-Bradford IWA Model (IWA — influence without authority), о которой мы довольно подробно рассказали на нашем прошлом докладе на DevOops. Если кто-то не смотрел, очень рекомендуем, потому что там мы рассказываем все 6 стадий от нахождения соратников по трансформации до понимания своих целей и понимания, чем же можно обменяться для того, чтобы создать симбиоз, как строить отношения в такой трансформации и о том, как делать трансформацию через give and take.
Сегодня мы остановимся на одной стадии этой модели, потому что для того, чтобы эффективно понять, как сшить колодцы и понять, что там происходит, нам надо диагностировать глубокий внутренний мир другой стороны. Это та часть модели, которая связана с безопасностью. Мы считаем, что надо раскрывать эту часть для работников нашей индустрии, потому что безопасность всегда сидела в стороне по сравнению с другими составляющими. Это понимание — то, что ведет к более эффективной работе вместе.
Глубокий внутренний мир
Если вы смотрели наши предыдущие доклады, то знаете, что мы с Барухом большие фанаты книги Дэниела Пинка «Драйв». В ней говорится, что для современной индустрии, где мы работаем не на станках, а головой, есть три ключевых аспекта, о которых надо подумать. Эти аспекты качественно мотивируют работника в индустрии:
- Autonomy — независимость от других.
- Mastery — возможность саморазвития.
- Purpose — наличие цели, ради которой мы все это делаем.
Барух и я любим добавить четвертую категорию — fear, то есть страх.
Это те четыре категории мотивации, о которых мы рассказываем и рекомендуем подумать, когда вы пытаетесь построить отношения со стороной, которую не до конца понимаете. Это то, при помощи чего можно диагностировать этот глубокий внутренний мир.
Барух: Посмотрим на строку security и выясним, какой у этих людей autonomy, master, purpose и чего они боятся. Autonomy — это, безусловно, быть в состоянии сделать лучше для организации в сфере их деятельности. То есть, если мы говорим про реактивную безопасность, про цикл «обнаружить — починить — задеплоить», то спецу по безопасности хотелось бы, чтобы он мог прийти и помочь. Обнаружить, починить и задеплоить, сделать это самому, таким образом сделать свою работу и чувствовать, что он приносит пользу.
Леонид: Mastery — тут тоже довольно понятно: мы показывали вам, сколько страниц надо прочитать, чтобы сдать экзамен на CISSP и сколько категорий нужно знать. Mastery тут достаточно. Себя можно развивать десятилетиями, причем можно углубляться в любую из этих категорий, потому что, если вы давно работаете в индустрии, вы наверняка натыкались на специалистов в любой из этих категорий от Identity Management до Security Operations. Саморазвития в индустрии хватает, потому что индустрия довольно широкая, обширная и молодая.
Барух: Ну и, безусловно, purpose у безопасников — это чувствовать себя защитником организации.
Information Security и думает о себе как о супергероях. Это супергерои, которые спасают организации от безруких инженеров и безголовых бизнесменов. Если мы понимаем это, то мы можем лучше понять, как подступиться к этим людям.
Риски
Леонид: Чтобы быть супергероем, надо оставаться супергероем, потому что самый большой страх человека, который занимается безопасностью, — что-то произойдет. После этого индустрия безопасности работает так, что, если что-то произошло, потом, особенно, если ты CISO, тебе вряд ли доверят защищать что-то другое. К сожалению, играя на защиту, ты должен быть прав 100% времени, а не один раз, как атакующая сторона.
А рисков много: репутационные, финансовые (штраф, деньги, которые надо вернуть), данные, которые надо оберегать, — это тоже дорого, страшно, но при этом всё должно быть доступно. Мы на мясокомбинате не сделаем бизнеса, если не будем вовремя продавать и быстро доставлять наши стейки. А тут еще есть много регуляций: Федеральный закон «О персональных данных», PCI DSS (Payment Card Industry Data Security Standard, Стандарт безопасности данных индустрии платежных карт), ISO 20000-1. В Штатах есть SOC 2 (Service and Organization Controls 2), стандартов куча и надо все их знать, они часто меняются. PCI поменялся год назад, и надо срочно что-то делать, потому что можно нечаянно потерять лицензию на обработку. Рисков и страхов у этого отдела и этой индустрии очень много.
Барух: Ты же понимаешь, что индустрия не новая и специалисты есть, и то, что для нас выглядит странно, для них — нет. Грубо говоря, вот эти все страхи — «нормально делай, нормально будет». Нужно тебе защищать — ну, защищай; надо тебе network security — ну, сделай network security, всё будет хорошо. В чем, собственно говоря, истерика?
Леонид: Проблема с такой защитой в том, что отдел безопасности должен быть прав и играть на защиту 100% времени, а векторов всяческих атак, даже самых элементарных векторов атак — полно. От них надо защищаться круглосуточно, а атакующей стороне надо всего лишь найти одно уязвимое место в категории. Не будем забывать, что у нас у всех есть тетя Валя из бухгалтерии, которая любит тыкать на ссылки, и этого часто достаточно, чтобы забраться во внутреннюю сеть компании. Конечно, «нормально делай, нормально будет» — это хорошо, но есть тот самый человеческий фактор, и тот самый surface area, та сфера, через которую можно атаковать компанию, и те методы, при помощи которых сегодня можно атаковать информационный бизнес.
Вернемся к CISSP
Барух: Тут мы еще раз суммируем: понятно, что ничего не понятно. Мы более или менее поняли, чем живут наши безопасники, но, тем не менее, хотелось бы немного разобраться, потому что, как вы понимаете, это важная часть.
Слава богу, мы не одни, у нас есть прекрасный эксперт — Денис Якимов, и он настоящий безопасник, не как мы. Он консультант по информационной безопасности, ведет очень крупный Telegram-канал, занимается имплементацией инструментов как раз в процессах DevOps.
Мы сейчас будем мучить Дениса вопросами, допрашивать его о непонятных нам вещах. И имеет смысл еще раз пройти по составляющим экзамена CISSP, чтобы понять, о чем вообще речь.
Леонид: Пойдем методически и попросим Дениса доступно рассказать нам, простым смертным инженерам, о чем же думает CISO, когда речь идет о разных категориях экзамена CISSP. И мы начнем с самой широкой категории — Security and Risk Management. Денис, а о чем вообще это всё?
Денис: Security Risk Management — речь идет о рисках. Если конкретно, то тут, наверное, проще оценить вообще логический процесс. Например, мы сначала провели модель угроз, но, я думаю, мы потом об этом побольше поговорим.
Леонид: Модель угроз — это паста, драйд, страйды?
Денис: На самом деле, в России, на мой взгляд, упомянутыми тобой методологиями оперируют нечасто. Но, в принципе, есть понятия риска и риск-менеджмента. Условно говоря, это процесс, по которому мы должны оценить риск. Это может быть количественная или качественная оценка. Предположим, есть пять серверов, и бизнес работает, если работают эти пять серверов, но есть угроза, реализация которой может с какой-то вероятностью вывести один из серверов. И мы можем оценить этот риск как таковой: например, взять вероятность падения сервера, оценить время ущерба при падении сервера и перевести все это в деньги. Например, количество минут, которые потеряет бизнес от того, что произойдет простой. CISSP описывает набор подходов, который объяснит, как оценить риск, как оценить ущерб и как подобрать меры защиты. Чтобы не пытаться спрятать или защитить актив за 100 долларов условной мерой защиты за 10 тысяч долларов.
Леонид: Иногда у меня создается впечатление, что ребята из безопасности мыслят черно-белыми категориями: они либо защитили, либо не защитили. То есть это про методологию, которая действительно помогает понять, где и как защищать, где концентрироваться, а где нет?
Денис: Методология лишь ориентир. Некоторые берут подход — отбрасывать все уязвимости с уровнем критичности ниже высокой и забивать на них. Мы не бросаемся на всё, что нашли наши сканеры или кто-то зарепортил, мы выбираем, что именно фиксить в первую очередь.
Леонид: Ух ты, а так можно? Я иногда встречался с ребятами из области безопасности, которые говорили: «Всё есть, мы сделали скан, вот вам список, чините». Более правильно к этому подходить — это действительно идентифицировать риски, идентифицировать цену и стоимость защиты от риска?
Денис: Конечно, сначала надо понять, что мы защищаем, какую потерю мы понесем, если это произойдет, а дальше отталкиваться от того, что защищать в первую очередь, что потом, может, вообще не надо ничего делать.
Леонид: То есть я как инженер, если хочу эффективно общаться с ребятами из безопасности, должен хотя бы вкратце понимать бизнес и что мы защищаем? Это хороший переход к следующему разделу экзамена CISSP: а что же мы вообще защищаем и как об этом думать. Там есть целый раздел Asset Security. Расскажи немного, что это такое и о чем там надо думать.
Денис: Конкретно с формулировкой Asset Security я сталкиваюсь впервые, я чаще видел Asset Assessment, когда мы сначала пытаемся определить, что мы защищаем. То есть мы определить должны для себя ассеты — активы, которые у нас есть и которые мы в первую очередь должны защитить. Это может быть…
Леонид: Ну, у нас мясокомбинат, то есть у нас есть коровы, стейки, туши.
Денис: От этого и отталкиваться. У нас есть туши — это наш ассет, у нас есть набор инструментов для разделки — тоже ассет. И нам нужно оценить, что важнее. Мы понимаем, что, если украдут инструмент, — потеряем 100 долларов, надо его купить. А если мы потеряем тушу, то возможно, будут репутационные потери. Короче говоря, сначала нужно определить, что для нас важно. Понятное дело, что раз для работы с этой тушей нужны данные клиентов и кредитки, то мы их будем защищать в первую очередь.
Леонид: Да, мы пытаемся понять, что у нас есть, что мы обрабатываем и какие риски от потери каждого класса ассетов.
Денис: Там условные сегменты PCI DSS, которые дают полную защиту для тех данных, где идет обработка банковских карт. Там, естественно, свой ассет, свои комплаенсы. В большинстве случаев делят примерно так: о, у нас там кредитки, давайте там PCI DSS — и начинают уже строить всё, что связанно с соответствующей регуляторкой.
Леонид: Следующий раздел этого CISSP — это громадный раздел Communication and Network Security, но мне показалось, там всё понятно. Безопасники поставили пароль для Wi-Fi, сделали VPN, а есть еще что-то интересное в этой области защиты коммуникаций?
Денис: Это всё, что попадает под взаимодействие. Также сюда может попасть и Istio, все эти знакомые истории для DevOps, TLS, это вопрос коммуникаций. И Zero Trust-подход (не отражено в CISSP), то есть мы никому не доверяем. Но суровая реальность говорит, что нам еще только к этому идти. Концепция Zero Trust — всё должно проверяться через аутентификацию и авторизацию, соединения должны проверяться — это просто как одна из деталей, про которую надо не забыть. Когда безопасно разворачиваем Kubernetes, мы не должны забыть про взаимодействие компонентов и задеплоенных микросервисов. Это дележка того, чем надо заняться.
Леонид: Zero Trust — интересная вещь, потому что у нас архитектура распределенных систем становится всё сложнее и сложнее, и я в последней работе занимался мониторингом. Ты начинаешь общаться с клиентом и понимаешь, что ребята, которые пишут распределенные системы в больших масштабах, просто не понимают, как эти компоненты сообщаются между собой. Zero Trust — это, судя по всему, интересная вещь.
Я знаю, Барух, ты же у нас член программного комитета на DevOops, у нас было много хороших докладов на эту тему, поэтому мы рекомендуем послушать. Очень полезная вещь, которая сейчас начинает развиваться быстрее. Ну вот, мы говорили про развертывание Kubernetes, защиту асетов, следующий раздел CISSP — это как раз Identity and Access Management. О чем это, кроме того, что выдали бейдж и пароль от электронной почты?
Денис: На самом деле, я не CISO, из своего опыта ничего не могу сказать. Это идентификация пользователей, увольнение сотрудника вовремя, умение выстроить процесс так, чтобы после увольнения все данные сотрудника автоматически порезались. Помимо того, что условно происходит в кластерах Kubernetes, за пределами, в инфраструктуре, куда вы нанимались, есть система, где создаются учетки, и система, которая удаляет эти учетки. И по бейджам физическая защита: зайти, приложить бейдж и уйти.
Леонид: Я правильно понимаю, что сегодня с трендом Zero Trust identity — не только у работников, клиентов, но еще и у участников архитектурной системы — Identity теперь расширяется. Не только люди, но и архитектурные компоненты начинают играть в этой сфере?
Денис: Да, раньше тоже так было. Есть системы, которые называются бастионами — это больше знакомо для людей. Это некоторый компонент, куда ты должен сначала подключиться, а потом подключиться дальше. Он записывает, что ты делаешь, даже если ты подключишься по RDP или SSH. Этот постоянный мониторинг, на самом деле, и раньше был, просто с концепцией Zero Trust он заключается в том, что поведение злоумышленника развивается до степени, когда он ищет любые возможности. И Zero Trust — это если он попал в сеть, где пять серверов общаются друг с другом, то злоумышленник получит доступы к этим пяти серверам. А Zero Trust ограничивает поверхность атаки. Это работает не только в нетворке, но и в выполняемых командных системных вызовах.
Леонид: Следующая категория — это Security Assessment and Testing. Это те самые хакеры, которых мы нанимаем, чтобы они проверили, не напортачили ли мы, это тот самый «доверяй, но проверяй», или это больше, чем пришел дядя Ваня и хакнул?
Денис: Понятно, что нам нужно проверять, что мы докрутили. Проверка может быть самой разной. Раньше мы бы позвали команду аудита с пентестом, и они пропентестят нам систему два раза в год. Пентест — это попытка найти максимум уязвимостей инфраструктуры в целом. Потом появляются такие вещи, как red team, и вся история с shift left security, DevSecOps, когда мы не только начинаем проверять в рамках пентеста, но и автоматически сканерами в рамках каждого релиза. Это проверка того, что всё ок.
Сейчас у нас появился технический прогресс, и мы включили ассессмент и тестирование в пайплайны. Есть еще понятие, когда аудит проводится в рамках комплаенса. Приходит аудитор, и ему надо проверить, что все действительно по комплаенсу, и только после этого он может выдать сертификат. Это всё попадает сюда же.
Леонид: Последняя категория — это тот самый Security Operations. Думаю, мы его пропустим. Это те ребята, которые сидят и смотрят в камеры наблюдения и следят, что происходит в бизнесе. У нас в чатике куча вопросов, и сейчас будем отвечать. Мы пока с Барухом попробуем сделать иллюстрацию того, как это всё можно свести на простом примере.
Batman’s threat model
Барух: Да, и пример будет — это Бэтмен и Брюс Уэйн. Тиффани Лью из MIT сделала прекрасный пример того, как строится threat-модель на примере Брюса Уэйна и Бэтмена. Для того чтобы понять, как это всё смоделировать, нам нужно понять, какие у нас есть ассеты, какие мы защищаем. В случае с Бэтменом у нас есть пещера, Альфред, электронная почта и текстовые сообщения, которые нужно защитить. С другой стороны, у нас есть угрозы: полиция, Джокер и другие злодеи и журналисты. Соответственно, эти угрозы представляют разный уровень рисков для наших ассетов. Некоторые из них менее страшны, потому что ассеты менее ценные, некоторые из них менее страшны, потому что угрозы слабее и наоборот: от более сильных ассетов и более сильных угроз, естественно, риски выше.
Леонид: Также риски могут отличаться тем, какие ассеты каким угрозам подвержены. И, делая threat-модель, мы пытаемся понять, например, что Бэткейв интересен Джокеру, но еще больше ему интересен Альфред, а переписка вообще неинтересна. Соответственно, понимание, какие ассеты подвергаются каким рискам, позволяет решить, куда вкладывать наши ограниченные ресурсы и как их защищать. И после того, как мы понимаем, что мы защищаем, от кого мы защищаем, мы делаем последнюю стадию threat-моделинга — это, соответственно, методы защиты.
Они, естественно, бывают разные в зависимости от того, что мы защищаем: физические ассеты мы защищаем камерами и бейджами, а электронные — шифрованием. И это как раз то, что элементарная threat-модель делает для любого бизнеса — это поможет любому из вас, кто занимается инженерией, общаться с секьюрити-командой, потому что понимание того, как они об этом думают, позволяет вам правильно подойти к решению какого-то вопроса и понять, откуда они вообще приходят с этими запросами. Но threat-модели бывают разные, да, Барух?
Барух: Это очень хорошо и важно, но самая большая проблема — это действительно понять, что ты защищаешь и что threat-модели бывают разные. Если Вася работает не на мясокомбинате, а на рыбокомбинате, то у него могут быть внезапно совершенно другие боли, и понять, что нельзя тупо пойти и скопировать threat-модель из одной организации в другую — это важно. И правильно оценить, что нужно защищать — это очень важно.
DevSecOps — это булшит
Мы забыли два самых близких сердцу Васи пункта. Это Security Engineering и Software Development Security. Они такие родные для Васи и для нас всех, потому что это же DevSecOps. Давайте я вам прямо скажу, что DevSecOps — это маркетинг булшит, как и диаграмма ниже.
Берем Development, QA, Operations, сливаем их вместе, получаем DevOps. А DevSecOps — это мы берем Development, Security, Operations и получается DevSecOps — ура-ура. Это все прекрасно для того, чтобы писать хайповые заголовки, но на самом деле это всё, конечно, ерунда. DevOps, как и DevSecOps — это не о том, чтобы создать несуществующее мифическое существо, которое будет понимать всё обо всём.
Леонид: На самом деле, мы с Барухом предпочитаем вариант, что DevSecOps — это все-таки культурная трансформация трех компонентов: это люди, процессы и инструменты. Это линза, через которую мы всегда смотрим на DevOps, и это то, о чем мы сегодня говорим: глубокое диагностирование мира безопасника, это как раз о людях.
Барух: Вы помните, как нам представляли DevOps — когда мы разрушаем эти стены, и Development и Operations вместо того, чтобы быть противниками, становятся друзьями. И мы говорили о том, что у Development и Operations противоположные мотивы. Operations хотят стабильности, а разработчики хотят все ломать, крушить и делать что-то новое. И мы решили, что у нас DevOps, у нас нет колодцев, и тут у нас внезапно свежачок — у нас теперь то же самое, только с секьюрити. Девелоперы хотят все ломать, секьюрити хотят стабильности, и из-за этого у нас и происходят неприятности. Например, у нас есть разработчики, которые пилят фичу на протяжении спринта, а потом к ним приходит CISO из конторы, который на самом деле юрист, а не технарь, и говорит: «Мы проверили security, и вот этой библиотекой пользоваться нельзя, у неё там неправильная лицензия. Но через неделю релиз никто не отменял, крутитесь как хотите, это не наши проблемы».
Shift left
Леонид: Да, и это мы уже где-то видели. Раньше в нашей индустрии, когда к нам в последний момент приходили тестировщики и говорили: «Баг нашли за час до релиза, надо все отменять». Что мы с этим сделали? Мы сделали так называемый shift left, то есть стали перетягивать все проверки, которые могут внести препятствия в наш pipeline flow, из девелопмента в продакшен влево.
Барух: И этот shift left для нас в первую очередь в техническом смысле. Что значит для security — вместо того, чтобы юристы проверяли зависимости за день до релиза, теперь мы это будем делать на код-ревью, намного чаще и раньше, или даже во время CI, или даже в IDE, совсем в руках разработчиков. Каждый раз, когда они добавляют новую зависимость, то эта зависимость проверяется на безопасность лицензии. Вот этот shift left от релиза прямо в клавиатуры разработчиков — то самое движение, которое помогает нам не оказаться в ситуации, когда у нас до релиза неделя и нам нужно все переписать, потому что у нас базовая зависимость, и ей внезапно запретили пользоваться.
Леонид: Похоже на то, что происходило с тестировщиками, но при этом и отличается от того, что происходило с тестировщиками. И отличается тем, что ребята, которые растут в безопасности, всегда раньше росли довольно далеко от процесса product development. И поэтому они в нем, скорее всего, очень мало понимают и очень часто они приходят в конце за день до релиза со своими вопросами.
Так происходит не потому, что они хотят прийти в последний день, а потому, что они не понимают, как работает product development в вашей организации. Я очень часто наблюдал это в своих командах и поэтому очень рекомендую: если у вас появляются такие симптомы, образуйте, научите команду безопасности, как работает процесс product development, какие у вас есть стадии спринт-планирования, принятия каких-то вещей в ваш процесс, чтобы они его лучше понимали и чтобы правильно могли найти время, место, митинги. Может быть, могли включиться в design-ревью, architecture-ревью, добавить что-то в баг-бэклог. Образуйте и научите их девелопмент-процессу, потому что вы будете удивлены, насколько они его не понимают.
Чтобы shift left произошел эффективно, им надо очень хорошо понимать ваш процесс product development. Также нужно, чтобы они вам доверяли, потому что люди, которые работают в области безопасности, не доверяют вам критерии своей работы. Сделайте так, чтобы они понимали, что происходит. Есть очень хорошая книжка Making Work Visible — помогите ребятам из безопасности понять, на каких стадиях находятся их запросы. Для них R&D представляется черной дырой: пофиксить уязвимость, и всё. Обучите их, как пользоваться вашей Jira. Это поможет им работать с вами более эффективно. Не забудьте, что надо обучить их тому, как у вас работает процесс product development.
Барух: Ну и, безусловно, shift left не может происходить без автоматизации. Потому что, если человек в состоянии просмотреть зависимости перед релизом, который происходит, допустим, раз в две недели — потому что это займет три дня, а три дня — это меньше, чем три недели. Как только мы делаем shift left, мы переходим к ситуации, когда человек физически не в состоянии сделать эту работу. Если каждый раз, когда я добавляю зависимость, у меня на компьютере надо проверить эту зависимость — то это не может уйти на approval, который занимает у безопасников две недели. Поэтому максимальная автоматизация этих процессов — это часть shift left. И тут такие инструменты, как проверка зависимости, уязвимости лицензии — это, как я уже упоминал, забыл правильно передать параметры в мой SQL-запрос, сделал там string computilation, нужно немедленно найти, и так далее. Это всё автоматизируется, и именно так этот shift left и может работать.
Bottlenecks
Леонид: Ну так же, как автоматизируются вещи c shift left, очень часто, особенно с compliance-ребятами, мы натыкаемся на проблему сертификации релизов. Мы не понимаем, как релизить быстрее, нам надо сертифицировать каждый релиз. Но на самом деле, никто никогда не говорил, что сертифицировать надо релизы, и ребятам, которые занимаются комплаенсом, достаточно посмотреть на фреймворки, чтобы был сертифицированный пайплайн. То есть автоматизируем не только scanning и detection, но и все, что мы делаем при помощи сертификации пайплайна. И это очень серьезный такой mess no more о том, что надо действительно ставить знак качества на каждый релиз. Можно на мясокомбинате проверить, что линия обработки мяса работает качественно, и этого достаточно.
Барух: Но с другой стороны, безусловно, картинка прекрасная, она иллюстрирует скрытую безработицу, то, как люди ленивы и так далее. На самом деле, нет: яма-то небольшая. В яму помещается один Вася. Все остальные ничего не делают не потому, что они ленивые, а потому что Вася, bottleneck, занял своей задницей всю яму, и больше туда никто не помещается. После того, как Вася раскопает эту яму до размеров, когда туда все смогут запрыгнуть, они все попрыгают туда и начнут впахивать вместе.
Так вот, про bottleneck. Существует мнение, что в нашем пайплайне тоже есть bottlenecks, которые связаны с security. Мы же не можем автоматизировать вообще все, что связано с нахождением в security. Мы можем автоматизировать только то, что мы знаем. Есть ли уязвимость в этой зависимости и так далее. Но есть еще те самые red teams и blue teams, есть аудиты, и эти операции выглядят блокирующими. Пока не прошел аудит, мы не можем двигаться. И тут неважно, как все автоматизировано слева или справа от этого аудита. Но тут тоже мы бы сказали, что есть некоторые вещи, которые должны изменяться.
Денис: У нас заканчивается время, но мне интересно всё равно вникнуть в историю по поводу shift left. Здесь не всё так тривиально.
Во-первых, есть вещи, которые автоматизировать до сих пор невозможно, и это статика. Потому что, во-первых, если мы будем просто делать статику в начале пайплайна, то это будут в итоге falls примерно на 70%. Я недавно искал статистику, даже самое дорогое решение из коробки будет фолзить больше половины. Соответственно, возникает вопрос: применимы ли правила внутри того же дорогущего чекмарка для нас? Не факт.
Поэтому мы вынуждены писать свои кастомные правила, нам необходимо триажить (разбирать) те уязвимости, которые выпали из статики, и это только первый момент. Вот в BSIMM, например, рассказывается, что вообще не всегда нужны эти shift left. Там даже есть такие вещи, как shift right и shift everywhere. В этом году вышла версия 11, и там говорится, что привязываться и фигачить всё в самом начале не обязательно, то есть, в принципе, можно делать проверки позже, но пусть они будут качественнее. И мне кажется, вот этот уровень зрелости, когда у нас вообще многие организации придерживаются shift left: давайте делать проверки на каждый коммит, будем проверять каждый коммит по пятьдесят минут, и бедные разработчики там повесятся. Нет, зачем, если мы можем проверять только в релиз, а может быть, еще позже. Пусть мы будем проверять позже, но проверка будет лучше, и мы не будем тратить время на разбор. То есть тут история длиною в жизнь.
Леонид: По-моему, Денис только что придумал тему для доклада на следующий DevOops.
Барух: Голову надо включать в направлении, которое мы хотим. И да, может быть, shift left — это не всё, может быть, нам нужен shift right или shift up. Но в итоге, если мы помним про нашу цель, что мы хотим более безопасные релизы чаще, то в общем-то такие вещи, как bottlenecks, можно решить. Например, можно делать процессы, которые выглядят как bottlenecks, во время разработки.
Помните, как мы решали проблему ручного тестирования? Что мы сначала написали, потом потестировали, и пока мы тестируем, ничего не происходит? Мы это потестировали, перенесли на то время вместе с написанием, назвали это explore to retesting. То, что мы нашли в это время, закодировали в юнит-тесты, и больше нам делать не надо. Тут очень похожие принципы. Мы можем делать этот discovery во время разработки, дальше кодировать дальнейшее нахождение регрессий этих discovery в security-тесты и так далее.
С щитом или на щите
Леонид: Время начинает подходить к концу, мы хотим поговорить еще про одну очень важную часть нашего дела. Потому что, чтобы это всё произошло, самое важное — это диагностика внутреннего мира, эмпатии и становления чемпионом безопасности.
Барух: Тут написано «с щитом или на щите», и действительно: Вася или все сотрудники безопасности помогают организации быть более безопасной, либо нам скоро придется искать новую работу. И для того, чтобы каждый из нас мог помогать безопасности, хотелось бы дать слово Денису, чтобы он нам рассказал, что же это реально значит, как каждый из нас может помочь сделать нашу организацию более безопасной.
Денис: Нам задают вопросы из разряда «как стать безопасником, если ты тестировщик или питонист, и как в это погрузиться», то, о чем мы говорили. На самом деле, не нужно пытаться сжевать всю безопасность. Нужно лишь взять тот кусок, которым вы занимаетесь, и просто копнуть чуть дальше в безопасность. Понять: а что, если я напишу нормальный код, может быть, я сделаю жизнь безопасника лучше? Организация увидит ваши старания и скажет, что вы чемпион безопасности. А в некоторых организациях это уже отдельная роль, дополнительные плюшки и первый шажок в сторону security. Продолжение — то, о чем мы говорили, это расширять кругозор и не так топорно делать то, что от вас хотят.
Леонид: А еще расширение кругозора может оказаться полезным с профессиональной и финансовой точки зрения. Те ребята, которые рано поняли, что DevOps никуда не уйдет, и начали это изучать и заниматься этим, сейчас ужасно востребованы. Сейчас специалистов тяжело найти, так же будет с безопасностью. Она придет, поэтому учитесь и пользуйтесь возможностью развивать собственный mastery, это поможет вам еще и с компенсацией.
Если ваше сердце неравнодушно и к DevOps как культуре, и к связанным с ней технологиям, вы попали по адресу! DevOops 2021 пройдет онлайн с 8 по 11 ноября. Во-первых, уже можно приобрести билет. А во-вторых, сейчас последние выходные, когда можно подать заявку на доклад и попасть на конференцию в качестве спикера — так что если вам есть что полезного рассказать собратьям по DevOps, откликайтесь!
