Инструменты методики АЦТ, часть 47: безопасная разработка (DevSecOps), безопасность интернета вещей (IoT Security), операционная технологическая безопасность (OT Security) и активный поиск угроз (Threat Hunting)

ОтДепартамент аналитики АЦТ

Это сорок седьмая статья цикла по инструментам методики «Аккордная цифровая трансформация». Завершаем группу I «Кибербезопасность и управление рисками» подгруппой I3 «Промышленные и IoT-решения» и открываем I4 «Аналитика и расследования» — инструменты I3-01, I3-02, I3-03 и I4-01.

Четыре инструмента этой статьи переносят кибербезопасность из области общих правил в область конкретных технических сред. Безопасная разработка (I3-01) встраивает проверки защищенности в сам процесс создания программного обеспечения, а не добавляет их после. Безопасность интернета вещей (I3-02) защищает устройства, которые массово подключаются к сети и массово же остаются без присмотра. Операционная технологическая безопасность (I3-03) защищает системы, управляющие физическими процессами — станками, насосами, центрифугами, — а не данными. Активный поиск угроз (I4-01) исходит из предположения, что средства автоматического обнаружения уже пропустили атакующего, и ищет его следы вручную. Трудоемкость составляет 36 часов у безопасной разработки, 36 часов у безопасности интернета вещей, 46 часов у операционной технологической безопасности и 38 часов у активного поиска угроз. Все четыре инструмента отнесены методикой к сложным. В сумме 156 часов.

I3-01 — Безопасная разработка (Development Security Operations, DevSecOps)

Откуда появился инструмент. Термин связывают с 2014 годом и с именем Шеннон Литц, занимавшей на тот момент должность в компании Intuit. Подход вырос из более раннего движения «сдвига влево», зародившегося около 2012 года и призывавшего переносить проверки качества на более ранние этапы разработки. Свою роль сыграла и практика DevOps, которая к середине 2010-х стала стандартом отрасли и лишила традиционные службы безопасности прежнего права в одиночку останавливать выпуск продукта. В 2015 году Литц вместе с коллегами по Intuit сформулировала манифест DevSecOps, закрепивший идею коллективной ответственности за безопасность. Точное происхождение термина остается предметом споров даже среди специалистов отрасли: если авторство термина DevOps единодушно приписывают Патрику Дебуа, то в случае DevSecOps источники расходятся.

Суть и механика. Подход интегрирует процессы безопасности на всех этапах жизненного цикла программного обеспечения, от проектирования до развертывания. В основе методики — принцип «Secure by Design»: системы изначально разрабатываются с учетом строгих требований безопасности. Методика выделяет три принципа. Автоматизированные проверки вместо ручного контроля: статический анализ кода выявляет уязвимости в исходном тексте программы, динамическое тестирование проверяет уже работающее приложение. Ранний поиск уязвимостей: чем раньше найдена уязвимость, тем проще и дешевле ее исправить. Коллективная ответственность за безопасность: в DevSecOps ею занимаются не только специалисты по безопасности — разработчики пишут более защищенный код, специалисты по эксплуатации настраивают безопасную инфраструктуру, тестировщики проверяют функциональность и потенциальные уязвимости одновременно.

Цену позднего обнаружения дефекта видно на редком в отрасли случае, когда популярную статистику пришлось публично опровергнуть.

Пример. Годами в статьях о безопасной разработке кочует утверждение, что исправление дефекта после выпуска продукта обходится в сто раз дороже, чем на этапе проектирования, — со ссылкой на некий «Институт системных наук IBM». В 2021 году специалист по методологии разработки Лоран Боссави проверил источник этой цифры и обнаружил, что подобного института попросту не существует: под этим названием скрывалась внутренняя учебная программа для сотрудников IBM, а данные, стоящие за широко растиражированным графиком, остались неподтвержденными. Тем не менее у самого утверждения есть законная, рецензируемая основа. В 2001 году Барри Боэм и Виктор Базили опубликовали в журнале IEEE Computer статью, показавшую, что для крупных проектов стоимость исправления ошибки после поставки действительно может возрастать примерно в сто раз по сравнению с этапом проектирования. Для небольших некритичных проектов это соотношение ближе к пяти к одному, а не к ста.

