Безопасность из облака: почему между ИБ и ИТ необходим открытый диалог

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

Источник: https://habr.com/ru/company/talenttech/blog/648381/


Интересные статьи

Интересные статьи

Работа над общей библиотекой сильно отличается от работы в продуктовой команде. Но разработчики библиотек тоже проходят длинный путь становления своего продукта, причем, в отличие от приложений, часто...
Внутреннее тестирование на проникновение, одна из самых сложных и при этом впечатляющих услуг на рынке. Впечатляющих в первую очередь для руководства, ведь за несколько дней, а иногда и часов, пентест...
Источник Судя по всему, искусственный интеллект узнал о человечестве достаточно. Пора ему уже кое-что забыть, а именно персональные данные людей. Решение этой задачи человечество ищет с помощью нов...
Там, где есть разработчики, рядом должны быть и тестировщики. И чем сложнее система, тем важнее роль последних. Но не все тестировщики выполняют одну и ту же функцию одинаково, и сего...
Дано:1. Корпоративное iOS-приложение, реализованное только под форм-фактор Apple iPad с устаревшим дизайном (особенно, если изучать гайдлайны Apple).2. Заказчик = крупное...