4.1 Основы безопасности и культура

Обзор и мотивация

Безопасность не функция, которую прикручивают в конце, и не работа одной специализированной команды, сидящей отдельно от инженерии. В большой организации безопасность это свойство того, как проектируется, строится, эксплуатируется и управляется вся система. Когда тысячи инженеров поставляют код через сотни сервисов, самое слабое звено определяет, какой ущерб может нанести инцидент. Одно неверно настроенное хранилище, один непропатченный зависимый пакет или одна сервисная учётная запись с избыточными привилегиями могут открыть миллионы записей. Основы и культура то, что не даёт этому случиться в масштабе.

Для корпораций ставки финансовые и репутационные: стоимость утечек, регуляторные штрафы, потерянные клиенты и сниженная оценка. Для государства они простираются до национальной безопасности, общественного доверия и непрерывности важнейших услуг. Обе среды разделяют жёсткую истину: нельзя принудить безопасность одними средствами контроля и барьерами. Она должна быть усвоена людьми, делающими работу. Культура, где инженеры понимают угрозы, чувствуют ответственность и поощряются за поднятие тревог, даёт гораздо лучшие результаты, чем та, что опирается на перегруженную команду безопасности, играющую вратаря.

Эта глава излагает ментальные модели и культурные практики, лежащие в основе каждой другой главы по безопасности в этом руководстве. Она охватывает превращение безопасности в дело каждого, моделирование угроз, жизненный цикл безопасной разработки, основополагающие архитектурные принципы вроде эшелонированной защиты и нулевого доверия и то, как расставлять приоритеты работы по безопасности по реальному риску, а не по страху или моде.

См. также: главы 4.2 (безопасность приложений), 4.3 (безопасность инфраструктуры и облака), 4.4 (операции безопасности) и 4.6 (соответствие требованиям и управление) опираются на эти основы.

Ключевые принципы

Безопасность дело каждого. Каждый инженер, менеджер продукта и оператор отвечает за безопасность того, что строит. Команда безопасности помогает, консультирует и проверяет; она не делает и не может делать работу одна.
Предполагайте взлом. Проектируйте так, будто атакующие уже внутри. Минимизируйте то, до чего может дотянуться скомпрометированный компонент.
Эшелонированная защита. Ни одно средство контроля не достаточно. Наслаивайте независимые средства контроля, чтобы отказ одного не означал отказ всех.
Наименьшие привилегии. Предоставляйте минимум необходимого доступа на минимум необходимого времени и отзывайте его автоматически, когда он больше не нужен.
Сдвиг влево. Находите и исправляйте проблемы как можно раньше, когда это дешевле всего.
Приоритеты по риску. Тратьте усилия там, где сочетание вероятности и воздействия наивысшее, руководствуясь триадой CIA (конфиденциальность, целостность и доступность), а не тем, что попало в новости на этой неделе.
Обучение без обвинений. Воспринимайте инциденты безопасности и «чуть не» как возможности учиться, а не поводы для наказания.

Компромиссы: плюсы и минусы

Подход	Плюсы	Минусы
Центральная команда безопасности владеет всей безопасностью	Глубокая экспертиза, согласованные стандарты	Узкое место, инженеры отстраняются, не масштабируется
Распределённая безопасность (чемпионы)	Масштабируется, строит ответственность, быстрее обратная связь	Требует вложений, неравные навыки, нужна координация
Тяжёлое предварительное моделирование угроз для всего	Тщательно, ловит проектные дефекты	Замедляет поставку, может стать галочкой
Лёгкое моделирование угроз, нацеленное на риск	Быстро, сфокусировано на важном	Может упустить угрозы в «малорисковых» системах
Строгие барьеры, блокирующие выпуски	Принуждает к соответствию	Трение, подталкивает к обходным путям

Центральное напряжение между скоростью и гарантией. Склонитесь слишком к барьерам и центральному контролю, и вы создадите трение, которое инженеры обходят, порождая теневую ИТ и обиду. Склонитесь слишком к автономии без поддержки, и вы получите несогласованную непроверенную безопасность. Устойчивый ответ сильная культура с помогающими ограждениями: автоматизированными там, где можно, человеческими там, где нужно суждение, и всегда объяснёнными, а не просто навязанными.

