Как стать автором
Обновить
104.19

ИБ — новая инженерная подсистема ЦОД?

Время на прочтение 8 мин
Количество просмотров 2.5K

Привет, Хабр! Сегодня мне хотелось бы поговорить о том, как нужно относиться к информационной безопасности в центрах обработки данных. Поскольку обеспечить бесперебойный доступ к сервисам — главная задача любого дата-центра, мы стали рассматривать ИБ как одну из инженерных систем ЦОДа, которая обеспечивает uptime. Сегодня я не буду рассказывать про конкретные решения и вендоров, а поделюсь нашим опытом внедрения решений и политик информационной безопасности на уровне всего дата-центра. 

Когда люди создают свой ЦОД или выбирают поставщика услуг (что в последнее время встречается чаще, потому что создавать ЦОД на т.н. “параллельном импорте” пока весьма сложно), совершенно типичными являются вопросы: “А к какой категории по классификации Uptime Institute относится ЦОД?”, “А ЦОД соответствует рекомендациям TIA-942?”, “Насколько хорошо зарезервировано электропитание?”, “Есть ли у вас/нас удаленная площадка для гео-репликации?” и так далее. Но про информационную безопасность обычно никто не спрашивает сразу.

Почему в перечне так редко присутствуют вопросы об информационной безопасности? Я пробовал задавать этот вопрос потенциальным пользователям, и в основном слышал три типичных ответа (под спойлером).

Hidden text
  1. “Уж с безопасностью-то мы разберемся сами, когда придет время” (то есть не разберемся, пока петух не клюнет)

  2. “А что, разве есть стандарты обеспечения безопасности, с которыми нужно сверяться?” (Есть, но, увы, не общеотраслевые).

  3. “Безопасность — это дополнительная услуга, ее можно внедрить/подключить в любое время” (но все-таки лучше сделать это ДО ТОГО, чем ПОСЛЕ ТОГО).

Проще говоря, дело в том, что ИБ воспринимается как дополнительный сервис, а не часть инфраструктуры дата-центра. И совершенно зря.

Мы же в компании 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. На всякий случай мы приносим извинения всем Василиям. Любые совпадения имен и лиц в этой статье — абсолютно случайны!

Теги:
Хабы:
+17
Комментарии 2
Комментарии Комментарии 2

Публикации

Информация

Сайт
oxygen.cloud
Дата регистрации
Дата основания
Численность
201–500 человек
Местоположение
Россия
Представитель
vvroschin