Привет, Хабр! Сегодня мне хотелось бы поговорить о том, как нужно относиться к информационной безопасности в центрах обработки данных. Поскольку обеспечить бесперебойный доступ к сервисам — главная задача любого дата-центра, мы стали рассматривать ИБ как одну из инженерных систем ЦОДа, которая обеспечивает uptime. Сегодня я не буду рассказывать про конкретные решения и вендоров, а поделюсь нашим опытом внедрения решений и политик информационной безопасности на уровне всего дата-центра.  Когда люди создают свой ЦОД или выбирают поставщика услуг (что в последнее время встречается чаще, потому что создавать ЦОД на т.н. “параллельном импорте” пока весьма сложно), совершенно типичными являются вопросы: “А к какой категории по классификации Uptime Institute относится ЦОД?”, “А ЦОД соответствует рекомендациям TIA-942?”, “Насколько хорошо зарезервировано электропитание?”, “Есть ли у вас/нас удаленная площадка для гео-репликации?” и так далее. Но про информационную безопасность обычно никто не спрашивает сразу. Почему в перечне так редко присутствуют вопросы об информационной безопасности? Я пробовал задавать этот вопрос потенциальным пользователям, и в основном слышал три типичных ответа (под спойлером). “Уж с безопасностью-то мы разберемся сами, когда придет время” (то есть не разберемся, пока петух не клюнет) “А что, разве есть стандарты обеспечения безопасности, с которыми нужно сверяться?” (Есть, но, увы, не общеотраслевые). “Безопасность — это дополнительная услуга, ее можно внедрить/подключить в любое время” (но все-таки лучше сделать это ДО ТОГО, чем ПОСЛЕ ТОГО).  Проще говоря, дело в том, что ИБ воспринимается как дополнительный сервис, а не часть инфраструктуры дата-центра. И совершенно зря. Мы же в компании Oxygen развиваем централизованную практику построения безопасности. И за последние 5 лет нам удалось накопить компетенции по внедрению ИБ-решений в экосистему ЦОД, сделав ИБ еще одной инженерной системой. На сегодняшний день у нас 100% аптайма. Этот уровень достигается за счет качества оборудования и его правильной настройки, высокой квалификации персонала и своевременная реакция на ИБ-инциденты. Процесс мониторинга ИБ инцидентов в дата-центре должен достигать уровня автоматизма, сравнимого с инженерной системой. Например, если происходит проблема с энергоснабжением, подключается дизельно-генераторная установка (ДГУ). Это действие можно (и нужно) автоматизировать, чтобы дизель запускался удалённо и автоматически. В качестве примера, пожалуй, один из самых крупных и нашумевших инцидентов последнего времени — вынужденная остановка управления магистралью доставки топлива. Поскольку проблема произошла в крупной американской компании, она спровоцировала дефицит бензина и привела к рекордному росту его стоимости. В стране пришлось вводить чрезвычайное положение, а компании - платить вымогателям выкуп в размере 4,5 млн $. А вот еще досадные примеры. Казалось бы, крупные и серьёзные компании. Но они страдают из-за хакерских атак по причине недостаточной интеграции ИБ в свою инфраструктуру: Во время глобального сбоя работы сервисов одной запрещенной на территории Российской Федерации организации на букву 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. На всякий случай мы приносим извинения всем Василиям. Любые совпадения имен и лиц в этой статье —  абсолютно случайны!  CISO OxygenDC