Вопросы для обсуждения с командой

Какие из ваших систем заслуживают тяжёлого моделирования угроз и кто решает уровень? В большом хозяйстве нельзя запускать семистадийный анализ PASTA для каждого сервиса, поэтому нужно явное правило, когда достаточно 30-минутного прохода STRIDE, а когда высокоценная система заслуживает глубокого моделирования, управляемого воздействием на бизнес. Закрепите решение в вашей классификации CIA: системы, хранящие регулируемые записи, платёжные потоки или логику аутентификации, находятся наверху, а публичная маркетинговая страница нет. В корпоративной и государственной работе аудитор попросит вас обосновать, почему данная система моделировалась именно так, поэтому запишите критерии уровней и назовите владельца, который их применяет. Принесите на встречу вашу текущую классификацию активов и список сервисов без модели угроз, потому что разрыв между ними ваш реальный риск. Если вы не можете договориться о планке, вы по умолчанию будете моделировать всё поверхностно или ничего глубоко, и оба подведут вас.
Когда чемпион по безопасности и срок поставки сталкиваются, кто на самом деле может остановить выпуск? Программа чемпионов меняет результаты, только если у чемпиона есть настоящие полномочия, а не только дополнительное обучение и добрые намерения. Решите заранее, может ли чемпион заблокировать поставку, эскалирует ли он в центральную команду AppSec и какая серьёзность находки оправдывает остановку поставки против её отслеживания. Это важнее всего под давлением, когда менеджер продукта хочет освободить от исправления проектный дефект за неделю до запуска, а именно тогда неисправленные дефекты дороже всего исправлять. Принесите недавний пример, где соображение безопасности столкнулось со сроком, и проследите, кто решил и как, потому что эта история раскрывает ваш настоящий путь эскалации. Если честный ответ в том, что поставка всегда побеждает, ваши чемпионы декоративны, и вам следует исправить стимул, прежде чем добавлять новых.
Что конкретно меняет «предполагайте взлом» на вашем следующем рецензировании проекта? С принципом легко кивать и трудно его операционализировать, поэтому привяжите его к конкретным обязательствам: какие границы доверия вы ужесточите, где добавите микросегментацию и как сократите то, до чего может дотянуться одна скомпрометированная сервисная учётная запись. Для большой команды отдача в сокращении радиуса поражения, так что атакующий, попавший в один сервис, не может перейти к хранилищу данных за ним. В корпоративной и государственной среде это также определяет ваши решения о наименьших привилегиях и краткоживущих учётных данных, которые дёшево заложить в проект и болезненно дооснащать. Принесите одну настоящую диаграмму сервиса и спросите, что делает атакующий, овладев веб-уровнем, затем обязуйтесь внести два изменения локализации в этом квартале. Смутное согласие, что взломы случаются, бесполезно, пока оно не сдвигает разрешение, сетевое правило или срок жизни учётных данных.
Как вы узнаете, что ваша культура безопасности действительно улучшается, и какую метрику вы защитили бы перед советом директоров? Доли завершения обучения и число заявок легко собирать и они почти бесполезны, потому что измеряют активность, а не снижение риска, а большая организация в них тонет. Выберите метрики результата, на которые вы действительно поставили бы бюджет: медианное время устранения находок высокой серьёзности, доля сервисов с актуальной моделью угроз, доля инцидентов, пойманных до эксплуатации, и частота самостоятельно сообщаемых «чуть не», которая должна расти по мере роста доверия, а не падать. Конкурирующее соображение в том, что любую хорошую метрику можно обмануть, поэтому сочетайте каждую с контрметрикой и просматривайте тренд, а не снимок. Принесите вашу текущую панель и спросите, какие числа изменились бы, если бы безопасность действительно ухудшилась; те, что не изменились бы, декорация. В корпоративной и государственной среде регулятор или комитет по аудиту попросит свидетельства, что средства контроля работают, поэтому выбирайте метрики, которые можно защитить под пристальным вниманием, а не те, что просто выглядят зелёными.
Что на самом деле случится в следующий раз, когда инженер сообщит об ошибке, и бывает ли ваш процесс без обвинений на практике или только на слайде? Обучение без обвинений принцип, чаще всего провозглашаемый и реже всего исполняемый, потому что первый серьёзный инцидент проверяет, действительно ли руководство это имеет в виду. Решите заранее, как вы разделяете ответственность за исправление проблемы и наказание за её причинение и кто ведёт пост-инцидентный разбор, чтобы он оставался о сломанных системах, а не названных людях. Напряжение реально: заинтересованные стороны хотят, чтобы кто-то был признан виновным, но наказание сообщившего гарантирует, что следующая ошибка останется скрытой, пока не станет взломом. Принесите ваши последние два разбора инцидентов и проверьте, обвиняли ли они человека или средство контроля и поблагодарили ли инженера, поднявшего тревогу, или тихо отодвинули. Для государства и регулируемых корпораций обязательные правила раскрытия утечек поднимают ставки ещё выше, потому что культура, скрывающая ошибки, также пропустит сроки отчётности, несущие юридические штрафы.
Кто владеет трением ваших инструментов сдвига влево и покупаете ли вы их, строите или тонете в них? Автоматизированный статический и динамический анализ, сканирование зависимостей и сканирование секретов основа жизненного цикла безопасной разработки, но конвейер, заливающий инженеров ложными срабатываниями, учит их игнорировать вывод по безопасности, что хуже отсутствия сканирования. Решите, кто настраивает инструменты, кто сортирует находки и покупаете ли вы интегрированную платформу или собираете сканеры с открытым кодом, которые затем должны сопровождать сами. Конкурирующие соображения охват против шума и контроль против стоимости: дешёвый сканер, кричащий «волк!», сжигает доверие, на строительство которого программа чемпионов потратила годы. Принесите вашу текущую долю ложных срабатываний, среднее время, которое инженеры ждут блокирующую проверку, и список команд, тихо отключивших барьер. В больших корпорациях и государстве добавьте угол закупок и разрастания инструментов, потому что десять команд, каждая покупающая свой сканер, дают несогласованное покрытие, которое ни один аудитор не сможет свести.

