Привет, меня зовут Иван Дмитриев, директор по ИТ и безопасности холдинга TalentTech,  и сегодня я хочу поговорить про безопасность облаков и безопасность в организациях в целом. Поскольку я смотрю на вопрос со стороны службы ИБ, в этом посте хотелось бы обсудить вопросы взаимодействия с между ИБ и ИТ, а также поговорить о том, что делать с ИБ-специалистами, которые пытаются заблокировать ваши идеи, заявляя, что “это небезопасно”. Желающих подискутировать о степенях безопасности и их оценке также приглашаю пообщаться в комментариях.

Не нужно быть большим экспертом, чтобы заявить: “Задача любой службы ИБ - сделать ИТ-системы максимально безопасными”. Однако в своей практике я сталкивался только с одной моделью полностью безопасной информационной системы. И она работала следующим образом: важная информация записывалась на материальные носители и закапывалась глубоко под землю. С точки зрения современного бизнеса такой подход, увы, не работает. А с наступлением пандемии и повсеместной удаленной работы, даже старые определения ИБ, которые были сфокусированы на достижении целостности, конфиденциальности и доступности, уже не вписываются в новую реальность.

Облака стали данностью, и с ними нужно что-то делать. Например, мы в TalentTech сами для себя сформулировали новое определение безопасности облачной информационной системы. На мой взгляд теперь наши задачи  подразумевают обеспечение достаточного уровня целостности, безопасности и доступности, которые необходимы для течения бизнес-процессов. Такой подход помогает внедрять новые продукты, выбирать провайдеров для себя и вообще работать, не наступая на горло ни функциональности, ни защите.

Цифровая трансформация

Одной из основных причин изменения подхода к ИБ является выступает трансформация. Сложно дать точное определение и объяснить, что это за зверь. Но все бизнесы в той или иной степени хотят трансформироваться. 

Вроде бы никаких проблем, но ключевая активность, в рамках цифровой трансформации, сводится к тому, что все бизнес-процессы становятся измеримыми и управляемыми, а у каждого участника бизнес-процесса появляется постоянный доступ к данным. Он должен знать обо всем (или почти обо всем), что происходит в бизнесе. Цифровая копия того самого гвоздя, который мы выпускаем на нашем заводе метизов, позволяет  моделировать использование изделия и даже прогнозировать его прочность на десять партий выпусков. 

При этом специалисты по информационной безопасности сталкиваются с беспрецедентным размытием информационного периметра компании. Мы не сможем посадить в одном офисе всех участников бизнес-процессов, подключить их к серверу только кабелем. Возникает неизбежная потребность в облаках — не важно, внешние они или внутренние. Компаниям приходится адаптировать облачные технологии, чтобы обеспечить доступ сотрудников к данным и информационным системам.

Что еще хуже (для безопасников конечно), в компаниях появляется функция дата-инжиниринга. Вместе с цифровой трансформацией появляются те самые ребята, которым нужен доступ “ко всему”. Не знаю как у кого, а у нас это, как правило, молодые люди, которые хорошо умеют работать с Python, умело используют какие-то новые инструменты для даты-аналитики, но абсолютно не в курсе об архитектуре и правилах работы сложных систем.

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

Мы можем сколь угодно говорить о том, что “это небезопасно”, что нам не нравится какой-то подход и так далее. Но зачастую служба ИБ выдает ярлык «небезопасно», когда не знает, как с чем-то работать. И если вы сталкиваетесь с активным противодействием  службы безопасности при внедрении облачных систем, не стоит идти на конфронтацию. Коллег просто надо перевести в русло конструктивной дискуссии. Предложите им обсудить “как сделать это безопасно”. Ведь наша общая задача состоит в том, чтобы обеспечить необходимый и достаточный уровень целостности, конфиденциальности и доступности, чтобы бизнес продолжал работать. Например, мы с нашим техническим директором — лучшие друзья. Поэтому всегда находим компромисс, решаем, как внедрить тот или иной сервис, как что-то разработать, как что-то сделать.

Оценка рисков — это наше все

Такова природа мышления специалиста по ИБ, что мы все апеллируем рисками. На диаграмме показаны возможности разделения рисков в случае внедрения облачных сервисов. Если мы говорим о полностью своей инфраструктуре, «зеленый столбик» показывает, что на всех уровнях системы управления информационной безопасности риски остаются за нами. Мы не можем их ни с кем разделить, мы можем пожаловаться на них в социальных сетях или еще где-то, на очередной конференции по безопасности, рассказать, как все небезопасно и плохо, но не более того. Но когда речь идет об облаках, которые бизнес получает как сервис, риски железа легко переносятся на сторону того самого провайдера, который эти сервисы предоставляет (конечно, при грамотной юридической обвязке). Инфраструктурные риски в той или иной степени могут быть разделены между собственной службой ИБ и провайдером. Чего греха таить, ведь любая компания может построить кривую инфраструктуру, в которой с безопасностью все будет не очень гладко.

Но что интересно, чем выше глубина предоставления облачных услуг, тем сильнее смещается та самая грань водораздела рисков между потребителем и провайдером. Поэтому метрики эффективности в области безопасности будут разными для собственной инфраструктуры и для облачных сред. 

