Security — как много в этом звуке для сердца девопсного слилось
Чтобы понять безопасность, надо думать как безопасник, вести себя как безопасник, стать безопасником. Барух 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 — это все-т