Взгляд по секторам

Стартап. Без команды безопасности и при малом запасе времени культура ваше единственное доступное средство контроля. Сделайте 30-минутную доску для моделирования угроз привычкой перед любой функцией, касающейся аутентификации или платежей, включите наименьшие привилегии и MFA повсюду, потому что они ничего не стоят, и держите канал без обвинений, где любой может отметить тревогу. Пропустите тяжёлый процесс и инструменты; основатели-инженеры не смогут их сопровождать, а дисциплина, которую вы строите сейчас, то, что позже позволит корпоративным покупателям вам доверять.

Малый бизнес. У вас нет выделенного специалиста по безопасности и ограниченный бюджет, поэтому опирайтесь на безопасные значения по умолчанию в уже покупаемых инструментах, а не поднимайте собственный конвейер. Отдавайте предпочтение управляемым платформам, принуждающим к MFA, патчингу и наименьшим привилегиям за вас, и воспринимайте безопасность как вопрос гигиены данных: знайте, какие чувствительные данные вы держите и кто может до них дотянуться. Когда нужно выбирать «построить или купить», покупайте, потому что управляемое средство контроля, которое вы поддерживаете актуальным, лучше самодельного, которое вы даёте сгнить.

Крупная организация. В масштабе сотен сервисов и тысяч инженеров трудность в согласованности и управлении по многим командам. Ведите программу чемпионов по безопасности, стандартизируйте уровни моделирования угроз, привязанные к классификации CIA, и предоставляйте шаблоны «проторённой дороги» и автоматические проверки конвейера, чтобы каждая команда наследовала хорошие значения по умолчанию. Отслеживайте метрики устранения и покрытия относительно базовых значений и храните след аудита, показывающий, почему каждая система моделировалась и контролировалась именно так.

Государственный сектор. Правила закупок, обязательства прозрачности и публичная подотчётность определяют каждый выбор. Принципы нулевого доверия и краткоживущие учётные данные нередко предписываются исполнительной политикой, и вы должны уметь показать аудитору документированное основанное на риске обоснование того, куда пошёл бюджет на укрепление. Сначала приоритизируйте системы, хранящие наиболее чувствительные записи граждан, публикуйте меры защиты там, где у общества есть право знать, и требуйте от поставщиков раскрывать ограничения, а не принимайте непрозрачные чёрные ящики.