Нередко перенос серверов в свою инфраструктуру расценивается как увеличение уровня безопасности. Например, руководитель одной из компаний, которым мы предоставлен ИТ-услуги, пришел ко мне и говорит: «А, давайте откажемся от серверов учетных систем в облаке, мы хотим поставить у себя сервер в офисе или в серверной». С одной стороны хорошо, конечно, когда железяка находится условно на расстоянии вытянутой руки. Но с другой стороны оказалось, что в офисе не решены  вопросы по каналам связи, нет гарантий отказоустойчивости. А когда выяснилось, что каждый час простоя этой системы измеряется десятками миллионов, решение о переносе в серверную на физическое оборудование стало выглядеть сомнительным. 

Если говорить о требованиях соответствия законодательству, они до сих пор построены на принципах работы с дискетами и перфокартами (не хочу никого обидеть, но это факт). И когда речь идет про облака и специфику облачной обработки информации, регуляторы еще только готовятся дать какие-то рекомендации и предъявить требования к защите данных в облаке. Поэтому бездумно применять устаревшие требования просто нельзя. Нужно искать общие точки, чтобы помочь бизнесу решить свои задачи, причем сделать это максимально безопасно.

Внутренний регулятор

Учитывая, что внешний регулятор пока не готов предложить четкое руководство по работе с облаками (и вряд ли когда-нибудь сможет сделать это с учетом интересов бизнеса), можно обратиться к внутренней экспертизе. Не важно, строите ли вы свой облачный сервис или планируете обратиться к провайдеру, служба безопасности может стать внутренним регулятором, который поможет сформулировать понятные и прозрачные измеримые требования безопасности. Главное —  подойти к вопросам взаимодействия с точки зрения диалога. 

Чтобы такой подход работал необходимо составить SLA, даже если это внутренний заказ. Договоритесь со службой безопасности, чтобы  получать уведомления о любых инцидентах и анализировать их. Как известно, дьявол кроется в деталях. И если мы говорим о внешних облаках, вся “небезопасность”, как правило, лежит в интеграционном  слое, туда надо смотреть. Необходимо добиться прозрачности коммуникации между внутренним либо внешним провайдером облачных услуг и службой безопасности, которая обеспечивает защиту. Служба ИБ в свою очередь, должна объяснить, почему проекту предъявляются те или иные требования, с чем это связано. По себе знаю, что безопасникам необходимо говорить на понятном языке. 

Те, кто обеспечивает работу сервиса должны, в свою очередь, объяснить, соответствуем ли мы этим требованиям или нет. Рассказать, почему так происходит, предложить какие-то пути компенсации несоответствий. Более того, сегодня надо думать и о DRP: если вы пользуетесь заокеанскими облаками, надо держать в голове, что нас могут отрубить от Интернета. И у подобного инцидента должна быть своя оценка риска, свои ответственные.

Защита сотрудника

Тем не менее современная карта рисков и киберугроз говорят о том, что основной мишенью злоумышленников являются простые сотрудники. Взломать их проще, чем находить уязвимости в ПО. Получить доступ в облачную инфраструктуру намного легче через пользователя этой облачной инфраструктуры. Взять хотя бы взломы Twitter в 2020.

Скачать важную информацию также можно прямо или косвенно, если найти инсайдеров. Поэтому в дополнение к технологически безопасным системам нам необходимо задуматься  и о воспитании культуры поведения сотрудников. Их нужно научить безопасно пользоваться облаками. И для этого службам ИБ и ИТ также нужно объединить усилия, потратить на свое время. 

На мой взгляд роль IT-шников состоит в том, чтобы научить людей правильно пользоваться облаками, не допускать простоев или неразумных технологических нагрузок. А служба безопасности должна курировать вопросы именно воспитания той самой безопасной культуры в компании. 

Конкретно для себя мы составили модель компетенций сотрудника TalentTech с точки зрения безопасного поведения. Были разработаны инструкции, на каком уровне каждый должен уметь пользоваться корпоративными системами, почему он должен использовать двухфакторную аутентификацию для доступа и так далее. Затем с помощью нашей же системы  TalentTech.Обучение (не быть же сапожником без сапог) провели тестирование всех сотрудников компании, выявили пробелы и составили индивидуальный план обучения. За счет обратной связи и повторных курсов сегодня мы непрерывно совершенствуем культуру безопасной работы.

 

Подводя итог хочу сказать, что сегодня я вижу задачу нашей службы не в запретах, а в воспитании в сотрудниках ответственности за обеспечение информационной безопасности. Люди должны понимать, что Google Drive находится на неконтролируемых нами серверах, поэтому некоторая информация там размещаться. 

Я уверен, что в 2021 году служба безопасности должна быть открытой. Я, например, вообще запрещаю своим ребятам уходить в кабинеты. У нас вся служба безопасности работает в Open Space вместе с остальной командой. К нам  подходят ребята и консультируются. Я, кстати, тоже сижу там, если что. 

Расскажите, а как у вас складываются отношения между ИБ и ИТ, когда речь идет о работе с облаками?