Разница между мифом и рецензируемым исследованием состоит не в направлении вывода — оба говорят, что раннее исправление дешевле, — а в том, что настоящее исследование честно называет условие, при котором цифра в сто раз верна, тогда как выдуманный источник представляет ее как универсальную константу.

Границы применимости. Инструмент применим при разработке любого программного обеспечения, где цена дефекта, обнаруженного после выпуска, существенно выше цены его обнаружения на этапе разработки. По методике это сложный инструмент. Первое ограничение касается масштаба выгоды: соотношение затрат на исправление дефекта на разных этапах сильно зависит от размера и критичности проекта, и перенос выводов с крупных систем на небольшие приложения переоценивает экономию. Второе — культурный барьер: коллективная ответственность за безопасность требует изменения привычек разработчиков, тестировщиков и специалистов по эксплуатации одновременно, а не установки одного инструмента. Третье — ложные срабатывания автоматических проверок: статический и динамический анализ кода нередко указывают на дефекты, не являющиеся реальными уязвимостями, и без настройки инструментов под конкретный проект это подрывает доверие команды к самой практике. Безопасная разработка опирается на облачную безопасность (I2-01) как на среду развертывания и служит источником более защищенного исходного кода для операционной технологической безопасности (I3-03) там, где промышленное программное обеспечение создается самим предприятием.

Чек-лист перед внедрением безопасной разработки:

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

Типовые ошибки:

  • Перенос выводов без учета масштаба. Ожидаемая экономия от раннего обнаружения дефектов рассчитывается по показателям крупных проектов для небольшого приложения. → Оценивать масштаб и критичность конкретного проекта при расчете ожидаемой выгоды.
  • Безопасность как задача одного отдела. Ответственность за безопасность остается на специалистах по безопасности, остальные участники команды не вовлечены. → Распределять ответственность между разработчиками, эксплуатацией и тестировщиками.
  • Игнорирование ложных срабатываний. Автоматические проверки настроены без учета специфики проекта и выдают избыточное количество ложных предупреждений. → Настраивать инструменты анализа под конкретный проект и разбирать ложные срабатывания.
  • Внедрение без измерения результата. Практики DevSecOps вводятся без отслеживания, на каком этапе на самом деле обнаруживаются дефекты. → Измерять долю дефектов, найденных на ранних этапах, до и после внедрения.

I3-02 — Безопасность интернета вещей (IoT Security Framework)

Откуда появился инструмент. Толчком к формированию дисциплины как отдельного направления послужила атака ботнета Mirai в 2016 году. Вредоносная программа заражала устройства интернета вещей — домашние маршрутизаторы, камеры видеонаблюдения, видеорегистраторы, — использующие заводские пароли по умолчанию, и превращала их в сеть для распределенных атак типа «отказ в обслуживании». 21 октября 2016 года атака на компанию Dyn, обслуживающую систему доменных имен для крупных интернет-сервисов, вывела из строя доступ к Twitter, Netflix, Reddit, Spotify, GitHub и десяткам других площадок на территории США и Европы. Создателями ботнета оказались не государственные хакеры, а трое американских студентов, стремившихся получить преимущество в конкурентной борьбе за серверы игры Minecraft: массированные атаки на серверы конкурентов должны были переманить игроков на собственные площадки создателей.

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

Масштаб ущерба от простейшей уязвимости — пароля, оставленного по умолчанию, — виден на атаке, ставшей поворотной для всей отрасли.

Пример. Ботнет Mirai сканировал интернет в поиске устройств, доступных по стандартному набору из нескольких десятков заводских логинов и паролей, которые владельцы никогда не меняли. К моменту атаки на Dyn в сеть входило порядка ста тысяч зараженных устройств, а пиковая мощность атак, использовавших код Mirai, достигала 1,2 терабита данных в секунду — один из крупнейших показателей распределенных атак, зафиксированных на тот момент. Создатели ботнета были установлены и признали вину в декабре 2017 года. Задолго до этого, в конце сентября 2016 года, они опубликовали исходный код Mirai в открытом доступе, что привело к появлению десятков вариаций вредоносной программы, созданных уже другими группами. Спустя десятилетие потомки Mirai остаются одними из самых активных семейств ботнетов, поскольку коренная причина — устройства с паролями по умолчанию, подключенные к интернету, — не устранена до сих пор.

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

