| Слушать на Google Podcasts | Слушать на Mave | Слушать на Яндекс Музыке |
Руслан Рахметов, Security Vision
Направление информационной безопасности, или кибербезопасности, достаточно молодо. Еще лет 10-15 назад специалисту по ИБ приходилось объяснять коллегам и друзьям, чем же он занимается. Однако, в настоящее время вопросы защиты информации, киберустойчивости, хакерских атак обсуждаются на уровне первых лиц государств, а темы кибербезопасности и защиты от мошенников не сходят с главных страниц новостных сайтов. При этом, как и любое другое современное направление бизнеса, информационная безопасность эволюционирует - причем не только в части тактик и техник хакерских атак, новых компьютерных уязвимостей или средств защиты информации. Меняются сами концепции защиты: например, такой подход, как «безопасность контролируемого информационного периметра», столь знакомый и понятный еще 5-10 лет назад, теперь уже не имеет практического применения в большинстве случаев, а удаленная работа в связи с пандемией только усилила устаревание данной концепции. В настоящей статье мы рассмотрим наиболее яркие и актуальные на наш взгляд современные тренды в области информационной безопасности.
1. Атаки на цепочки поставок
Современные крупные высокотехнологичные компании стараются грамотно выстраивать процессы информационной безопасности, такие как управление киберрисками, управление уязвимостями и обновлениями, работа со средствами защиты информации, сбор и анализ логов, аудиты ИБ. Однако, даже для высококвалифицированного специалиста многое современное программное обеспечение остается «черным ящиком»: зачастую они вынуждены слепо доверять вендорам - производителям операционных систем, прикладного ПО и даже разработчикам средств защиты. Мало какие компании имеют в штате выделенных сотрудников, которые смогут осуществить реверс-инжиниринг программных продуктов с тем, чтобы понять, какие именно функции выполняет та или иная компонента. А если учесть, что обновления для программных решений выпускаются едва ли не ежедневно, нам становится понятно, что проверить такие объемы кода становится практически нереально. Таким образом, компании волей-неволей становятся зависимыми от компетенций и состояния ИБ вендора.
Недавние примеры таких атак на цепочки поставок (англ. Supply chain attacks) – это нашумевшие взломы ИТ-гигантов SolarWinds и Kaseya. В обоих случаях в исходный код программных решений этих компаний атакующие вносили вредоносные изменения, которые приводили к тому, что все потребители - заказчики данных ИТ-решений становились уязвимы перед несанкционированным воздействием злоумышленников: зараженные системы содержали т.н. «бэкдор», т.е. вредоносный модуль, который принимает управляющие команды с сервера хакеров. Таким образом, даже грамотно выстроенная система ИБ в данном случае будет бессильна - все обновления ПО от SolarWinds и Kaseya, содержащие вредоносный модуль, были подписаны корректной цифровой подписью, и не доверять им не было основания. Более того, даже сами сотрудники этих ИТ-производителей не знали, что в исходный код их ПО были внесены несанкционированные изменения.
Приведем другой пример: репозитории GitHub, содержащие исходный код open source-проектов, т.е. программ на основе открытого исходного кода, доступного для ознакомления каждому, и распространяемых как правило бесплатно. Данные репозитории также являются потенциальными источниками атак на цепочки поставок - злоумышленникам достаточно завладеть учетной записью пользователя GitHub, имеющего полномочия на внесение изменений (т.н. commit) в исходный код проекта. Внеся вредоносные изменения, атакующим лишь остается подождать, пока код данного проекта будет загружен производителем атакуемого программного решения, поскольку не секрет, что многие коммерческие продукты используют «под капотом» именно open source компоненты.
Вариантом защиты от атак на цепочки поставок будет комплекс мер, направленных на проверку благонадежности вендора-поставщика программных продуктов и анализ состояния процессов информационной безопасности, выстроенных у данного вендора. Для проверки благонадежности можно использовать классические инструменты экономической безопасности, включая неформальный аудит финансовой документации, запрос данных в системах «Интерфакс-СПАРК» и «Контур-Фокус», проведение встреч с руководством компаний. Для анализа состояния информационной безопасности в вендорах следует подготовить опросник (чек-лист), в котором в форме вопросов следует сформулировать все требования по ИБ, предъявляемые вашей компанией, например: существуют ли в компании согласованные процедуры риск-менеджмента и кибербезопасности; каковы процессы управления ПО и уязвимостями, следуют ли разработчики правилам безопасной разработки ПО (т.н. SSDLC - secure software development life cycle) и если да, то каким; каков процесс создания документации на продукты; используются ли статические и/или динамические анализаторы исходного кода; как настроены процессы CI/CD (continuous integration/continuous delivery, т.е. непрерывная интеграция и доставка ПО до потребителя); какими положениями законодательства и внутренних нормативных документов руководствуются разработчики в своей деятельности.
Для решения проблемы внедрения вредоносных модулей вендорами-производителями с помощью технических мер можно порекомендовать компаниям-заказчикам анализировать аномальное поведение установленных программных компонент, особенно недавно обновленных, системами класса UEBA (user and entity behavior analysis, анализ поведения пользователей и сущностей) и IDS/IPS (intrusion detection system / intrusion prevention system, системы обнаружения/предотвращения вторжений). При выявлении подозрительных паттернов в сетевом взаимодействии ПО, при запуске различных дополнительных утилит, возможно скачиваемых «на лету» из интернет-репозиториев, при попытке выполнить незадокументированные операции следует оперативно провести проверку.
2. Атаки на третьих лиц
Атаки на третьих лиц (англ. 3rd parties attacks) похожи на рассмотренные выше атаки на цепочки поставок, однако их отличие заключается в том, что атакованные контрагенты (поставщики, подрядчики, партнеры, даже клиенты и заказчики) могут, сами того не осознавая, стать «плацдармом» для хакеров. Это может произойти следующим образом: допустим, у вашей компании установлены договорные отношения с подрядчиком. Это подразумевает некий документооборот, который будет, скорее всего, осуществляться в электронном виде, а для этого, опять же, скорее всего, будет настроено некоторое доверенное соединение - чаще всего это VPN-туннель либо учетная запись в вашей внутренней инфраструктуре для сотрудника такой организации-контрагента. Таким образом, некоторая часть вашей ИТ-инфраструктуры и внутренние ресурсы будут доступны вашему подрядчику - например, общие сетевые диски, внутренние веб-порталы, какие-то бизнес-приложения. Либо же сотрудники компании-подрядчика будут подключаться к вашей ИТ-инфраструктуре с использованием выданной им учетной записи, так же попадая во внутренние системы и ресурсы вашей компании.
Атакующие, которые изначально планировали взломать вашу инфраструктуру, могут пойти обходным путем, когда поймут, что ваши системы защищены достаточно надежно: хакеры постараются сначала атаковать ИТ-системы вашего подрядчика, которые могут быть защищены слабее, затем, надежно там закрепившись, они постараются добраться уже до первоначальной цели, используя либо настроенный VPN-туннель, либо украденные логин и пароль для учетной записи с удаленным доступом к вашей инфраструктуре. Таким образом, атакованная компания выполняет роль «прокси-сервера» для атакующих, что позволяет им от имени вашего подрядчика получить доступ к интересующим их активам (документы, финансы, персональные данные).
Данная атака отличается от атак на цепочки поставок тем, что её можно достаточно легко предотвратить - достаточно лишь ко всем сущностям, которые оказываются в вашей ИТ-инфраструктуре, применять принцип «нулевого доверия» (англ. Zero Trust). Это подразумевает проверку всех учетных записей, всех устройств, всех сетевых соединений и выполняющихся процессов вне зависимости от того, кто является их инициатором. Для каждой сущности, будь то учетная запись руководителя, смартфон инженера или даже принтер в переговорке, можно рассчитывать некий скоринговый бал благонадежности, который уменьшается при подключении из неизвестных ранее локаций (нетипичные города и страны), в нерабочее время, при наличии активных киберинцидентов на данном устройстве. Если посмотреть на проблему шире, то «прокси-сервером» для злоумышленников может стать и ноутбук вашего же сотрудника, который, работая из дома, во внерабочее время скачивает разнообразные файлы из интернета на свой компьютер, который затем подключает по VPN к корпоративной сети. Применяя же принцип нулевого доверия, мы руководствуемся парадигмой проверки всех сущностей в нашей ИТ-инфраструктуре на основе нескольких факторов, таких как версия ОС, наличие установленных обновлений ОС и патчей для ПО, присутствие работоспособного антивирусного средства на подключающемся к сети устройстве, время подключения, страна подключения, отклонения в нормальном поведении устройства (тут опять же помогут системы анализа аномалий и отклонений от известных паттернов, например, UEBA-решения).
Организационные меры, однако, также могут быть применимы к данного рода атакам - можно взять за основу опросный лист, описанный в предыдущем пункте. В данный чек-лист следует включить вопросы о наличии в компании-контрагенте согласованных политик информационной безопасности и риск-менеджмента, процедур и правил обновления ОС и ПО, использующихся средствах защиты информации, применимых положений законодательства и внутренних нормативных документов. Ответы на данные вопросы помогут понять общий уровень зрелости ИБ в компании-контрагенте, и данный уровень необходимо учитывать при принятии решения о возможности или невозможности сотрудничества с данным подрядчиком, поставщиком, клиентом.
Если же требования кибербезопасности в компании-контрагенте явно не выполняются, но взаимодействовать с ней необходимо, то будет весьма разумным воспринимать все входящие информационные потоки от данного контрагента аналогично любой другой неаутентифицированной, возможно злонамеренной, информации из интернета. Для такого контрагента не стоит заводить учетные записи во внутренних ИТ-системах или создавать выделенный VPN-канал для предоставления доступа к внутренним ресурсам, а следует работать с ним как с любой недоверенной сущностью из интернета, пропуская через весь набор средств периметровой защиты (фаирволлы, «песочницы», средства антивирусной защиты и т.д.). Не следует недооценивать и юридически верно составленное «соглашение о неразглашении» (англ. NDA - Non-disclosure agreement), в котором нужно четко указать меры обеспечения информационной безопасности при совместной работе, ответственность за нарушение данного соглашения, а также описать порядок компенсации потенциального ущерба от реализации рисков кибербезопасности при взаимодействии.