Комментарии (5)


  1. baalmor
    28.01.2022 18:50
    +2

    Скорее всего, проблема в том, что в вашем случае ИБ решает/решала вопросы ИБ, а не бизнеса. Собственно говоря вот это: "Нередко перенос серверов в свою инфраструктуру расценивается как увеличение уровня безопасности" об этом и говорит. Просто имеет смысл пересмотреть роль ИБ в компании. Это не отдельная структура со своими задачами, а центр, который помогает решать другим департаментам задачи бизнеса.
    Еще момент - оценка рисков. По моему личному мнению, это довольно бессмысленая затея без модели функционирования бизнеса (с точки зрения ИБ, конечно). Это, по сути дела, карта атак, но выведенная на уровень выше технического. И чаще всего она демонстрирует, что люди хоть и важная, но всего лишь одна из возможных проблем.


  1. somurzakov
    28.01.2022 21:12

    безопасники это те же ИТшники, только более опытные и с фокусом на безопасность, а не операционные функции. Они должны быть технарями в первую очередь, и работать как архитекторы вместе и рука об руку с ИТ и помогать создавать безопасную инфраструктуру для использования ИТ. ИТ это лишь операторы. Безопасники это архитекторы которые создают изначально безопасный дизайн, конфигурацию и следят за поддержанием безопасности (апдейты, патчи, реагирование на инциденты, смена конфигурации и тд)

    например: архитектура сети, как одни подсети общаются с интернетом и корп сетями и разрабами (VPC, GW) - это обязанность безопасников. настройка фаероволов и стандартные темплейты для секьюрити групп.

    образы ОС и создание образов платформ с hardened настройками, центральная авторизация и логгинг, сбор метрик и реагирование на инциденты, сканирование на уязвимости, динамическое и статическое сканирование, периодические пентесты - все обязанность безопасников.

    любую платформу, например endpoint, email, webserver - должны быть 2 человека ответственны, один из ИТ как оператор и другой от безопасников как архитектор.Это дорого, но оправданно на высоких машстабах при большом кол-ве сотрудников.

    автор жалуется на дата инженеров что мол они везде доступ получают и качают данные, так в инфобезе сейчас нереально высокий спрос на своих дата инженеров в безопасности. Когда нужно вытащить данные из десятков разных систем и видеть целую картину. Без данных безопасники как слепые котята - видят только кусочек но не видят общую картину. Какой-нибудь старый древний сервер которые работает в подвале офиса и 100 лет не патчится и о котором никто не знает - только через обработку данных и кросс-корреляцию узнать. Прогуляться автоматом по всем сетевым свитчам и фаерволам и собрать текущую конфигу - через автоматизацию и сбор данных. Прогуляться по всем линуксовым боксам и собрать кто имеет права на sudo - через автоматизацию и сбор данных. Вытащить данные из сканера уязвимостей и потом скоррелировать с SCCM по тому где какие патчи установились, или вытащить данные из Active Directory и сравнить с другими системами.

    уже не говорю про навороченные системы, реагирование на инциденты через машин лёрнинг (IPS, IDS, WAF, SIEM, DLP, UEBA, Anti-Fraud) - везде МЛ щас


    1. ofigenn
      30.01.2022 02:03

      Опытные?) Ха-ха) вы очки розовые снимите, пожалуйста) "должны быть" - вообще забудьте. Как повезёт, так и работает. Безопасник выставит требования, разраб выполнит, появится zeroday, все в заднице) Кто виноват? Никто)


    1. Jammarra
      30.01.2022 13:38

      С каких пор это опытные айтишники и вообще айтишники.

      Безопасники это маратели бумаги.

      Все их существование это имитация бурной деятельности и написание бумаг для прикрытия своей жопы. А жопу всегда легче всего прикрыть просто запретив все что только можно и что нельзя. Что бы в случае любых проблем достать бумажку номер 1953 протокола 4535 от заседания 24451 И сказать: "Мы запретили так делать, сами дураки что не слушались"

      А иначе где были все эти хваленые безопасники, во всех компаниях которые использовали Java (Коих тысячи) и в какие глаза они долбились пропустив Log4j

      Вот честно ни разу еще не видел что бы хоть один безопасник работающий в компаниях. Нашел хоть одну реальную уязвимость в софте компаний или опенсорсе. Речь не про не white hat и людях которы за баунти охотятся. А именно про подразделения "айти безопасности"


  1. gochaorg
    30.01.2022 01:39

    Ну если безопасник занимается запретами, без объяснения, без возможности демонстрации уязвимости, то в шею его надо гнать, и имя ему - диверсант и саботажник, без обид.

    Это если кратко, пару комментариев выше все точно и описали.

    Ещё можно вспомнить, что имеет смысл нанять спецов, которые будут регулярно ломать сервера, назначить им большие премии за успешный взлом.

    Они первые найдут брешь в вашей системе, и это будет лучше, чем нежели это найдет человек ,со злым умыслом, которого вы не знаете.

    Потом, в обязательном порядке, к нему, на обучение отправлять людей, которые допустили сбой.