Десять аксиом кибербезопасности. Аксиома вторая. Доверять нельзя никому
Аксимомы кибербезопасности:
-
Доверять нельзя никому.
Современные информационные технологии построены на доверии, существующем на совершенно различных уровнях – начиная доверительными отношениями между серверами и заканчивая лояльностью к поставщикам услуг и производителям решений ИТ и кибербезопасности. Но не является ли это близоруким подходом, который основан на устаревшей парадигме, давно превратившейся в труху? Особенно в ситуации, когда все имеют доступ ко всему и отовсюду (см. рис.1).
Взломать можно всё
Не будем ходить вокруг да около, а посмотрим на несколько примеров. На днях был обнародован факт взлома сайта компании ASUS. По данным «Лаборатории Касперского», обнаружившей столь неприятный инцидент, это событие произошло еще полгода назад. Неизвестные пока злоумышленники смогли проникнуть в сеть ASUS, взломать ее систему автоматического обновления ASUS Live Update и распространять через нее вредоносное ПО большому количеству пользователей. «Лаборатория Касперского» подтвердила заражение 57 тысяч пользователей, но предполагает, что число жертв гораздо больше и достигает одного миллиона пользователей. Парадоксально, но компания ASUS на момент написания статьи отказывалась признать факт своего взлома и компрометации, несмотря на представленные доказательства и подтверждение проникновения также и специалистами Symantec.
Это не единственный случай, когда сайт ИТ-компании без ее ведома распространял вредоносный код. Год назад, американский центр реагирования на инциденты US CERT опубликовал отчет, в котором обвинил неуловимых русских хакеров в том, что они атаковали американскую энергетику. Интерес представляет метод, которым были взломаны несколько компаний американского ТЭК. Он получил название «водопой» (water hole). Его идея заключается в том, что злоумышленники взламывают не своих жертв, а сайты, которые они посещают (как животные, идущие на водопой, где их поджидают хищники). В описываемом сценарии русские хакеры взломали ряд ресурсов, которые раздавали обновления для программного и аппаратного обеспечения промышленных сетей атакованных компаний, а уже с них вредоносное ПО и было загружено жертвами, доверившимися производителям.
Годом ранее, в 2017-м специалисты Cisco обнаружили, что компания Avast (кстати, производитель средств защиты информации) распространяла скомпрометированное ПО CCleaner, предназначенное для оптимизации ОС Windows. Зараженная версия ПО устанавливала на компьютер пользователя дополнительный вредоносный код. По оценкам специалистов, от действий вендора, которому доверяли многие пользователи по всему миру, пострадало несколько миллионов человек, загрузивших ПО, никем не проверенное на наличие опасного содержимого.
Посмотрим теперь в другую сторону и вспомним ситуацию с бюро кредитных историй Equifax, взломанным в 2017-м через уязвимость в публичном веб-портале компании. Но основной ущерб, кража данных 140 млн клиентов, был нанесен за счет доверительных отношений между уязвимым веб-сервером и внутренними серверами баз данных, которые и хранили похищенную информацию. Налицо злоупотребление доверием между техническими компонентами, что и повлекло за собой одну из крупнейших утечек информации в истории.
Не доверять никому
Недоверие ИТ-вендору. Недоверие ИБ-производителю. Недоверие серверам в корпоративной инфраструктуре.
Но вероятно, мы можем доверять своим сотрудникам? Увы. В 2007 году главный специалист ИТ-дирекции Росбанка был арестован и отправлен под суд за внедрение в инфраструктуру своей организации вредоносной программы, несанкционированно скопировавшей часть базы данных платежных карт клиентов Росбанка, после чего, с помощью полученной информации, похитил со счетов около 300 тысяч рублей. Не так уж и много по нынешним меркам, но сам факт использования ИТ-специалистом своих полномочий во вред компании говорит о том, что доверие может обойтись дорого. Кстати, один из первых случаев злоупотребления доверием со стороны «своих» произошел еще в Советском Союзе, когда в 1992 году в Литве программист Игналинской АЭС загрузил вредоносный код в автоматизированную систему, отвечающую за работу одной из подсистем реактора. Данный факт был своевременно обнаружен, для проведения всестороннего расследования АЭС была остановлена. Аналогичная ситуация, когда внутренний нарушитель действовал со злым умыслом, произошла в 1999 году на АЭС в Бредвелле (Великобритания). Тогда в инциденте участвовал уже сотрудник службы безопасности (!) атомной электростанции.
Ну хоть подрядчикам-то мы можем доверять, если даже сотрудникам службы кибербезопасности верить нельзя? Увы, тут нас тоже никаких приятных сюрпризов не ждет. Обратимся вновь к атомной электростанции, но на этот раз уже по ту сторону океана, в США. Считается, что подобные объекты коренным образом отличаются от обычных корпоративных сред и с точки зрения архитектуры, и с точки зрения процедуры проверки персонала, и с точки зрения подбора подрядчиков. Но нет. В 2003 году на атомной электростанции David Besse в Огайо произошел пренеприятнейший инцидент. Внутренняя сеть компании, обслуживающей АЭС в Огайо, была заражена червем Slammer, который загружался в серверы с программным обеспечением MS SQL Server 2000. В процессе проведения регламентных работ и в нарушение всех установленных на АЭС политик безопасности сотрудник обслуживающей организации установил прямое соединение между АЭС и сетью своей компании, чем не преминул воспользоваться вредоносный код, попавший в сеть АЭС David Besse. Неконтролируемое распространение червя привело к перегрузке сети и невозможности компьютеров общаться в ней между собой. В итоге система отображения параметров безопасности (SPDS) была недоступна в течение 6 часов 9 минут, а часть процессов АЭС пришлось останавливать, что привело к веерному отключению электричества на восточном побережье США.
Схожий инцидент произошел во Флориде в 2008-м. Инженер, обслуживающий обычную электростанцию в западном Майами, в обход всех правил отключил основную и резервную системы противоаварийной защиты. В результате последующего сбоя из строя было выведено оборудование подстанции, а система противоаварийной автоматики не смогла его предотвратить. В итоге пострадало свыше 680 тыс. потребителей, оставшихся без электричества. Несколько компаний, продающих электроэнергию, потеряли контроль над своими энергосетями, в том числе пострадала атомная станция Turkey Point на юге Майами.
В январе 2019 года американский производитель продуктов питания, фирма Mondelez, известная такими брендами, как Alpen Gold, Dirol, «Барни», «Юбилейное», Milka, Toblerone, столкнулась с тем, что ее страховая компания Zurich отказалась выплачивать более $100 млн в качестве страхового возмещения за заражение Mondelez вредоносной программой Nyetya (NotPetya). Наконец, в 2013-м известная ИБ-компания RSA заявила о том, что в их продуктах использовался генератор случайных чисел с закладкой от Агентства национальной безопасности США, который делал случайные числа не такими уж и случайными. Что интересно, данный генератор был сертифицирован американским институтом стандартов NIST, что вновь ставит вопрос о доверии к сертификации со стороны регуляторов (в России, кстати, вопрос доверия к результатам сертификации также стоит очень остро).
Не доверяй, а проверяй
Я мог бы и дальше продолжать приводить примеры, когда доверие только вредило организациям, но закончу этот список коротким экскурсом в историю. 15 марта, но более двух тысяч лет назад, в 44-м году до н. э. был убит Гай Юлий Цезарь. Наверное, мало кто сможет назвать имена убийц римского императора (а их по разным оценкам было от 15 до 60), но одно имя вы наверняка знаете – это Брут, а точнее Марк Юний Брут. Некоторые историки называют его сыном Гая Юлия Цезаря от Сервилии из рода Цепионов. Отсюда и выражение «и ты, Брут» – с этими словами умирающий Цезарь обратился к человеку, которому он доверял и которого считал то ли сыном, то ли близким другом (анализа ДНК в то время проводить еще не умели).
За две тысячи лет ситуация изменилась мало, и доверия больше не стало, а значит, мы должны уметь строить систему кибербезопасности на предприятии в условиях отсутствия доверия. Можно даже перефразировать известную поговорку «Не доверяй, а проверяй». Отсюда попытки разных компаний придумать нечто, что позволило бы на практике реализовать эту поговорку. В 2003-м на Jericho Forum активно обсуждали концепцию депериметризации, которая бы позволила не доверять периметру организации, выстраивая защиту предприятия в условиях отсутствия четких границ. В 2010-м Джон Киндерваг из Forrester предложил концепцию Zero Trust (в 2018 году концепция была расширена и стала называться Zero Trust eXtended, ZTX). В 2013-м Google назвал схожий подход BeyondCorp, а Intel – Beyond the Edge. В 2017-м Gartner предложил свой подход – CARTA (continuous adaptive risk and trust assessment). Последней к гонке названий присоединилась Cisco, именующая свой метод Trust Access. Во всех случаях замысел одинаковый: уйти от идеи доверия по умолчанию к внутренним объектам (серверам, сетевому оборудованию, рабочим местам и др.) и субъектам (пользователям, подрядчикам, ИТ- и ИБ-специалистам) к принципу недоверия всем и вся, независимо от источника.
Стратегические правила
Это требует от современного предприятия пересмотреть свою стратегию кибербезопасности и реализовать следующие обязательные элементы:
-
Предполагать, что весь трафик, независимо от источника, является вредоносным, пока мы не убедились в обратном, проинспектировав его различными решениями или технологиями.
-
Реализовать принцип минимума привилегий, в том числе сегментировав сеть, предоставив пользователям доступ только к тем данным и приложениям, которые им нужны для выполнения служебных обязанностей. При этом речь идет не о банальном разбиении на статические VLAN, а о динамической или программно определяемой микросегментации.
-
Инспектировать весь трафик, внутренний и внешний, с целью обнаружения вредоносных следов и их блокирования в реальном режиме времени. Проводя анализ сетевого трафика, не забывать и про мониторинг Netflow (или иных flow-протоколов), собираемого с уже имеющегося сетевого оборудования, в том числе и облачных платформ.
-
Идентифицировать и аутентифицировать всех пользователей и устройства (а в ряде случаев и непрерывно их верифицировать) и постоянно мониторить их доступ и привилегии – внутри инфраструктуры и за ее пределами, в Интернете. 802.1x, сертификаты, Single Sign-On, многофакторная аутентификация должны прописаться в вашей инфраструктуре.
-
Осуществлять контроль по всему стеку используемых приложений, особенно взаимодействие между гипервизорами и контейнерами в общедоступных облаках.
-
Защищать и управлять данными, классифицировать их и регулярно обновлять схему категорирования данных, с последующим шифрованием – как в процессе хранения, так и в процессе передачи.
-
Непрерывно проводить инвентаризацию и контроль доступа на основе ее результатов, в том числе и с учетом применения политик безопасности не только к отдельным IP-адресам или группам узлов, но и применительно к отдельным пользователям и даже приложениям.
Модель зрелости безопасности изображена на рис.2.
Пришло время, когда следует пересмотреть привычные нам концепции обеспечения безопасности с разделением на доверенные и недоверенные сети и сегменты, пользователей и приложения. Пора привыкать в своей инфраструктуре к новой аксиоме кибербезопасности – «никому нельзя доверять»!
Смотреть все статьи по теме "Информационная безопасность"
Опубликовано 01.04.2019
