Он хотел созорничать,
Но не знал, с чего начать
С.В. Михалков. «Дядя Степа»
У меня достаточно много знакомых. С кем-то мы когда-то вместе работали, будучи работниками одной компании, или в разных ролях поставщика или потребителя, с кем-то просто пересекались на каких-либо мероприятиях. Приятно, что приятели и просто знакомые часто просят совета по тем или иным вопросам управления ИБ, еще приятнее узнавать, что мои советы оказались им полезны. В надежде на то, что мои советы окажутся также полезными еще кому-то, этой заметкой я открываю серию публикаций по управлению ИБ.
Герой этой публикации – выдающийся менеджер подразделений ИТ-инфраструктуры, в прошлом хороший сисадмин. На новом месте, помимо прекрасно знакомой ему инфраструктуры получил и направление ИБ. Поскольку ранее ИБ занимался только как исполнитель, пришел за советом с чего начать, об этом и поговорим.
Если мы с вами желаем получить хороший результат в условиях ограниченных ресурсов, то нам в обязательном порядке следует фокусироваться на главном. Фокусировка на главном предполагает сбалансированное отношение к аутсорсингу: что-то делать в рамках подразделений Компании (самому), что-то отдать подрядчику. Аутсорсингу хорошо поддаются только бизнес-процессы, слабо завязанные на корпоративные особенности, кроме того, корпоративные особенности\уникальность, как правило, сконцентрированы именно в ключевых бизнес-процессах, которые нельзя отдавать на аутсорсинг. Безопасность хорошо работает только тогда, когда она интегрирована, поэтому безопасность, тесно интегрированную в ключевые бизнес-процессы и процессы, уникальные для Компании, надо делать самому, а стандартные вещи можно и нужно аутсорсить.
В публикации я писал, что ИБ – это связующее звено между Бизнесом, хорошо знающим корпоративные бизнес-процессы, и подразделениями ИТ, хорошо понимающими отражение корпоративных бизнес-процессов на информационные технологии и как эти технологии на самом деле работают. Т.е. подразделение ИБ понимает, как бизнес-риски проецируются на ИТ, и эксплуатация каких уязвимостей ИТ приводит к реализации этих бизнес-рисков. Вот это самое понимание рисков бизнес-процессов и их проекции на ИТ-системы точно надо делать самому. Какой-то первичный слепок, фреймворк для дальнейшего поддержания и развития, можно получить от подрядчика, но анализ рисков следует делать постоянно\периодически, поэтому лучше сразу осваивать это ремесло, и устанавливать хорошие деловые взаимоотношения с руководителями ключевых бизнес-функций, Внутренним аудитом и ИТ, чтобы потом четко понимать в каких местах вставить какие контроли ИБ (упрощенно можно считать, что Безопасник – это эксперт по контролям ИБ).
Но мой приятель – руководитель ИТ-инфраструктуры, поэтому, в первом приближении ему не следует распыляться на уровни бизнес-приложений и бизнес-процессов, ими автоматизируемых, а на уровне ИТ-инфраструкты надо решить ту же проблему с аутсорсингом: какие-то контроли ИБ реализовать в рамках операционных процессов ИТ, а какие-то .... зааутсорсить. Именно зааутсорсить (!), поскольку ИТ-инфраструктура в большинстве случаев стандартна, не завязана на особенности корпоративных бизнес-процессов. Стандартность инфраструктуры позволяет создать на рынке конкурентное и зрелое предложение, которым лучше воспользоваться, чтобы иметь возможность фокусироваться на действительно важном, что никто за нас точно не сделает. Если, вдруг, как-то так получилось, что корпоративная ИТ-инфраструктура сильно завязана на ключевые бизнес-процессы, то это, скорее, недостаток и лучше поработать над «модульностью», например, применительно к АСУТП я когда-то писал.
Чтобы понять первичный набор контролей ИБ, а за одно и понять текущую ситуацию (приятель только пришел, а верить рассказам не самая разумная стратегия), я порекомендовал провести анализ защищенности в сценарии внешнего злоумышленника с развитием во внутренней сети. Все корпоративные бизнес-приложения завязаны на доменные аутентификацию и авторизацию, поэтому развитие внутри сети – стандартно, до админа в домене. При составлении ТЗ на анализ защищенности (я не раз писал ТЗ на различные аудиты с разнообразными «уклонами»\акцентами, может как-нибудь напишу и об этом, поэтому был готов помочь приятелю и с ТЗ) надо явно указать необходимость уделить повышенное внимание мероприятиям по управлению рисками, связанными с эксплуатацией выявленных в ходе аудита уязвимостей – это и будут наши первые контроли ИБ, которые надо реализовать. Среди полученных контролей, те, которые можно выполнить в рамках существующих процессов TI Operations, например, Управления изменениями – надо брать в работу подразделений ИТ-инфраструктуры, соответствующим образом закрепив их в локальных нормативных документах. На оставшиеся надо посмотреть, скорее всего, их можно прекрасно зааутсорсить в рамках SOC и\или MDR или подписки на DFIRMA. Поскольку пока нет выделенного подразделения ИБ, связывающего Бизнес и ИТ, формального процесса Управления инцидентами тоже нет, поэтому управлять ИБ-инцидентами, пришедшими, скажем из SOC/MDR можно в рамках процесса управления инцидентами ИТ, для чего его надо соответствующим образом, незначительно, модифицировать (как не парадоксально, такой единый процесс Управления инцидентами, на практике, будет даже работать лучше, чем при наличии разных формальных процессов управления инцидентами у ИТ и ИБ).