Границы применимости. Инструмент применим на любом предприятии, использующем подключенные к сети устройства и датчики: в производстве, логистике, зданиях с автоматизированными системами управления. По методике это сложный инструмент. Первое ограничение относится к масштабу парка устройств: количество устройств интернета вещей на типичном предприятии на порядки превышает количество традиционных компьютеров, и ручное управление их безопасностью на этом масштабе невозможно. Второе — ограниченность самих устройств: многие датчики и контроллеры обладают минимальной вычислительной мощностью и не способны выполнять сложные проверки безопасности или получать обновления традиционным образом. Третье — публичная доступность методов атаки: после утечки исходного кода Mirai барьер входа для повторения подобной атаки резко снизился, и это касается любого семейства уязвимого оборудования, а не только устройств, затронутых в 2016 году. Безопасность интернета вещей опирается на управление данными (H1-01) в части учета подключенных устройств и связана с операционной технологической безопасностью (I3-03) там, где устройства интернета вещей встроены в промышленные системы управления.

Чек-лист перед внедрением безопасности интернета вещей:

  • Составлен полный реестр устройств интернета вещей, подключенных к сети предприятия.
  • Заводские пароли по умолчанию заменены на всех устройствах реестра без исключения.
  • Определен порядок сегментации сети, отделяющий устройства интернета вещей от критически важных систем.
  • Установлен порядок получения и применения обновлений для устройств, где это технически возможно.
  • Для устройств, не поддерживающих обновления, определены компенсирующие меры защиты.
  • Предусмотрен мониторинг аномального поведения устройств, включая нетипичный сетевой трафик.

Типовые ошибки:

  • Пароли по умолчанию не изменены. Устройства подключаются к сети с заводскими учетными данными. → Обязательно заменять пароли по умолчанию при подключении каждого устройства.
  • Отсутствие полного реестра устройств. Часть устройств интернета вещей подключена к сети без учета и контроля. → Вести полный и регулярно обновляемый реестр подключенных устройств.
  • Единая сеть без сегментации. Устройства интернета вещей находятся в одной сети с критически важными системами. → Отделять устройства интернета вещей от критичной инфраструктуры сетевой сегментацией.
  • Игнорирование устройств без поддержки обновлений. Устаревшие устройства эксплуатируются без компенсирующих мер защиты. → Определять компенсирующие меры для устройств, не получающих обновления.

I3-03 — Операционная технологическая безопасность (OT Security)

Откуда появился инструмент. Дисциплина как самостоятельное направление сформировалась после обнаружения в июне 2010 года вредоносной программы Stuxnet белорусской компанией VirusBlokAda. Программа была нацелена на программируемые логические контроллеры Siemens, управлявшие центрифугами для обогащения урана на иранском объекте в Натанзе. Она проникала в изолированную от интернета сеть через зараженные USB-накопители, использовала четыре ранее неизвестные уязвимости операционной системы Windows и перепрограммировала работу центрифуг, одновременно показывая операторам заведомо нормальные показания приборов. По оценке специалистов, между ноябрем 2009 года и январем 2010 года программа вывела из строя около тысячи центрифуг — порядка десятой части действующего парка. Считается, что за разработкой стояли спецслужбы США и Израиля в рамках операции, санкционированной еще в 2006 году. Stuxnet стал первой широко изученной атакой, продемонстрировавшей, что кибератака способна причинить физический ущерб оборудованию, а не только похитить или исказить данные.

Суть и механика. Подход к защите систем, которые контролируют физические процессы и устройства в промышленных средах: производственных, энергетических, транспортных — от угроз и уязвимостей. В отличие от традиционных информационных технологий, которые в основном обрабатывают данные и коммуникации, операционные технологии отвечают за прямой контроль и мониторинг оборудования и промышленной среды. Методика сосредоточена на трех областях: правах доступа, устранении уязвимостей и обучении сотрудников методам обеспечения безопасности.

Разницу между атакой на данные и атакой на физический процесс видно на происшествии, определившем облик всей дисциплины.

