Привет! Меня зовут Андрей, и я руковожу командой информационной безопасности в Авито. Я занимаюсь ИБ уже больше 10 лет, и в статье расскажу, как выстроить информационную безопасность в компании с нуля.
Мы рассмотрим два основных подхода к организации ИБ, которые можно применить на старте: основанный на рисках, то есть страхах менеджера, и фреймворках, то есть коллективном опыте индустрии.
Статья будет интересна небольшим компаниям, которые задумываются о выстраивании полноценной системы обеспечения ИБ — фокус будет на её выстраивание с нуля. С другой стороны, описанные подходы могут быть не интересны стартапам: в этой стадии о безопасности думать ещё рановато — нужно заботиться о выживании.
Подход первый: берём за основу риски, о которых говорят руководители
Даже если в компании пока нет выстроенной структуры информационной безопасности, у руководителей наверняка есть список страхов и пожеланий в этой теме. Суть первого подхода — помочь им избежать нежелательных ситуаций.
Алгоритм первого подхода:
Собрать «страхи» менеджеров. Пообщаться не только с вашим непосредственным руководителем, но и с другими менеджерами разных уровней, которые отвечают за разные подразделения организации. Это поможет сформировать более целостную картину и не упустить что-то важное.
Предпочтительнее делать это в формате личной встречи, чтобы лучше понять ход мыслей человека и получить дополнительные инсайты. Но можно и просто попросить заполнить анкету.
В этом пункте есть важный нюанс. Чем больше людей вы опросите, и чем подробнее будет ваш разговор — тем больше страхов и опасений вам расскажут. Важно выделить самые критичные для бизнеса риски, чтобы сосредоточиться на них.
Приоритизировать список рисков. Более объективной будет приоритизация по вероятности возникновения проблемы и масштабу возможного ущерба от неё. Но при выстраивании ИБ с нуля, у вас, скорее всего, не будет статистики, чтобы сделать эту оценку качественно — поэтому можно воспользоваться другими критериями. Например, приоритизировать по количеству упоминаний проблемы, или по статусу менеджера: за сколько подразделений он отвечает, и насколько глубоко погружён в ИБ.
Составить список ответных мер для каждого риска. Обычно меры можно разделить на три категории: технические, организационные и физические.
Технические меры — это программа или железка, которые позволяют снизить риск или полностью защититься от него. Например, двухфакторная аутентификация помогает защититься от подбора пароля и, частично, фишинга.
Организационные меры — это новый процесс или договорённость, которая также снижает риски. Например, регулярный пересмотр прав в системах. Обычно такие меры менее эффективны и требуют больших усилий для реализации, но к ним стоит прибегать, если не удалось найти хороших технических мер.
Физические меры — сейф, забор, видеокамеры и любые другие осязаемые меры безопасности. Эффективные, но применять приходится нечасто, если в ваши задачи не входит защита режимного объекта.Составить такой список с нуля и без соответствующего опыта — непросто. Вам помогут стандарты ИБ, фреймворки и другие инструменты, подробнее о которых мы поговорим в следующем разделе.
Согласовать список рисков и ответных мер с менеджерами. Этот шаг важен, чтобы ещё раз синхронизироваться и убедиться, что намечен правильный путь. На этом этапе можно договориться о дополнительной помощи в реализации мер безопасности, которые, например, требуют вовлечения других подразделений.
После того, как список рисков и мер согласован, стоит подумать о форме отчётности — как руководитель будет оценивать вашу работу, и узнавать о том, скольких проблем удалось избежать. Универсального совета здесь нет: кому-то подойдёт визуальная презентация с графиками, кому-то будет легче читать текст.
По моему опыту, есть важное общее правило — руководители хотят видеть динамику, и поэтому лучше всего рассказывать о своей работе в формате «было-стало». Например, можно привести список идентифицированных рисков, указать, какие ответные меры были внедрены за рассматриваемый период, и какой эффект для снижения рисков они дали.
Подход второй: берём за основу опыт индустрии
В основе второго подхода — многолетний опыт индустрии ИБ, выраженный в огромном количестве разнообразных стандартов, фреймворков и лучших практик. Это не значит, что при этом подходе не стоит учитывать мнение руководителей: просто опираться мы будем не на него, а на опыт индустрии. Этот подход поможет и в том случае, если у менеджеров нет конкретных опасений, и они просто хотят, «чтобы было безопасно».
В дальнейших рассуждениях я буду опираться на CIS Critical Security Controls. На момент выхода статьи актуальная версия 8, которая состоит из 18 контролей. Подробнее можно почитать на сайте CIS.
Кроме CIS Controls, я рекомендую обратить внимание на NIST Cybersecurity Framework. Он устроен сложнее, зато покрывает не только потребности в мерах контроля, но и организационные функции. Почитать можно тут.
После того, как вы изучите и выберите для себя подходящий фреймворк, нужно будет адаптировать его к контексту компании, то есть изучить предлагаемые фреймворком контроли и выкинуть все неприменимые. Например, если вы не разрабатываете собственное ПО, то можно смело исключить категорию Application Software Security. И аналогично поступаете на более глубоких уровнях фреймворка. Не используете Active Directory (ну а вдруг?) — убираем все связанные контроли!
Полученный список контролей нужно приоритизировать. Для этого можно использовать вводные от менеджмента (опросить руководителей по плану, о котором мы поговорили в предыдущем разделе), или использовать собственную экспертную оценку, например, по модели ICE или любой другой привычный вам метод.
Также для приоритизации можно посмотреть на последние инциденты в прессе и проанализировать, в результате чего они случились. Если такой же сценарий атаки применим и для вашей компании — повышаем приоритет соответствующих контролей.
Получившийся список нужно будет согласовать с руководителями. Поскольку во втором подходе, в отличие от первого, вы отталкиваетесь не от их мнения, ваш план может быть менее прозрачен и понятен. Чтобы это преодолеть, я рекомендую на старте договориться про формат отчётности и сделать её регулярной. Обычно, менеджмент предпочитает видеть не просто срез на какую-то дату, а понятное движение в нужном направлении. Для этого можно показывать план-факт («что сделали», «что будем делать») или какой-то другой traction (например, сколько контролей закрыли за квартал и сколько осталось).
Сравниваем два подхода в организации ИБ
Несомненный плюс первого подхода со сбором «страхов» менеджмента — мы работаем с конкретным запросом бизнеса. Это позволяет быстро показать ценность ИБ — это особенно важно на первых этапах организации, чтобы получать поддержку и ресурс. С таким подходом проще обосновать коллегам в процессе реализации, зачем нужны эти меры — есть прямая связь с запросами менеджмента.
С другой стороны, мы рискуем что-то упустить: первый подход не комплексный, и может учитывать только моментальные потребности.
С первым подходом может потребоваться глубокая экспертиза по ИБ, чтобы выработать эффективные меры защиты, потому что готовых ответов под каждую конкретную ситуацию не существует. Но есть и хорошие новости — для этого можно нанять консультантов.
Второй подход с готовым фреймворком — комплексный, и при правильном выборе фреймворка покрывает все аспекты ИБ. Меньше вероятность о чём-то забыть и из-за этого получить инцидент.
Ещё один минус второго подхода — нужно быть готовым доносить до коллег ценность тех или иных контролей на понятном им языке, потому что прямой связи с запросами бизнеса, на которые можно сослаться, не будет.
Не всегда контроли можно внедрить в каноническом виде. В некоторых случаях потребуется идти на компромиссы, в том числе и вместе с коллегами из смежных подразделений.
Сочетаем два подхода к организации ИБ
Из сравнения описанных подходов становится заметно, что они хорошо работают вместе и такой микс нивелирует минусы обоих.
Можно сначала собрать и оценить риски, которые озвучат менеджеры, а затем использовать эту информацию на этапе отбора и приоритизации контролей из стандарта или фреймворка. При этом важно не забыть про оставшиеся контроли.
В таком случае мы получим все плюсы подхода со сбором «страхов» — менеджерский buy-in и понятную ценность для бизнеса, и фреймворков — целостный подход и отсутствие необходимости придумывать меры защиты самостоятельно.
Заключение
В статье я рассмотрел два способа начать выстраивать ИБ в компании. Разумеется, этот список далеко не исчерпывающий, но этих двух подходов или их сочетания достаточно в большинстве случаев.
Какой подход когда применять? Если у менеджмента есть чёткий запрос или хотя бы общие представления о том, что они считают наибольшими рисками для компании — разумнее будет начать со сбора и анализа этих рисков. Если же запрос сформулирован нечётко, например, «сделать безопасно», то лучше использовать готовый стандарт или фреймворк, чтобы не изобретать велосипед.