ИБ — новая инженерная подсистема ЦОД?
Привет, Хабр! Сегодня мне хотелось бы поговорить о том, как нужно относиться к информационной безопасности в центрах обработки данных. Поскольку обеспечить бесперебойный доступ к сервисам — главная задача любого дата-центра, мы стали рассматривать ИБ как одну из инженерных систем ЦОДа, которая обеспечивает uptime. Сегодня я не буду рассказывать про конкретные решения и вендоров, а поделюсь нашим опытом внедрения решений и политик информационной безопасности на уровне всего дата-центра.
Когда люди создают свой ЦОД или выбирают поставщика услуг (что в последнее время встречается чаще, потому что создавать ЦОД на т.н. «параллельном импорте» пока весьма сложно), совершенно типичными являются вопросы: «А к какой категории по классификации Uptime Institute относится ЦОД?», «А ЦОД соответствует рекомендациям TIA-942?», «Насколько хорошо зарезервировано электропитание?», «Есть ли у вас/нас удаленная площадка для гео-репликации?» и так далее. Но про информационную безопасность обычно никто не спрашивает сразу.
Почему в перечне так редко присутствуют вопросы об информационной безопасности? Я пробовал задавать этот вопрос потенциальным пользователям, и в основном слышал три типичных ответа (под спойлером).
Hidden text
«Уж с безопасностью-то мы разберемся сами, когда придет время» (то есть не разберемся, пока петух не клюнет)
«А что, разве есть стандарты обеспечения безопасности, с которыми нужно сверяться?» (Есть, но, увы, не общеотраслевые).
«Безопасность — это дополнительная услуга, ее можно внедрить/подключить в любое время» (но все-таки лучше сделать это ДО ТОГО, чем ПОСЛЕ ТОГО).
Проще говоря, дело в том, что ИБ воспринимается как дополнительный сервис, а не часть инфраструктуры дата-центра. И совершенно зря.
Мы же в компании Oxygen развиваем централизованную практику построения безопасности. И за последние 5 лет нам удалось накопить компетенции по внедрению ИБ-решений в экосистему ЦОД, сделав ИБ еще одной инженерной системой.
Все ради аптайма
На сегодняшний день у нас 100% аптайма. Этот уровень достигается за счет качества оборудования и его правильной настройки, высокой квалификации персонала и своевременная реакция на ИБ-инциденты.
Процесс мониторинга ИБ инцидентов в дата-центре должен достигать уровня автоматизма, сравнимого с инженерной системой. Например, если происходит проблема с энергоснабжением, подключается дизельно-генераторная установка (ДГУ). Это действие можно (и нужно) автоматизировать, чтобы дизель запускался удалённо и автоматически.
В качестве примера, пожалуй, один из самых крупных и нашумевших инцидентов последнего времени — вынужденная остановка управления магистралью доставки топлива. Поскольку проблема произошла в крупной американской компании, она спровоцировала дефицит бензина и привела к рекордному росту его стоимости. В стране пришлось вводить чрезвычайное положение, а компании — платить вымогателям выкуп в размере 4,5 млн $.
А вот еще досадные примеры. Казалось бы, крупные и серьёзные компании. Но они страдают из-за хакерских атак по причине недостаточной интеграции ИБ в свою инфраструктуру:
Hidden text
Во время глобального сбоя работы сервисов одной запрещенной на территории Российской Федерации организации на букву F, сотрудники не смогли попасть в офис компании, поскольку система управления доступом не принимала пропуска. То есть парализованы были все рабочие процессы, и сотрудники даже не могли пройти через двери, чтобы решить проблему. Можете представить потери организации за это время.
Перехват управления инфраструктурой водоочистных сооружений чуть не привёл к заражению химикатами целого города. Если бы хакер, который своими шаловливыми ручками все-таки завершил процесс изменения настроек очистных сооружений, была бы большая беда.
Недавно хакеры легко получили доступ к системе видеонаблюдения банков, тюрем, ИТ-компаний, используя уязвимость в камерах. Слава богу, что это были белые хакеры. Но в случае «черных» (I mean «bad» in case if you are from US), атака на камеры могла бы парализовать службы охраны, подменить видео или замаскировать реальный рейд на организацию.
А теперь на минуту представьте, если бы аналогичные инциденты произошли в том ЦОДе, где крутятся ваши системы. Допустим, управление было перехвачено хакером. Что мы имеем? С одной стороны — сотрудники, заблокированные в своих кабинетах. С другой — стойки, к которым может легко добраться злоумышленник, как удаленно, так и физически. Как хакер воспользуется своей властью? Да как угодно. Зависит от степени его изощрённости, креативности и жадности. Мурашки по коже…
Россия на прицеле
Вы можете сказать: «Да ваши примеры все из США!». И будете правы. Но, к сожалению, в России такие сценарии тоже возможны. Хорошо, что никто не взломал элементы критической инфраструктуры как в США, но зато компании регулярно теряют деньги из-за атак.
По данным открытой статистики, в 2022 году организации на территории РФ уже подверглись массированным DDoS-атакам. Осуществлялись крупные кражи баз данных. При этом основным мотивом выступала не финансовая выгода злоумышленника, а дестабилизация работы российских компаний — то есть хакеры часто не ставили даже цели монетизировать свои действия.
И ЦОДы, естественно, становятся одними из первых, кто должен держать удар.
Почему же атаки удаются?
Неверно будет говорить, что сегодня кто-то не использует защиту. Как правило, компании задумываются об информационной безопасности: внедряют протоколы, развивают внутреннюю экспертизу или обращаются к ИБ-подрядчикам. Почему же их всё равно взламывают?
Увы, современный человек чаще всего живет в своей иллюзии безопасности. Мы придумываем разные схемы, готовимся, но в определенный момент просто «что-то идет не так». Но реальность такова, что каждый инцидент ИБ — это набор взаимосвязанных инцидентов, один следует за другим. Как дорожка из домино.
Чтобы такая череда инцидентов не приводила к неприятным последствиям, важно развивать навык по выявлению и быстрой реакции на разные виды атак. Сегодня мало грамотно расставить «сигнальные флажки». В реальной жизни требуется быстрая и грамотная реакция, а это уже навык, который нужно тренировать и развивать у команды ИБшников.
В общем, в вопросах ИБ профилактика — это лучшее лечение. А для профилактики нужно очень много всего, прямо как в кабинете дорогостоящего терапевта элитной медицинской клиники:
На уровне сети — изоляция сегментов и выявление сетевых аномалий с помощью NGFW и сетевых детекторов, защита инфраструктур от DDOS;
Для аудита уязвимостей — использование сканеров, тесты на проникновения и ручное проверка тактик и техник взлома;
На уровне WEB-ресурсов — применение межсетевых экранов уровня приложений, анализ логики приложений;
Для людей (чтобы исключить социальную инженерию, человеческий фактор в атаках) — повышение осведомленности и проведение киберучений;
На рабочих местах и серверах (защита конечных точек) — целый набор решений от классических антивирусов до продвинутой защиты от таргетированных атак и атак нулевого дня.
В целом — оперативное реагирование на изменения в инфраструктуре и мониторинг поведения подсистем с помощью SIEM.
Накопленные практики оказались полезны
Централизованный подход к защите показал хорошие результаты, и мы начали предоставлять услуги ИБ внешним заказчикам. Тут могу привести несколько свежих примеров
5 минут и готово
Крупная федеральная компания несколько дней боролась с DDoS-атакой. За это время были исчерпаны все собственные возможности по фильтрации запросов (в том числе в ручном режиме), админы были заняты только этим, а бизнес не мог нормально функционировать.
Подключив их через свой проверенный контур, мы решили вопрос за 5 минут! 5 минут, Карл, и все было в порядке. Стоило ли так долго откладывать простое решение?
Захватить всю сеть
При анализе внешнего периметра инфраструктуры клиента, мы шаг за шагом выявили уязвимости в оборудовании и подчинили себе всю сеть. В результате удалось добраться даже до кассовых аппаратов розничных точек и запатчить все уязвимости — быстро и полностью в удаленном режиме.
Как мы к этому пришли?
С виду кажется, что все задачи по защите собственных и клиентских систем решаются очень просто. Но это не совсем так. На самом деле, чтобы прийти к инфраструктурному уровню ИБ, нужно постараться. В частности, мы в Oxygen сделали это за следующие три шага:
Шаг 1. Описание процессов. В качестве базовой и отправной точки мы выбрали международный стандарт по информационной безопасности ISO 27-серии, тем более что он имеет свой перевод в виде ГОСТа. В соответствии с контекстом деятельности компании мы выделили и описали основные процессы: от набора персонала до проектирования новых сервисов и вывода из эксплуатации ненужных систем. Получился достаточно объемный регламент, которым мы руководствуемся до сих пор.
Шаг 2. Описание ролей. Начали создавать планы по достижению целей информационной безопасности, а сразу после этого — реализовывать их. Матрица RACI оказалась очень полезной для визуализации: сразу стало понятно, кто участвует в каждом процессе и на каких ролях. Масштабируя процессы ИБ на структурные подразделения компании, мы сразу наглядно видим, кто и что должен сделать для достижения заданного уровня ИБ.
Шаг 3. Добавление метрик. Нам также хотелось получить ответы на вопросы и измерить эффективность тех или иных мер обеспечения ИБ. И тогда мы разработали метрики для измерения эффективности каждого процесса. В число этих метрик входит очень многое — от доли сотрудников, ознакомленных с политиками и регламентами до значения uptime подсистем обсечения безопасности и инфраструктуры в целом. Такие показатели хорошо видны на дашбордах, которыми пользуются все руководители.
Результат: После проведения всей этой работы мы создали виртуальную модель системы информационной безопасности в дата-центре. На её основе можно прослеживать взаимосвязи между различными составляющими системы, определять зоны ответственности и разрабатывать меры оперативного противодействия атакам на инфраструктуру.
А за счет обучения персонала и знакомства сотрудников с этой картой, каждый может увидеть, что все ИБ-процессы и безопасность компании в целом — часть повседневной работы всех участников системы, а не что-то отстранённое и абстрактное.
Метрики
Как работают метрики в этой матрице? Это хорошо видно на примере задачи обеспечения сетевой безопасности. На входе мы вводим действующую топологию сети, чтобы на выходе получить модернизированную сеть с учётом лучших практик в сфере ИБ.
Главным SLA для данного процесса становится аптайм, стремящийся к 100% по передаче данных. Всё осуществляется при соблюдении конфиденциальности, целостности и доступности циркулирующей информации. Снижение SLA ниже допустимых значений приводит к перезапуску процесса по новой с привлечением всех необходимых в компании подразделений, определенных матрицей RACI.
Инженерый подход рулит
Комплексный инженерный подход показал, насколько фрагментарно обычно выстроен ИБ-процесс взаимодействия внутри компаний.
Теперь, когда мы оказываем услуги по инфобезу клиентам, (а иногда даже во время атак или после свершившегося инцидента), мы из раза в раз убеждаемся в необходимости фундамента в виде выстроенных процессов обеспечения и управления информационной безопасности.
Для того, чтобы нам самим было удобно работать, мы в Oxygen пришли к концепции трёх центров мониторинга внутри ЦОДа:
Мониторинг ИТ (его ещё называют NOC)
Мониторинг и управление подсистем ЦОД — Data Center Infrastructure Management (DCIM)
Мониторинг информационной безопасности — Security Operations Center (корпоративный SOC).
Все эти центры не только управляют своими системами, но непрерывно взаимодействуют друг с другом, участвуют в бизнес-процессах компании и развивают не только катастрофоустойчивость ЦОДа, но также формируют актуальную продуктовую линейку компании, достигая синергического эффекта в улучшении SLA предоставляемых услуг.
Учитывая, что ИБ сегодня является одной из ключевых сфер обеспечения доступности и сохранности данных, на мой взгляд, такой подход можно считать уже проверенной практикой. Вы можете использовать его внутри своей инфраструктуры…или обратиться к нам, чтобы получить в готовом виде. Главное помнить, что профилактика всегда дешевле тушения пожаров, а процессы инфобеза проходят через всю компанию, кто бы что ни говорил по этому поводу.
P.S. На всякий случай мы приносим извинения всем Василиям. Любые совпадения имен и лиц в этой статье — абсолютно случайны!
