Полный текст публикации от 02.11.2020 на сайте сетевого издания ИКС-медиа
Если за системный подход ответственность несет государство, то комплекс мероприятий и непосредственная защита объектов КИИ – задача для организаций-владельцев и облачных провайдеров, которые нередко имеют дело с критическими объектами.
Организация является субъектом КИИ, если одна из составляющих ее деятельности – эксплуатация критически важных систем (объектов КИИ), предназначенных для решения задач государственной обороны, обеспечения правопорядка, управления или безопасности. Функционирование объектов КИИ связано с процессами, нарушение которых может нанести большой ущерб окружающей среде, населению, экономике и административным органам. Эксплуатация таких объектов регламентируется законом 187-ФЗ «О безопасности объектов КИИ в РФ».
Если организация владеет объектом КИИ, на нее автоматически ложится обязанность обеспечивать его безопасность, в том числе информационную, и регулярно доказывать соответствие мер защиты требованиям регуляторов. В некоторых случаях атаки на отдельные объекты могут действовать на всю КИИ по принципу домино. Причем последствия успешных хакерских атак могут быть необратимыми. Вот почему опыт обеспечения информационной безопасности элементов этой экосистемы накапливается централизованно и тщательно систематизируется согласно требованиям регуляторов, а ответственность каждого элемента важна в рамках всей системы. Если организация не уверена в своей способности нести подобную ответственность, ей целесообразно обратиться к внешним подрядчикам, обладающим необходимой экспертизой.
Объект КИИ как предмет аренды
Когда элементом объекта КИИ является арендуемая у провайдера облачная инфраструктура, нужно позаботиться о том, чтобы выстроить в ней систему информационной безопасности. В этом случае задачи защиты облачной части объекта КИИ делятся между компанией-заказчиком и провайдером инфраструктуры. Конечно, с проверкой придут к субъекту КИИ, но сегмент инфраструктуры на стороне провайдера должен быть защищен в соответствии с требованиями ФСТЭК и ФСБ и иметь соответствующий аттестат. Политики безопасности провайдера должны быть подкреплены документами, фиксирующими результаты проведения аудита ИБ сторонней организацией. Однако обязанности провайдера на этом не заканчиваются. Для работы с определенными сегментами КИИ поставщики облачных услуг должны не реже раза в год проводить обучение своих специалистов.
Наличие у провайдера такого фундамента безопасности делает его привлекательным не только для субъектов КИИ, но и для других игроков рынка. Использование аттестованного защищенного облака в комплексе со службой информационной безопасности провайдера позволит им обеспечить безопасность информационной системы с нуля без лишних финансовых, временных и организационных затрат, а также дополнительных рисков из-за отсутствия опыта. Встраивание же функций и инструментов безопасности в системы, сети и оборудование уже после их ввода в эксплуатацию сопряжено с рядом рисков, самый серьезный из которых – необходимость отключать системы для установки обновлений.
Дополнительным драйвером для отечественного рынка стала инициатива Министерства цифрового развития, массовых коммуникаций и связи РФ в сжатые сроки «переодеть» КИИ в отечественные решения – перевести все объекты на преимущественное использование российского ПО (до 1 января 2021 г.) и оборудования (до 1 января 2022 г.). Такая инициатива замыкает выбор поставщиков облачных решений на тех, которые могут гарантировать полную локализацию своих продуктов в России.
Как разделить объекты по уровню критичности и оценить риски ИБ
Чтобы грамотно выстроить приоритеты в системе информационной безопасности объектов КИИ, необходимо сначала провести инвентаризацию активов (эту процедуру полезно совместить с категорированием объектов КИИ – одним из этапов обеспечения их защиты). Для категорирования формируется команда из специалистов по разным направлениям. Коллегиально они выявляют критические процессы и активы, собирают объекты КИИ, которые подлежат категорированию, определяют угрозы безопасности, категории значимости объектов и т.д. При предварительной оценке объектов есть вероятность ошибиться с категорией. Поэтому важно грамотно подобрать состав команды или доверить категорирование объектов профильным организациям.
Объекты КИИ оцениваются, исходя из их социальной, политической, экологической и экономической значимости, а также значимости для обороны страны, безопасности и охраны правопорядка. От этой оценки зависит, будет ли объекту присвоена какая-либо их трех категорий значимости или он будет признан незначимым. От уровня значимости объекта КИИ зависит набор организационных и технических мер, обеспечивающих нейтрализацию угроз, последствиями которых может быть прекращение или нарушение его работы. К незначимым объектам КИИ требования ниже. Для информационных систем, осуществляющих обработку персональных данных, определяется также уровень защищенности в зависимости от типов угроз, данных, обрабатываемых системой, и ее пользователей.
После инвентаризации становится ясен вектор работ по выстраиванию системы информационной безопасности. Критичность актива отражает степень влияния его функционирования на бизнес-процессы организации с точки зрения безопасности, отказоустойчивости и эффективности. После анализа критичности следует выработать план непрерывности бизнеса (Business Continuity Plan, BCP) и план послеаварийного восстановления инфраструктуры (Disaster Recovery Plan, DRP). В разработке этих планов участвуют все, кто взаимодействует с объектами КИИ. То есть если инфраструктура находится на стороне провайдера, то он должен принимать непосредственное участие в распределении активов по уровню критичности и планировании непрерывности работы систем. Отказоустойчивость инфраструктуры – ключевой элемент договора с провайдером, который закрепляется в соглашении об уровне оказания услуги. Надежные провайдеры гарантируют отказоустойчивость на уровне трех элементов: гипервизор, сеть и системы хранения данных.
Детально разработанные планы BCP и DRP будут дорожной картой спасения активов в случае возникновения инцидентов. Сценарии из этих документов нужно регулярно тестировать и корректировать, так как субъектам КИИ установлены строгие временные рамки для сообщения об инциденте в Национальный координационный центр по компьютерным инцидентам. А субъектам банковского сектора необходимо уложиться в три часа с момента обнаружения инцидента, чтобы проинформировать еще и Центр мониторинга и реагирования на компьютерные атаки в кредитно-финансовой сфере.
При анализе потенциальных рисков информационной безопасности на объекте КИИ лучший вариант – организовать проверку «на 360 градусов». Как это сделать? Во-первых, провести аудит ИБ для обнаружения слабых мест в информационной безопасности инфраструктуры. Во-вторых, смоделировать атаку на целевую систему, чтобы оценить ее готовность встречать реальные атаки. Второе предполагает привлечение сторонних специалистов («белых» хакеров) для проведения тестирования на проникновение. К такого рода проверке не стоит относиться скептически, она дает ценные результаты. А для защиты конфиденциальных данных целесообразно подписать с провайдером соглашение о неразглашении.
Изучив объект КИИ «насквозь», можно максимально прозрачно оценить все факторы, определяющие риски наступления неблагоприятных событий ИБ, увидеть слабые стороны, «дыры», лазейки, оценить ущерб до его наступления и вовремя подготовиться. Информационная безопасность КИИ не должна ограничиваться защитой на стороне субъекта КИИ, порой некоторые обязательства распространяются даже на контрагентов. При этом опытные облачные провайдеры уже обладают экспертизой, накопленной в результате реагирования на различные инциденты ИБ.
Угрозы ИБ в облаках
Злоумышленники все чаще выбирают мишенью для своих атак наименее защищенные элементы в ИТ-инфраструктуре, к которым относятся в том числе публичные облака. Одна из частых причин – неправильная конфигурация облачных платформ. Известны случаи, когда хакеры через облачные сервисы получали доступ к корпоративной инфраструктуре для поиска конфиденциальной информации, пригодной для продажи, или перенаправления зарплат и платежей на свои счета. Взломщики без труда обходили двухфакторную аутентификацию и через незащищенный протокол IMAP похищали аккаунты руководителей и административного персонала.
Одним из элементов инфраструктуры провайдера является гипервизор, который «нарезает» облако на виртуальные машины. Атака на гипервизор может привести к перехвату одной виртуальной машиной ресурсов и информации, доступной другой машине. Используя уязвимости гипервизора, можно нарушить работу всего облака и получить несанкционированный доступ к образам виртуальных машин вплоть до захвата всей инфраструктуры. Безопасный гипервизор должен уметь идентифицировать и контролировать доступ пользователей к виртуальным машинам, ограничивать права эмуляторов устройств до минимально необходимых, выявлять атаки и контролировать сетевые взаимодействия. Если провайдер облака не располагает таким решением, то гипервизор становится потенциальным источником серьезных рисков.
Принцип работы облачных сервисов (доступ из любого места в любое время) предполагает децентрализацию информации и устройств, имеющих к ней доступ. Если злоумышленнику удастся скопировать токен аутентификации, он сможет удаленно проникнуть в защищенный контур облачной инфраструктуры. Получить токены можно методами социальной инженерии. Такие атаки появились не так давно и получили название «человек в облаке».
Уязвимым звеном облачной модели является внешняя веб-среда. Передача данных и запросы к информационной системе в облаке провайдера должны идти через изолированные зашифрованные туннели. Поскольку большинство пользователей облачных систем подключаются к облаку через браузер, реализуются такие угрозы, как межсайтовый скриптинг, кража паролей, перехваты веб-сессий, компрометация каналов связи с искажением передаваемой информации.
Один из наиболее значимых факторов, останавливающих потенциальных заказчиков облачных сервисов, – DDoS-атаки, способные вывести из строя сегмент облака. При такой атаке множеством распределенных запросов к системе создается большая нагрузка на целевую инфраструктуру, которая доводит ее до отказа в обслуживании и делает ресурсы на некоторое время недоступными. Однако облака на то и облака, что при росте нагрузки на систему можно оперативно увеличить ее мощность, чтобы восполнить недостающие ресурсы. Дополнительной возможностью, предоставляемой провайдером, является резервирование данных, а иногда и рабочих процессов, на отдельной инфраструктуре. В таком случае при остановке основного ЦОДа можно быстро переключиться на работу в резервном, не теряя непрерывности процессов.
Облачные средства защиты объектов КИИ от угроз ИБ
Результатом качественного анализа безопасности критической инфраструктуры должна быть дорожная карта с комплексом мер, необходимых для проектирования эффективной системы ИБ на объекте. В случае сотрудничества с облачным провайдером защитой объекта занимается помимо самой организации еще и поставщик услуг, что дает синергический эффект. Облачный провайдер должен иметь не только расширенный актуальный аппаратно-программный комплекс защиты информации, но и штатных специалистов по информационной безопасности для мониторинга объектов КИИ, размещенных в облаке, и грамотной модернизации системы ИБ всей инфраструктуры.
Минимальная планка мер по защите инфраструктуры на стороне провайдера облачных решений – соответствие требованиям регуляторов. Но хороший подрядчик этим не ограничивается.
Для облачной защиты от внешних атак зачастую используются межсетевые экраны, фильтрующие веб-трафик в соответствии с заданными правилами. Комплексы WAF (Web application firewall) контролируют трафик, проходящий через веб-приложения в облаке, осуществляют сигнатурный и поведенческий анализ, сканирование уязвимостей, виртуальный патчинг. Кроме прочего, в облаке устанавливаются системы обнаружения и предотвращения вторжений (IPS/IDS), неочевидными функциями которых являются поиск открытых незащищенных портов и вредоносных программ, проникающих через них, а также попыток неавторизованного доступа. Эти системы помогают оценить уровень критичности обнаруженных угроз, что немаловажно для проектирования защиты объекта КИИ.
Некоторые провайдеры идут дальше и выстраивают систему единого управления угрозами, объединяющую функции антивируса, систем обнаружения и предотвращения вторжений, пакетного фильтра и VPN-шлюза в одной программе. Хорошим инструментом также является система SIEM (Security Information and Event Management). Она консолидирует и анализирует информацию со всех сетевых устройств и систем безопасности, предупреждает об аномальных событиях и фиксирует логи для последующего обучения. Это решение использует технологии искусственного интеллекта, и оно довольно дорогое, не каждой организации по карману. Мало просто приобрести такую систему, в штате должны быть высококвалифицированные специалисты, которые сумеют тонко настроить ее для эффективной эксплуатации. В противном случае деньги будут потрачены зря. Облачные провайдеры, обладающие продвинутым центром мониторинга и реагирования на инциденты ИБ, и дистрибьюторы услуг информационной безопасности имеют возможности и резоны использовать SIEM-системы не только в своих интересах, но и на благо заказчиков.
Все вышеперечисленные инструменты, конечно, полезны, но говоря о защите КИИ, нельзя обойти вниманием организационные меры. Эффект от внедрения самых продвинутых инструментов окажется нулевым, если сотрудники не будут соблюдать правил корпоративной «кибергигиены» – будь их действия беспечными или злонамеренными, подрывающими безопасность объекта КИИ. Любые WAF и SIEM бессильны в ситуации, когда сотрудник подключает к изолированной сети флеш-носитель, который может содержать скрытый вредоносный код, способный «обрушить» весь объект или целый сегмент КИИ. Соответствующие требования должны быть детально прописаны в пакете организационно-распорядительной документации. Не проверяя сотрудников на предмет соблюдения требований ИБ и не регламентируя их действия, можно поставить крест на безопасности объекта КИИ и на ответственности организации как игрока рынка.