Примеры

Стартап. Стартап из десяти человек не имеет команды безопасности и бюджета на неё, поэтому два основателя-инженера делают моделирование угроз 30-минутной привычкой у доски перед любой функцией, касающейся аутентификации или платежей, спрашивая, что может пойти не так и кто хотел бы, чтобы это случилось. Они принимают несколько основополагающих привычек, ничего не стоящих: наименьшие привилегии на каждой облачной роли, MFA на каждой учётной записи и канал без обвинений, где любой может поднять тревогу, не боясь упрёков. Когда позже они привлекают раунд, а корпоративные покупатели спрашивают, как они относятся к безопасности, эта ранняя культура позволяет им ответить честно, а не метаться, изобретая её.

Крупная организация. Международный банк с 6000 инженеров ведёт программу чемпионов по безопасности с одним обученным чемпионом на отряд. Чемпионы посещают ежемесячную гильдию, проходят ежеквартальное обучение и ведут моделирование угроз для каждого нового сервиса методом STRIDE. Центральная команда AppSec поддерживает шаблоны «проторённой дороги» и автоматические проверки конвейера. За два года медианное время устранения находок высокой серьёзности упало с 45 дней до 9, а моделирование угроз на стадии проектирования поймало дефект авторизации в платёжном API до того, как он достиг эксплуатации, избежав вероятного подлежащего отчёту инцидента.

Государственный сектор. Национальное налоговое ведомство, модернизирующее унаследованные системы, принимает принципы нулевого доверия, предписанные исполнительной политикой. Каждый вызов внутреннего сервиса аутентифицируется краткоживущими учётными данными и авторизуется на каждый запрос; сетевые сегменты больше не дают доверия. Ведомство моделирует угрозы для каждого сервиса, обращённого к гражданам, по деревьям атак с корнями «вывести записи налогоплательщиков» и «изменить декларацию». Приоритизация по риску, выровненная по уровням воздействия CIA, направляет бюджет на укрепление сначала на системы, хранящие наиболее чувствительные записи.

Бизнес-обоснование: мотивы, ROI и TCO

Цена построения культуры безопасности реальна: время чемпионов, обучение, инструменты и скромное торможение от моделирования угроз и рецензий. Но эта цена мала рядом со стоимостью бездействия. Средняя крупная утечка данных обходится в миллионы, если считать расследование, уведомление, устранение, регуляторные штрафы, юридическую экспозицию и потерянный бизнес. Утечки в государстве добавляют срыв миссии и подрыв общественного доверия, которые не вмещает ни один счёт.

Отдача от вложений в безопасность приходит из трёх мест: избегнутые инциденты (взлом, которого не случилось), сниженная стоимость устранения (дефекты, исправленные на этапе проектирования, стоят долю тех, что исправляются в эксплуатации) и более быстрая поставка («проторённые дороги» и автоматические проверки позволяют командам поставлять уверенно, а не ждать ручного рецензирования). Обосновывая это перед руководством, формулируйте безопасность как управление рисками с ценником, а не абстрактное благо. Покажите ожидаемый ущерб (вероятность, умноженная на воздействие) главных рисков, стоимость их снижения и риск, который остаётся. Руководители финансируют снижение риска, которое могут измерить.

Антипаттерны и ловушки

Театр безопасности. Средства контроля, выглядящие впечатляюще, но не снижающие реального риска, принятые, чтобы удовлетворить аудит, а не чтобы что-то защитить.
Команда безопасности как барьер в конце. Обнаружение проектных дефектов за неделю до запуска, когда их дороже всего исправлять и вероятнее всего от них освободят.
Культура обвинений. Наказание инженера, сообщившего об ошибке, гарантирует, что следующая ошибка останется скрытой.
Моделирование угроз для галочки. Заполнение шаблона, который никто не читает, порождающее документы, оторванные от реальной архитектуры.
Единые средства контроля для всех. Применение одного и того же тяжёлого процесса к публичному сайту и платёжной системе, расточающее усилия и порождающее обиду.
Приоритизация по страху. Погоня за любой уязвимостью, модной в новостях, а не за тем, что действительно угрожает вашим активам.
Чемпионы только по имени. Назначение чемпионов без предоставления им времени, обучения или полномочий.

Модель зрелости