Пример. До Stuxnet защита промышленных систем управления строилась на предположении, что физическая изоляция объекта от интернета — так называемый «воздушный зазор» — делает атаку практически невозможной. Программа обошла это предположение через человеческий фактор: зараженный накопитель, вероятно, был занесен на объект сотрудником или подрядчиком, не подозревавшим о заражении. Дальнейшее распространение шло автоматически, через уязвимости в самой операционной системе. Конечным результатом оказалось физически изношенное и вышедшее из строя оборудование при внешне нормальной работе систем контроля — не похищенные данные и не остановленный сервер. Иранское правительство признало факт заражения лишь в конце ноября 2010 года, спустя месяцы после публичного раскрытия программы, и до сих пор не раскрыло полный масштаб причиненного ущерба.

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

Границы применимости. Инструмент применим на предприятиях, где информационные системы управляют физическим оборудованием и процессами: на производстве, в энергетике, на транспорте, в коммунальном хозяйстве. По методике это сложный инструмент, самый трудоемкий в статье. Первое ограничение связано с устаревшей инфраструктурой: многие промышленные системы управления проектировались десятилетия назад без учета современных требований кибербезопасности и физически не поддерживают часть защитных мер, применимых к обычным информационным системам. Второе — цена простоя: в отличие от офисных информационных систем, остановка промышленной системы управления для установки обновлений или патчей нередко означает остановку производства, что создает давление в пользу отсрочки необходимых мер защиты. Третье — человеческий фактор как основной вектор проникновения: физическая изоляция объекта не защищает от заражения через съемные носители или подключенные устройства подрядчиков, что подтвердил сам Stuxnet. Операционная технологическая безопасность опирается на безопасность интернета вещей (I3-02) там, где промышленные датчики и контроллеры подключены к сети, и на осведомленность о безопасности (I1-01) в части обучения персонала, работающего с физическим оборудованием.

Чек-лист перед внедрением операционной технологической безопасности:

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

Типовые ошибки:

  • Опора на физическую изоляцию как единственную защиту. Предприятие полагает, что отсутствие подключения к интернету исключает угрозу заражения. → Контролировать съемные носители и устройства подрядчиков как отдельный вектор угрозы.
  • Отсрочка обновлений из-за цены простоя. Известные уязвимости не устраняются из-за нежелания останавливать производство. → Планировать устранение уязвимостей с учетом производственного графика, а не откладывать бессрочно.
  • Избыточные права доступа. К системам управления имеет доступ более широкий круг сотрудников, чем необходимо для их задач. → Ограничивать доступ к промышленным системам управления минимально необходимым кругом лиц.
  • Отсутствие сегментации сети. Промышленные системы управления находятся в одной сети с офисной информационной инфраструктурой. → Отделять промышленные системы управления от офисных сетей сегментацией.

I4-01 — Активный поиск угроз (Threat Hunting)

Откуда появился инструмент. Термин впервые употребил Ричард Бейтлих, на тот момент возглавлявший службу реагирования на инциденты компании General Electric, в статье «Become a Hunter», опубликованной в июльско-августовском номере Information Security Magazine за 2011 год. Бейтлих отталкивался от военного термина «охотник-убийца», популяризированного военно-воздушными силами США в середине 2000-х годов для обозначения тактики активного поиска и уничтожения цели, в противоположность пассивной обороне позиции. Практику активного поиска до публикации статьи уже вели сотрудники его собственной команды реагирования на инциденты, которых он называл «охотничьими вылазками». В 2013 году один из участников этой команды, Дэвид Бьянко, формализовал подход в модели, различающей анализ по готовым индикаторам компрометации и поиск без опоры на такие индикаторы — собственно «охоту» в узком смысле слова.

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

Значение целенаправленного, а не автоматического поиска видно на происхождении самого подхода внутри промышленной компании.

Пример. Команда реагирования на инциденты General Electric столкнулась с типичной проблемой начала 2010-х годов: автоматические средства защиты — системы обнаружения вторжений, антивирусы, брандмауэры — реагировали на известные сигнатуры атак, но пропускали целенаправленных, технически подготовленных противников, маскировавших активность под легитимный трафик. Вместо того чтобы дожидаться срабатывания автоматических средств, специалисты команды начали регулярно и целенаправленно анализировать журналы событий и сетевой трафик в поисках аномалий, не связанных ни с одним известным индикатором компрометации. Они искали то, что выглядело неправильно, а не готовое описание угрозы. Такой подход требовал экспертизы конкретных людей, а не автоматизации: их опыта, интуиции и готовности систематически проверять гипотезы, которые не подтверждались никакими готовыми правилами.

