Безопасность во многих компаниях стоит особняком. Вместо того чтобы беспокоиться о качестве вашего продукта, безопасники твердят о ГОСТах и ISO, о разных сертификациях и авторизационных протоколах — вещах важных, но вне фокуса основного архитектора. При этом их деятельность «подрывает» производительность, debugability, да вообще все.
Однако есть способы сделать безопасность своим союзником на пути к качеству. В этой статье — о дихотомии разработки и безопасности. О том, что, вообще говоря, миры информационной безопасности и архитектуры ИТ-систем не столь далеки друг от друга, как может показаться. И что на самом деле практики безопасности пересекаются с практиками повышения качества кодовой базы, а ПО можно сделать безопасным без потери качества. Поскольку я сама довольно долго занималась системной разработкой, после чего ушла в безопасность и сейчас работаю в команде собственной микроядерной операционной системы «Лаборатории Касперского» KasperskyOS, то отлично знаю, что хотела бы услышать еще тогда, когда ИБ была для меня другой стороной :)
Меня всегда удивляло, что безопасность существует настолько обособленно. Если так подумать, security — это такой же quality-атрибут, как performance или scalability. Только для остальных quality-атрибутов обычно не выделяют специального человека, ими занимается архитектор. Кажется, для того чтобы быть безопасником, надо родиться с сертификатом ФСТЭК во рту вместо серебряной ложечки. Будучи системщиком, я каждый раз звала безопасников, понимая, что они могут предложить мне нечто совсем иное — тот взгляд, которого у меня нет.
Перейдя в «Лабораторию Касперского», я стала заниматься безопасной разработкой для безопасной операционной системы KasperskyOS (в компании, которая занимается безопасностью). И тут у меня уже не было шансов не заниматься безопасностью 😊 Тогда я обнаружила, что она бывает разная и что часть привычных разработчику quality-атрибутов пересекается с атрибутами безопасности, а в домене безопасности есть вещи, которые здорово помогают разработке (и в самой разработке есть вещи, которые при правильном употреблении помогают безопасности). Многие из этих вещей мне следовало бы знать раньше. Об этой дружбе миров я и хочу рассказать в своей статье.
Безопасность приходит всегда не вовремя.
Начну с того, как выглядит история про безопасность, не встроенная в общий процесс (а очень часто оказывается именно так), и почему так сложилось.
На самом деле безопасников никто не ждет.
Очень часто бывает, что безопасники не хотят думать об общем дизайне системы. Они приходят уже в конце разработки на стадии приемки или выходного тестирования и говорят: «Слушайте, у вас же тут авторизации нет!» Что в этот момент остается делать бизнесу? Только ответить: «Мы примем этот риск».
Обратная ситуация — когда безопасники без какого-либо злого умысла продавливают какие-то свои фичи, которые делают продукт или сервис нежизнеспособным. Например, нам нужно всеобщее шифрование и MFA, и неважно, что продукт не выйдет в срок или что мы просядем по производительности.
Бывает, что security-архитектора разрывают на части, потому что это носитель уникального знания, без которого нельзя сделать ни одной фичи. Его гриф требуется на каждый дизайн-ревью, потому что «мы до конца не знаем, но пока он не разрешил, точно нельзя».
А бывает, что безопасники говорят о реальных проблемах и предлагают их решения, но все это запихивают в бэклог. И даже при наличии практик работы с ним, это может оказаться security бэклог (то есть отдельная сущность).
Я хочу призвать ИТ и ИБ жить дружно. И для этого далее попытаюсь внести терминологическую ясность.
Однако перед этим остановлюсь на дисклеймере для небольших компаний, которые планируют начать заниматься безопасностью когда-нибудь потом, когда станут большим энтерпрайзом или будут переходить на государственный бюджет («нам бы сейчас сделать MVP», или в вольном переводе — «фигак-фигак и в продакшен»). Быстро прикрутить безопасность потом не получится. Об этом много написано в SRE-книгах от Google. Одну из них я очень люблю — Building secure and reliable Systems.
Некоторые вещи проще начать с самого начала. Об этом наборе практик мы и будем говорить дальше. Вкратце все это переводится как «нормально делай — нормально будет».
Миры ИТ и ИБ плохо стыкуются.
Конечно, это мое видение. Я не могу тут не процитировать Google, который не знает российской действительности. Но эти миры очень непохожи. Встретить безопасника, который понимает, как устроена нормальная продуктовая разработка (а не просто создание банального скрипта на Python), или архитектора, который понимает безопасность, — большая редкость. Если вы нашли такого человека — радуйтесь, это исключение, они не обязаны все это понимать. У них разный терминологический словарь, непересекающиеся карьерные треки и отличающиеся источники бюджетирования.
Ради интереса я залезла на сайт Бауманки, где есть одна из лучших магистерских программ по безопасности (ИУ8), и за 2 года обучения нашла там всего 51 академический час, посвященный разработке. И это не потому, что они ленивые или неправильно все понимают. Домен информационной безопасности огромен.
В информационной безопасности 400 с лишним специальностей. Там есть специалисты по сетям, криптографии и т. п. И они не могут полностью перекрываться.
Источник
Мы просто не успеваем учить безопасность на треках по ИТ и, наоборот, изучать нормальную разработку на треках по безопасности.
Второй момент — у нас по-разному «продается» качество.
В ИТ продажа качества — широкий вопрос. Если кто-то хочет продать лучший availability или scalability для сервиса, то он говорит о внесении новых цифр в SLA, чтобы следующая версия сервиса продавалась уже условно не за 90 долларов, а за 190 (маржа очевидна для product owner и бизнеса). Мы можем продать performance через размещение кричащих показателей бенчмарков в журналах, чтобы пользователи знали о том, какой быстрый продукт мы сделали.
Аналогично мы можем «продать качество», сославшись на развитие PR и HR-бренда. Компании/команде, где качеству отдают должное, легче привлечь кандидатов.
Но безопасники «продают качество» по-другому
Но главный способ продажи у безопасников — объяснить бизнесу, как много будет потеряно, если риск реализуется. И все это совсем не похоже на методы ИТ.
И в этот момент кажется, что пути ИТ и ИБ расходятся. Но на самом деле безопасность — это часть нашего общего понимания качества продукта, причем неотъемлемая.
Столь многогранное понятие security — это один из аспектов качества продукта. Стандарты и фреймворки, которые концентрируются на качестве, неизменно его упоминают, взять хотя бы ISO/IEC 25010.
ISO/IEC FCD 25010
При этом безопасность — это составной атрибут. Если посмотреть внутрь домена, обнаруживается, что те самые циферки availability, которые мы продаем через SLA, — тоже часть безопасности. Ведь один из главных постулатов говорит, что если секреты у вас защищены, но они недоступны, то они вам и не нужны (CIA triad).
Источник
А еще есть функциональная безопасность — одна из моих любимейших тем. По-русски слово то же самое — «безопасность», хотя по-английски это другое — safety. Функциональная безопасность предполагает корректное поведение в практически любых условиях: при ошибках ввода/вывода (причем не только от пользователя, но и повреждения файлов, потери при передаче и пр.), при отказе компонентов/сервисов, при ошибках окружения (посыпавшийся жесткий диск, закончившаяся память, утекшие файловые дескрипторы). Корректное поведение не всегда означает сохранение полной работоспособности, функционально безопасная система может в каких-то условиях перейти в degraded mode, а то и перегрузиться, но чаще стратегия реагирования состоит в откате на последнее известное состояние или передаче управления на реплику. Главное, предсказуемо и согласно спецификации :) И, смотрите, как это близко к классическому качеству кода, ведь тут и robustness, и fault-tolerance, и recoverability. Но это близко и классической безопасности, ведь система пытается «выстоять» против всех воздействий, в том числе и зловредов.
Идем дальше. Software Engineering Institute Carnegie Mellon University (SEI) формулирует тактики для нефункциональных quality-атрибутов. Тактика — это набор практик/подходов, чтобы прокачать в программном продукте какую-то характеристику. Если рассматривать безопасность как quality-атрибут, то мы видим, что восстановление после атаки требует ровно тех же сценариев и методов, которые мы используем при восстановлении после сбоя. Здесь availability и security сходятся как два родных брата.
https://resources.sei.cmu.edu/asset_files/TechnicalReport/2009_005_001_15101.pdf
Дальше — больше. OWASP анализирует баги и старается разбивать их по категориям. В 2021 году в ТОП-10 ввели два бага, которые, казалось бы, полностью относятся уже к архитектуре.
Иными словами, безопасники сказали, что, когда у вас есть работающий софт, который не только нормально написан, но также нормально спроектирован и нормально выкатывается на конвейер, это необходимая составляющая безопасности.
Переходя от теоретической близости к близости практической, отмечу несколько вещей в домене безопасности, которые очень полезны для простых архитекторов.
Начну с постулата, который цитируют многие безопасники:
То есть security — это вообще о том, что система ведет себя так, как и предполагалось.
И еще одна не менее знаменитая картинка, которую можно видеть в куче презентаций к докладам. Картинка о том, что есть реальное поведение программы и предполагаемое. Проблемы возникают, когда они не совпадают. И, кстати, интересный момент — традиционный quality assurance фокусируется на левой части расхождения: ожидаем поведение Х, получаем поведение Y. А пен-тестинг, тестирование на проникновение, больше думает о правой части — а может ли в системе в дополнение к ожидаемому поведению Х существовать скрытое поведение Z.
Кстати, и левая часть рисунка, традиционные отказы/баги, имеет прямое отношение к безопасности. Мы же слышали, что безопасники говорят об уязвимостях. А что есть уязвимость? Мне понравилась фраза в докладе одного бывшего коллеги о том, что уязвимость — это просто баг, которому повезло. Любой баг может стать уязвимостью.
Weakness — flaw in architecture or code
Vulnerability — exploitable weakness
https://2019.heisenbug-piter.ru/en/2019/spb/talks/1ocfsya5zgrvruv8vf2mmm/
Из этого следует, что безопасникам нужен код без багов, как и архитекторам. Каждый раз, когда вы удаляете код, где-то в мире рождается и радуется безопасник. Потому что в этот момент становится меньше уязвимостей. Просто подходы к этому в безопасности специфические.
Как же в ИБ достигают снижения числа уязвимостей/багов? ИБ предлагает безопасную разработку. Безопасная разработка — широкое поле, но вот ловите несколько тем, популярных в этом домене.
Первое — убрать из языков все то, что потенциально продуцирует баги. Вспомним про MISRA C, MISRA C++ — специальные стандарты, описывающие подмножество языка, которое можно использовать в системах с повышенными требованиями.
И не думайте, что это проблемы, специфичные для старых «недобрых» плюсов. Даже если мы пишем на языках с лучшим memory safety, чем у Си (а кажется, почти все языки более memory safe), для каждого из них и даже для каждого фреймворка есть более устойчивые паттерны, которые позволяют сделать код более надежным. Вот, например, гайд по безопасному кодированию на Java — SEI CERT Oracle Coding Standard for Java.
Итак, у нас есть понимание, что какие-то конструкции языка не сильно хороши. Что дальше? На вопрос о том, как эти гайды применить в жизнь, отчасти отвечает SDL — secure development lifecycle, придуманный в Microsoft.
Сделаю дисклеймер. Microsoft последние лет 15 молодцы с точки зрения безопасности. Когда-то давно мы называли Windows мастдаем, и только ленивый не смеялся над ее дырявостью. Но с тех времен они осознали репутационные риски и что просто прикрутить сверху антивирус недостаточно. Чтобы достичь безопасности, они меняли процесс разработки и предложили сложный цикл, из которого нам будут особенно полезны статический и динамический анализы, а также фаззинг.
Статический анализ — поиск нарушения правил безопасного кодирования на уровне анализа исходного кода. Статический анализ ловит множество ситуаций, которые фигурируют в гайдах. Он прекрасен на CI и (или) встроенный в IDE. А то, что не ловит статический анализ, помогает найти динамический анализ — инструментация кода дополнительными проверками. Динамический анализ находит нарушения memory safety, состояния гонок, утечки памяти и так называемое undefined behavior, которые так часто бывают источниками серьезных секурити-проблем.
Про фаззинг сейчас не могу рассказать, хотя нежно люблю его. Однако, у гугла, который много инвестирует в эту тему, есть не только инфраструктура и инструменты, но и набор документов, позволяющих в тему фаззинга «вкатиться».
Если бы меня попросили указать всего одну тактику безопасности, которая максимально полезна для других качеств программы, я бы назвала compartmentalization (как назвать его по-русски, я так и не придумала; возможно, подойдет «взаимная изоляция компонентов»).
https://resources.sei.cmu.edu/asset_files/TechnicalReport/2009_005_001_15101.pdf
Сейчас об этом паттерне много написано, например в Building secure and reliable systems.
Compartmentalization говорит о построении систем так, чтобы большая система не потонула целиком при протекании/повреждении одной ее части. Изоляция, отсеки, которые мы создаем, нужны не только, чтобы устоять во время атаки и не пустить злоумышленника дальше, но и для того, чтобы не распространять падение/отказ (по причине перегрузки, по причине ошибки при апдейте, по причине посыпавшегося жесткого диска — по любой).
В качестве отсеков/доменов изоляции могут выступать разные сущности с независимым доступом:
Compartmentalization решает множество задач. С точки зрения безопасности — это ограничение радиуса поражения. Но это также доступность (один перегруженный сегмент не выведет из строя всю систему) и resilience (вся система не откажет из-за одного компонента).
На самом деле есть еще история про availability и scalability — про то, что мы можем поддерживать высокую доступность.
Конечно, таких практик безопасности, которые изначально рассматриваются в ИБ, но при этом «на руку» разработчику и архитектору, сильно больше:
У ИБ и ИТ много взаимных интересов. И если к вам приходит безопасник и говорит: «Сделайте мне безопасную фичу», предложите ему вложить свои ресурсы, выделенные на безопасность, в хороший пайплайн разработки.
Посмотрим на ИБ- и ИТ-интересы и с другой стороны. В работе архитекторов тоже есть внушительный арсенал практик, которые изначально служат повышению качества, но также помогают безопасности.
Я поддерживаю широко идущий тренд Secure by design, сформулированный, например, в книге трех Дэнов — https://www.piter.com/product/bezopasno-by-design. Посыл прост: изначально надежный дизайн системы, позволяющий предотвратить ошибки, приводит к большей безопасности.
Иными словами, нормально делай — нормально будет. В смысле хорошо проектируй — безопасно будет.
Возьмем один пример из этой книги — Domain Driven Design (DDD). DDD на первый взгляд совершенно ортогонален безопасности, но вот смотрите. В DDD у нас есть такие понятия, как value и entities. Value — то, что не может измениться и характеризуется своим значением. Entity — то, что меняется и характеризуется своим ID (отвечает за операции над содержащимися values и entities).
Когда безопасность пропагандирует использование DDD в качестве основных доменных примитивов, мы получаем следующие несложные установки/правила:
Такие несложные, казалось бы, правила, решают две очень важные проблемы: распространение некачественных недоверенных данных по системе (угроза безопасности) и излишние проверки данных (снижение производительности). Ведь если от пользователя изначально пришли некачественные данные (случайно или злонамеренно), система должна быть устойчива. И проверять фамилию-имя-отчество на содержание SQL-инъекций лучше в самом начале, а не в середине процессинга и не в каждом его модуле (теряя производительность). DDD определяет очевидное место проверки входных данных — без избыточности и пропущенных валидаций.
Полезно также знать, что в безопасности есть представление о последовательности валидации входных данных.
Семантическая проверка занимает много времени. Поэтому первое, что проверяется, это origin (раньше это называлось allow-deny-списки) — откуда пришел запрос. Дальше можно проверить его размер, лексику, синтаксис и т. п. Эту пирамиду безопасники используют в том числе при фаззинговых проверках. И эта пирамида отлично ложится в разработку.
Следующий пример устремлений архитектора, востребованный для ИБ, — это debugability/способность системы к отладке. Казалось бы, debugability нужен только разработчикам, потому что именно им отлаживают всю систему. Многие хорошие разработчики начинают разработку системы с вопроса об отладке багов.
Один мой коллега, не только проектируя систему, но и покупая машину, задумывается о том, как он будет ее отлаживать, — где искать запчасти, как устранять проблему в дороге и т. п. В debugability входит комплекс тактик — как мы продетектрируем произошедшую ошибку, как мы донесем эту ошибку до тех, кто ее может устранить, как мы из ошибки распутаем цепочку до ее первопричины, чтобы эту первопричину устранить.
Как же такая сугубо техническая характеристика, как debugability, связана с безопасностью? Во-первых, весь список detect-ов можно напрямую найти в функциональной безопасности. А часть detect-ов пересекается с SOC-метриками. Во-вторых, диагностический инструментарий напрямую связан с временем релиза security hotfix, а значит, это составляющая такой важной метрики, как incident response time.
Многие требования безопасности повышают качество системы (практики безопасной разработки) и ее отказоустойчивость. С другой стороны, многие работы «на качество» повышают безопасность системы, даже рефакторинг может улучшить incident response time.
Я ни в коем случае не говорю, что вся безопасность должна идти только на поддержание качества (как и не все качество идет в пользу безопасности). Допустим, изменение coding style едва ли вызовет бурные овации безопасника. Но давайте искать то, что нас объединяет. Так, Security-команда может очень любить команду разработки за:
В общем, ИБ и ИТ, давайте жить дружно. Исторически миры ИТ и ИБ разошлись, но сейчас они сходятся, и нужно быть в тренде, находить эти пересечения.
В качестве готового рецепта в финале статьи советую завести регулярную встречу со своим security-архитектором уже со следующей недели. Просто чтобы знать, что у них происходит.
Если таких встреч у вас никогда не было, первым вопросом станет — а о чем нам поговорить. И я подготовила набор вопросов для этой беседы:
С этого можно начать беседу и выстраивать отношения.
А если вы хотите глубже погрузиться в то, как эти процессы реализованы у нас, а заодно самостоятельно поучаствовать в сближении мира ИТ и ИБ при разработке безопасной ОС, добро пожаловать в нашу команду KasperskyOS.
Дополнительная информация:
Однако есть способы сделать безопасность своим союзником на пути к качеству. В этой статье — о дихотомии разработки и безопасности. О том, что, вообще говоря, миры информационной безопасности и архитектуры ИТ-систем не столь далеки друг от друга, как может показаться. И что на самом деле практики безопасности пересекаются с практиками повышения качества кодовой базы, а ПО можно сделать безопасным без потери качества. Поскольку я сама довольно долго занималась системной разработкой, после чего ушла в безопасность и сейчас работаю в команде собственной микроядерной операционной системы «Лаборатории Касперского» KasperskyOS, то отлично знаю, что хотела бы услышать еще тогда, когда ИБ была для меня другой стороной :)
Меня всегда удивляло, что безопасность существует настолько обособленно. Если так подумать, security — это такой же quality-атрибут, как performance или scalability. Только для остальных quality-атрибутов обычно не выделяют специального человека, ими занимается архитектор. Кажется, для того чтобы быть безопасником, надо родиться с сертификатом ФСТЭК во рту вместо серебряной ложечки. Будучи системщиком, я каждый раз звала безопасников, понимая, что они могут предложить мне нечто совсем иное — тот взгляд, которого у меня нет.
Перейдя в «Лабораторию Касперского», я стала заниматься безопасной разработкой для безопасной операционной системы KasperskyOS (в компании, которая занимается безопасностью). И тут у меня уже не было шансов не заниматься безопасностью 😊 Тогда я обнаружила, что она бывает разная и что часть привычных разработчику quality-атрибутов пересекается с атрибутами безопасности, а в домене безопасности есть вещи, которые здорово помогают разработке (и в самой разработке есть вещи, которые при правильном употреблении помогают безопасности). Многие из этих вещей мне следовало бы знать раньше. Об этой дружбе миров я и хочу рассказать в своей статье.
Безопасность приходит всегда не вовремя.
Начну с того, как выглядит история про безопасность, не встроенная в общий процесс (а очень часто оказывается именно так), и почему так сложилось.
На самом деле безопасников никто не ждет.
Никто не ждет испанскую инквизицию и специалиста по безопасности — тоже.
Очень часто бывает, что безопасники не хотят думать об общем дизайне системы. Они приходят уже в конце разработки на стадии приемки или выходного тестирования и говорят: «Слушайте, у вас же тут авторизации нет!» Что в этот момент остается делать бизнесу? Только ответить: «Мы примем этот риск».
Обратная ситуация — когда безопасники без какого-либо злого умысла продавливают какие-то свои фичи, которые делают продукт или сервис нежизнеспособным. Например, нам нужно всеобщее шифрование и MFA, и неважно, что продукт не выйдет в срок или что мы просядем по производительности.
Бывает, что security-архитектора разрывают на части, потому что это носитель уникального знания, без которого нельзя сделать ни одной фичи. Его гриф требуется на каждый дизайн-ревью, потому что «мы до конца не знаем, но пока он не разрешил, точно нельзя».
А бывает, что безопасники говорят о реальных проблемах и предлагают их решения, но все это запихивают в бэклог. И даже при наличии практик работы с ним, это может оказаться security бэклог (то есть отдельная сущность).
Я хочу призвать ИТ и ИБ жить дружно. И для этого далее попытаюсь внести терминологическую ясность.
Однако перед этим остановлюсь на дисклеймере для небольших компаний, которые планируют начать заниматься безопасностью когда-нибудь потом, когда станут большим энтерпрайзом или будут переходить на государственный бюджет («нам бы сейчас сделать MVP», или в вольном переводе — «фигак-фигак и в продакшен»). Быстро прикрутить безопасность потом не получится. Об этом много написано в SRE-книгах от Google. Одну из них я очень люблю — Building secure and reliable Systems.
«The emergent nature of security and reliability means that design choices related to these considerations are often fairly fundamental… It’s usually difficult to “bolt on” security and reliability to an existing system… Accommodating security and reliability requirements in an existing system often requires significant design changes, major refactoring, or even partial rewritings…»
Некоторые вещи проще начать с самого начала. Об этом наборе практик мы и будем говорить дальше. Вкратце все это переводится как «нормально делай — нормально будет».
Камень раздора
Миры ИТ и ИБ плохо стыкуются.
Конечно, это мое видение. Я не могу тут не процитировать Google, который не знает российской действительности. Но эти миры очень непохожи. Встретить безопасника, который понимает, как устроена нормальная продуктовая разработка (а не просто создание банального скрипта на Python), или архитектора, который понимает безопасность, — большая редкость. Если вы нашли такого человека — радуйтесь, это исключение, они не обязаны все это понимать. У них разный терминологический словарь, непересекающиеся карьерные треки и отличающиеся источники бюджетирования.
Ради интереса я залезла на сайт Бауманки, где есть одна из лучших магистерских программ по безопасности (ИУ8), и за 2 года обучения нашла там всего 51 академический час, посвященный разработке. И это не потому, что они ленивые или неправильно все понимают. Домен информационной безопасности огромен.
В информационной безопасности 400 с лишним специальностей. Там есть специалисты по сетям, криптографии и т. п. И они не могут полностью перекрываться.
Источник
Мы просто не успеваем учить безопасность на треках по ИТ и, наоборот, изучать нормальную разработку на треках по безопасности.
Второй момент — у нас по-разному «продается» качество.
В ИТ продажа качества — широкий вопрос. Если кто-то хочет продать лучший availability или scalability для сервиса, то он говорит о внесении новых цифр в SLA, чтобы следующая версия сервиса продавалась уже условно не за 90 долларов, а за 190 (маржа очевидна для product owner и бизнеса). Мы можем продать performance через размещение кричащих показателей бенчмарков в журналах, чтобы пользователи знали о том, какой быстрый продукт мы сделали.
Аналогично мы можем «продать качество», сославшись на развитие PR и HR-бренда. Компании/команде, где качеству отдают должное, легче привлечь кандидатов.
Но безопасники «продают качество» по-другому
- Мы предотвратили 15 атак. Окей, а это много или мало? А сколько их всего было, а сколько прошло? А 20 человек в SOC для предотвращения атак — это не многовато ли будет.
- Мы прошли какую-то сертификацию. Сертификат — фактически плата за передачу ответственности. Кто не хочет брать на себя ответственность, покупает продукты с соответствующими лычками и переносит эту ответственность на разработчика сервиса/решения. И такие продукты стоят дороже.
- Мы публикуем результаты bug bounty, чтобы специалисты увидели, насколько мизерны атаки.
Но главный способ продажи у безопасников — объяснить бизнесу, как много будет потеряно, если риск реализуется. И все это совсем не похоже на методы ИТ.
И в этот момент кажется, что пути ИТ и ИБ расходятся. Но на самом деле безопасность — это часть нашего общего понимания качества продукта, причем неотъемлемая.
Безопасность как часть целого
Столь многогранное понятие security — это один из аспектов качества продукта. Стандарты и фреймворки, которые концентрируются на качестве, неизменно его упоминают, взять хотя бы ISO/IEC 25010.
ISO/IEC FCD 25010
При этом безопасность — это составной атрибут. Если посмотреть внутрь домена, обнаруживается, что те самые циферки availability, которые мы продаем через SLA, — тоже часть безопасности. Ведь один из главных постулатов говорит, что если секреты у вас защищены, но они недоступны, то они вам и не нужны (CIA triad).
Источник
А еще есть функциональная безопасность — одна из моих любимейших тем. По-русски слово то же самое — «безопасность», хотя по-английски это другое — safety. Функциональная безопасность предполагает корректное поведение в практически любых условиях: при ошибках ввода/вывода (причем не только от пользователя, но и повреждения файлов, потери при передаче и пр.), при отказе компонентов/сервисов, при ошибках окружения (посыпавшийся жесткий диск, закончившаяся память, утекшие файловые дескрипторы). Корректное поведение не всегда означает сохранение полной работоспособности, функционально безопасная система может в каких-то условиях перейти в degraded mode, а то и перегрузиться, но чаще стратегия реагирования состоит в откате на последнее известное состояние или передаче управления на реплику. Главное, предсказуемо и согласно спецификации :) И, смотрите, как это близко к классическому качеству кода, ведь тут и robustness, и fault-tolerance, и recoverability. Но это близко и классической безопасности, ведь система пытается «выстоять» против всех воздействий, в том числе и зловредов.
Идем дальше. Software Engineering Institute Carnegie Mellon University (SEI) формулирует тактики для нефункциональных quality-атрибутов. Тактика — это набор практик/подходов, чтобы прокачать в программном продукте какую-то характеристику. Если рассматривать безопасность как quality-атрибут, то мы видим, что восстановление после атаки требует ровно тех же сценариев и методов, которые мы используем при восстановлении после сбоя. Здесь availability и security сходятся как два родных брата.
https://resources.sei.cmu.edu/asset_files/TechnicalReport/2009_005_001_15101.pdf
Дальше — больше. OWASP анализирует баги и старается разбивать их по категориям. В 2021 году в ТОП-10 ввели два бага, которые, казалось бы, полностью относятся уже к архитектуре.
OWASP Top-10: A04 – insecure design
«A new category for 2021 focuses on risks related to design and architectural flaws, with a call for more use of threat modelling, secure design patterns, and reference architectures. As a community we need to move beyond «shift-left» in the coding space to pre-code activities that are critical for the principles of Secure by Design»
OWASP Top-10: A08 – software and data integrity failures
«A new category for 2021 focuses on making assumptions related to software updates, critical data, and CI/CD pipelines without verifying integrity»
Иными словами, безопасники сказали, что, когда у вас есть работающий софт, который не только нормально написан, но также нормально спроектирован и нормально выкатывается на конвейер, это необходимая составляющая безопасности.
Практики безопасности на страже качества
Переходя от теоретической близости к близости практической, отмечу несколько вещей в домене безопасности, которые очень полезны для простых архитекторов.
«Безопасная» разработка
Начну с постулата, который цитируют многие безопасники:
Security — «the property that a system behaves as expected». G. Spafford
То есть security — это вообще о том, что система ведет себя так, как и предполагалось.
И еще одна не менее знаменитая картинка, которую можно видеть в куче презентаций к докладам. Картинка о том, что есть реальное поведение программы и предполагаемое. Проблемы возникают, когда они не совпадают. И, кстати, интересный момент — традиционный quality assurance фокусируется на левой части расхождения: ожидаем поведение Х, получаем поведение Y. А пен-тестинг, тестирование на проникновение, больше думает о правой части — а может ли в системе в дополнение к ожидаемому поведению Х существовать скрытое поведение Z.
Кстати, и левая часть рисунка, традиционные отказы/баги, имеет прямое отношение к безопасности. Мы же слышали, что безопасники говорят об уязвимостях. А что есть уязвимость? Мне понравилась фраза в докладе одного бывшего коллеги о том, что уязвимость — это просто баг, которому повезло. Любой баг может стать уязвимостью.
Weakness — flaw in architecture or code
Vulnerability — exploitable weakness
https://2019.heisenbug-piter.ru/en/2019/spb/talks/1ocfsya5zgrvruv8vf2mmm/
«If you try to determine whether something is exploitable, it is highly likely that you will get it wrong. In most cases, it is only possible to prove that something is either exploitable or that you are not smart enough (or possibly have not spent enough time) to determine how to write an exploit».
Из этого следует, что безопасникам нужен код без багов, как и архитекторам. Каждый раз, когда вы удаляете код, где-то в мире рождается и радуется безопасник. Потому что в этот момент становится меньше уязвимостей. Просто подходы к этому в безопасности специфические.
Как же в ИБ достигают снижения числа уязвимостей/багов? ИБ предлагает безопасную разработку. Безопасная разработка — широкое поле, но вот ловите несколько тем, популярных в этом домене.
Первое — убрать из языков все то, что потенциально продуцирует баги. Вспомним про MISRA C, MISRA C++ — специальные стандарты, описывающие подмножество языка, которое можно использовать в системах с повышенными требованиями.
И не думайте, что это проблемы, специфичные для старых «недобрых» плюсов. Даже если мы пишем на языках с лучшим memory safety, чем у Си (а кажется, почти все языки более memory safe), для каждого из них и даже для каждого фреймворка есть более устойчивые паттерны, которые позволяют сделать код более надежным. Вот, например, гайд по безопасному кодированию на Java — SEI CERT Oracle Coding Standard for Java.
Итак, у нас есть понимание, что какие-то конструкции языка не сильно хороши. Что дальше? На вопрос о том, как эти гайды применить в жизнь, отчасти отвечает SDL — secure development lifecycle, придуманный в Microsoft.
Сделаю дисклеймер. Microsoft последние лет 15 молодцы с точки зрения безопасности. Когда-то давно мы называли Windows мастдаем, и только ленивый не смеялся над ее дырявостью. Но с тех времен они осознали репутационные риски и что просто прикрутить сверху антивирус недостаточно. Чтобы достичь безопасности, они меняли процесс разработки и предложили сложный цикл, из которого нам будут особенно полезны статический и динамический анализы, а также фаззинг.
Статический анализ — поиск нарушения правил безопасного кодирования на уровне анализа исходного кода. Статический анализ ловит множество ситуаций, которые фигурируют в гайдах. Он прекрасен на CI и (или) встроенный в IDE. А то, что не ловит статический анализ, помогает найти динамический анализ — инструментация кода дополнительными проверками. Динамический анализ находит нарушения memory safety, состояния гонок, утечки памяти и так называемое undefined behavior, которые так часто бывают источниками серьезных секурити-проблем.
Про фаззинг сейчас не могу рассказать, хотя нежно люблю его. Однако, у гугла, который много инвестирует в эту тему, есть не только инфраструктура и инструменты, но и набор документов, позволяющих в тему фаззинга «вкатиться».
Compartmentalization
Если бы меня попросили указать всего одну тактику безопасности, которая максимально полезна для других качеств программы, я бы назвала compartmentalization (как назвать его по-русски, я так и не придумала; возможно, подойдет «взаимная изоляция компонентов»).
https://resources.sei.cmu.edu/asset_files/TechnicalReport/2009_005_001_15101.pdf
Сейчас об этом паттерне много написано, например в Building secure and reliable systems.
Compartmentalization говорит о построении систем так, чтобы большая система не потонула целиком при протекании/повреждении одной ее части. Изоляция, отсеки, которые мы создаем, нужны не только, чтобы устоять во время атаки и не пустить злоумышленника дальше, но и для того, чтобы не распространять падение/отказ (по причине перегрузки, по причине ошибки при апдейте, по причине посыпавшегося жесткого диска — по любой).
В качестве отсеков/доменов изоляции могут выступать разные сущности с независимым доступом:
- классические сегменты сети;
- независимые дата-центры (полностью независимый деплой). С точки зрения безопасности важно, чтобы права в одном дата-центре не распространялись автоматически на права в другом дата-центре;
- ячеистая структура сервиса.
Compartmentalization решает множество задач. С точки зрения безопасности — это ограничение радиуса поражения. Но это также доступность (один перегруженный сегмент не выведет из строя всю систему) и resilience (вся система не откажет из-за одного компонента).
На самом деле есть еще история про availability и scalability — про то, что мы можем поддерживать высокую доступность.
Конечно, таких практик безопасности, которые изначально рассматриваются в ИБ, но при этом «на руку» разработчику и архитектору, сильно больше:
- Повышенное покрытие тестами.
- Статический, динамический анализы, фаззинг-тестирование и даже (полу)формальная верификация.
- Проверка входных аргументов во всех комбинациях, taint analysis.
- Качественный pipeline (чтобы включить DevSecOps).
- Обязательное code review (и наличие secure coding guideline).
- Throttling/rate-limiting.
У ИБ и ИТ много взаимных интересов. И если к вам приходит безопасник и говорит: «Сделайте мне безопасную фичу», предложите ему вложить свои ресурсы, выделенные на безопасность, в хороший пайплайн разработки.
Архитектурные тактики в помощь безопасности
Посмотрим на ИБ- и ИТ-интересы и с другой стороны. В работе архитекторов тоже есть внушительный арсенал практик, которые изначально служат повышению качества, но также помогают безопасности.
Я поддерживаю широко идущий тренд Secure by design, сформулированный, например, в книге трех Дэнов — https://www.piter.com/product/bezopasno-by-design. Посыл прост: изначально надежный дизайн системы, позволяющий предотвратить ошибки, приводит к большей безопасности.
«Security issues are often perceived as scary and complicated, but when using the design approach, the complexity suddenly disappears. This is primary because the distinction between security bug and ordinary bugs is erased when focus is placed on the domain rather than on which countermeasures to use».
Иными словами, нормально делай — нормально будет. В смысле хорошо проектируй — безопасно будет.
Domain Driven Design (DDD)
Возьмем один пример из этой книги — Domain Driven Design (DDD). DDD на первый взгляд совершенно ортогонален безопасности, но вот смотрите. В DDD у нас есть такие понятия, как value и entities. Value — то, что не может измениться и характеризуется своим значением. Entity — то, что меняется и характеризуется своим ID (отвечает за операции над содержащимися values и entities).
Когда безопасность пропагандирует использование DDD в качестве основных доменных примитивов, мы получаем следующие несложные установки/правила:
- DDD-values проверяют инварианты в момент их конструирования. Например, если мы описываем тип идентификатора печатного издания (ISBN), то проверка валидности формата (наличие там SQL-инъекций) осуществляется непосредственно при создании.
- Для DDD-values нельзя использовать простой встроенный тип (например, string или int).
- DDD-entities имеют валидацию при построении объекта и при том ограниченном варианте изменений, которые предполагает бизнес-логика.
Такие несложные, казалось бы, правила, решают две очень важные проблемы: распространение некачественных недоверенных данных по системе (угроза безопасности) и излишние проверки данных (снижение производительности). Ведь если от пользователя изначально пришли некачественные данные (случайно или злонамеренно), система должна быть устойчива. И проверять фамилию-имя-отчество на содержание SQL-инъекций лучше в самом начале, а не в середине процессинга и не в каждом его модуле (теряя производительность). DDD определяет очевидное место проверки входных данных — без избыточности и пропущенных валидаций.
Полезно также знать, что в безопасности есть представление о последовательности валидации входных данных.
Семантическая проверка занимает много времени. Поэтому первое, что проверяется, это origin (раньше это называлось allow-deny-списки) — откуда пришел запрос. Дальше можно проверить его размер, лексику, синтаксис и т. п. Эту пирамиду безопасники используют в том числе при фаззинговых проверках. И эта пирамида отлично ложится в разработку.
Debugability
Следующий пример устремлений архитектора, востребованный для ИБ, — это debugability/способность системы к отладке. Казалось бы, debugability нужен только разработчикам, потому что именно им отлаживают всю систему. Многие хорошие разработчики начинают разработку системы с вопроса об отладке багов.
Один мой коллега, не только проектируя систему, но и покупая машину, задумывается о том, как он будет ее отлаживать, — где искать запчасти, как устранять проблему в дороге и т. п. В debugability входит комплекс тактик — как мы продетектрируем произошедшую ошибку, как мы донесем эту ошибку до тех, кто ее может устранить, как мы из ошибки распутаем цепочку до ее первопричины, чтобы эту первопричину устранить.
Как же такая сугубо техническая характеристика, как debugability, связана с безопасностью? Во-первых, весь список detect-ов можно напрямую найти в функциональной безопасности. А часть detect-ов пересекается с SOC-метриками. Во-вторых, диагностический инструментарий напрямую связан с временем релиза security hotfix, а значит, это составляющая такой важной метрики, как incident response time.
Выводы
Многие требования безопасности повышают качество системы (практики безопасной разработки) и ее отказоустойчивость. С другой стороны, многие работы «на качество» повышают безопасность системы, даже рефакторинг может улучшить incident response time.
Я ни в коем случае не говорю, что вся безопасность должна идти только на поддержание качества (как и не все качество идет в пользу безопасности). Допустим, изменение coding style едва ли вызовет бурные овации безопасника. Но давайте искать то, что нас объединяет. Так, Security-команда может очень любить команду разработки за:
- DFD-, LLD-диаграммы, потому что они могут использоваться для моделирования угроз;
- низкий coupling и высокий cohesion, чтобы реализовать least privilege, поскольку эта история нужна для безопасности;
- быстрый CI/CD, чтобы быстро выкатить security hotfix (или правильный upgrade).
В общем, ИБ и ИТ, давайте жить дружно. Исторически миры ИТ и ИБ разошлись, но сейчас они сходятся, и нужно быть в тренде, находить эти пересечения.
В качестве готового рецепта в финале статьи советую завести регулярную встречу со своим security-архитектором уже со следующей недели. Просто чтобы знать, что у них происходит.
Если таких встреч у вас никогда не было, первым вопросом станет — а о чем нам поговорить. И я подготовила набор вопросов для этой беседы:
- Какие практики безопасного кодирования рекомендуются в компании? Есть ли гайд?
- Какие средства SAST/DAST/IAST у нас закуплены? И можно ли и нам пару лицензий на конвейер?
- Где можно посмотреть модель угроз для нашей системы? Что есть наш TCB и какие главные asset’ы?
- Какие события от нашей системы сойдут за security alert и куда их репортить?
С этого можно начать беседу и выстраивать отношения.
А если вы хотите глубже погрузиться в то, как эти процессы реализованы у нас, а заодно самостоятельно поучаствовать в сближении мира ИТ и ИБ при разработке безопасной ОС, добро пожаловать в нашу команду KasperskyOS.
Дополнительная информация:
- https://www.microsoft.com/en-us/securityengineering/sdl
- https://developers.redhat.com/topics/security
- https://insights.sei.cmu.edu/blog/topics/cybersecurity-engineering/