Уровень 1: Начальный. Безопасность реактивна и централизована. Рецензии происходят поздно, если вообще, и нет моделирования угроз. Инциденты порождают разовые исправления. Инженеры воспринимают безопасность как чужую проблему, и общего стандарта нет.

Уровень 2: Развитие. Команда безопасности существует и определяет стандарты, но практика непоследовательна между командами. Некоторое моделирование угроз происходит на крупных проектах и никакого на других. Базовое обучение доступно. Безопасность по-прежнему воспринимается как барьер, а сдвиг влево скорее намерение, чем реальность.

Уровень 3: Стандартизация. Чемпионы по безопасности встроены в каждую команду. Моделирование угроз рутинно для новых сервисов, разбито на уровни по классификации CIA, а жизненный цикл безопасной разработки документирован и соблюдается по организации. Приоритизация по риску направляет работу, стандарты безопасного кодирования и проверки конвейера это «проторённая дорога» по умолчанию, а пост-инцидентные разборы без обвинений норма.

Уровень 4: Управление. Результаты безопасности измеряются и контролируются относительно базовых значений. Организация отслеживает медианное время устранения находок высокой серьёзности, покрытие моделями угроз, долю инцидентов, пойманных до эксплуатации, и частоту сообщений о «чуть не» с разбивкой по командам. Полномочия чемпиона остановить выпуск определены и реально используются. Решения о рисках количественно выражены как вероятность, умноженная на воздействие, записаны и пересматриваются с установленной периодичностью, так что пробелы контроля проявляются как данные, а не как сюрпризы.

Уровень 5: Оркестрация. Безопасность действительно дело каждого и интегрирована с поставкой, риском и бизнес-планированием. Моделирование угроз и безопасное проектирование привычны и легки, а принципы нулевого доверия в основном реализованы. Метрики управляют непрерывным улучшением, организация учится на «чуть не» по командам, а средства контроля адаптируются автоматически по мере изменения картины угроз и архитектуры.

Идеи для обсуждения

Как вы измеряете, действительно ли культура безопасности улучшается, помимо подсчёта завершений обучения?
Где правильная граница между тем, что обрабатывают чемпионы по безопасности, и тем, чем владеет центральная команда?
Как сохранять моделирование угроз ценным, не давая ему стать бюрократической галочкой?
Реалистична ли полная архитектура нулевого доверия для вашего унаследованного хозяйства, а если нет, каково прагматичное подмножество?
Как следует расставлять приоритеты работы по безопасности относительно поставки функций, когда обе соперничают за одних и тех же инженеров?
Какие стимулы действительно меняют поведение инженеров в сторону ответственности за безопасность?

Главные выводы

Безопасность это культурное свойство больших организаций, а не задача, делегированная одной команде.
Чемпионы по безопасности масштабируют экспертизу и ответственность по инженерии.
Моделирование угроз (STRIDE, PASTA, деревья атак) выявляет проектные дефекты рано и дёшево.
Безопасный жизненный цикл разработки и мышление сдвига влево ловят дефекты, когда они стоят меньше всего.
Эшелонированная защита, наименьшие привилегии и нулевое доверие основополагающие архитектурные принципы.
Триада CIA и приоритизация по риску направляют дефицитные усилия туда, где они важнее всего.
Цена построения культуры безопасности гораздо меньше цены утечек, которые она предотвращает.

Источники и дополнительное чтение

Adam Shostack, Threat Modelling: Designing for Security
Ross Anderson, Security Engineering: A Guide to Building Dependable Distributed Systems
Michael Howard and Steve Lipner, The Security Development Lifecycle
Betsy Beyer et al. (Google), Building Secure and Reliable Systems
National Institute of Standards and Technology, SP 800-207: Zero Trust Architecture
National Institute of Standards and Technology, Secure Software Development Framework (SSDF), SP 800-218
OWASP, Threat Modelling and Security Champions guidance

4.1 Основы безопасности и культура

Обзор и мотивация

Ключевые принципы

Рекомендации

Учредите программу чемпионов по безопасности

Практикуйте моделирование угроз регулярно

Постройте жизненный цикл безопасной разработки программного обеспечения

Принимайте принципы архитектуры нулевого доверия

Расставляйте приоритеты по риску с помощью триады CIA