Активный поиск угроз ценен тем, что исходит из предположения о присутствии противника внутри инфраструктуры и ищет отклонения от нормального поведения, а не опирается на заранее известное описание угрозы.

Границы применимости. Инструмент применим на предприятиях с достаточно зрелой службой безопасности, обладающей собственными специалистами или доступом к внешней экспертизе такого уровня, поскольку метод требует квалифицированного человеческого анализа, а не автоматизации. По методике это сложный инструмент. Первое ограничение состоит в зависимости от квалификации специалистов: эффективность активного поиска определяется опытом и интуицией конкретных людей в большей степени, чем у большинства других инструментов кибербезопасности, и передать эту работу полностью автоматическим средствам невозможно. Второе — стоимость времени специалистов: активный поиск угроз, в отличие от автоматического мониторинга, требует постоянного выделения времени квалифицированных сотрудников на работу, не гарантирующую немедленного результата. Третье — риск отсутствия результата как ложного признака безопасности: не найдя следов компрометации при очередном поиске, предприятие рискует ошибочно счесть себя защищенным, тогда как отсутствие результата может означать и недостаточную глубину поиска. Активный поиск угроз опирается на анализ угроз (I2-02) как на источник сведений о тактиках и техниках, которые стоит искать, и на управление информационной безопасностью (I1-04) как на общую матрицу для систематизации найденного.

Чек-лист перед внедрением активного поиска угроз:

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

Типовые ошибки:

  • Полная зависимость от готовых индикаторов. Поиск ведется только по известным признакам компрометации, без проверки собственных гипотез. → Формулировать и проверять гипотезы, основанные на специфике собственной инфраструктуры.
  • Разовые эпизодические проверки. Активный поиск проводится нерегулярно, без установленной периодичности. → Устанавливать регулярный цикл проведения активного поиска угроз.
  • Отсутствие как ложный признак безопасности. Ненайденная угроза автоматически трактуется как ее отсутствие. → Оценивать глубину и полноту каждого цикла поиска отдельно от его результата.
  • Результаты поиска не влияют на защиту. Найденные пробелы в обнаружении не приводят к настройке автоматических средств защиты. → Связывать выводы активного поиска с последующей настройкой систем защиты.

Резюме

Четыре инструмента этой статьи завершают группу I переходом от общих правил защиты к конкретным техническим средам и конкретным методам поиска противника. Безопасная разработка встраивает защиту в процесс создания программного обеспечения. Безопасность интернета вещей защищает устройства, чей главный источник уязвимости — простейшая небрежность вроде незамененного пароля, а не сложность атаки. Операционная технологическая безопасность защищает физическую реальность, а не данные: оборудование, которое может выйти из строя. Активный поиск угроз исходит из того, что автоматические средства защиты уже пропустили противника, и ищет его вручную. Атака Mirai и программа Stuxnet разделены разными целями и разным уровнем сложности — студенческий проект ради игрового сервера против операции спецслужб нескольких государств. Оба случая объединены общим уроком: последствия атаки на физический или массово распространенный объект определяются тем, была ли устранена самая очевидная уязвимость заранее, а не изощренностью нападения. Разоблачение несуществующего «Института системных наук IBM» служит той же логике на другом уровне: даже внутри самой дисциплины безопасной разработки популярное обоснование бывает мифом, а рецензируемое исследование, стоящее за тем же выводом, честнее и осторожнее в формулировках. Суммарная трудоемкость составляет 156 часов, наибольшую величину среди статей о кибербезопасности в этом цикле, и это отражает переход от универсальных практик к средам, требующим собственной экспертизы: промышленному оборудованию, распределенным устройствам, работе аналитика без опоры на готовые правила. Для промышленного предприятия отсюда следует практический вывод: там, где автоматизированные средства защиты неизбежно отстают от конкретики физического производства, единственной опорой остается квалификация людей, которые эту защиту выстраивают и проверяют.

В следующей статье цикла продолжим группу I подгруппой I4 «Аналитика и расследования»: разберем цифровую криминалистику, этичный искусственный интеллект в управлении рисками и квантовую безопасность.

Похожие записи