Когда компания только начинает задумываться про управление информационной безопасностью и системной защите своих данных и инфраструктуры, встаёт закономерный вопрос: с чего вообще начинать? Рынок предлагает тонны стандартов, регуляторы пугают проверками, а бюджет на безопасность обычно ограничен. Я много раз наблюдал, как в такой ситуации можно пойти двумя разными дорогами. Обе имеют право на жизнь, и сейчас я расскажу, почему.
Первый подход: когда за основу берутся менеджерские страхи
В любой компании, даже там где про информационную безопасность никто всерьёз не задумывался, у руководства есть определённые опасения. Кто-то боится, что конкуренты украдут базу клиентов. Кого-то триггерит история про уволенного программиста, который может намусорить в коде. Третий переживает, что бухгалтерия попадётся на фишинговое письмо.
Суть метода проста до безобразия - взять эти страхи за фундамент.
Шаг первый: собираем фобии.
Идёте не только к своему непосредственному начальнику, но и к другим ключевым людям. Руководитель производства скажет про остановку станков, финансовый директор - про подделку платёжек, коммерческий - про утечку коммерческих предложений. Личный разговор всегда даёт больше, чем анкета. Человек может рассказать какую-то бытовую историю, и из неё вытаскивается настоящая боль.
Здесь важно не утонуть в потоке информации. Чем больше опрашиваешь, тем больше проблем вылезает. Задача - отсечь второстепенное. Не пытайтесь закрыть всё сразу, иначе завалите даже базовые вещи.
Шаг второй: раскладываем по приоритетам.
В идеальном мире мы бы оценивали вероятность катастрофы и сумму ущерба. В мире начинающей ИБ-службы у вас нет статистики, чтобы это посчитать. Я обычно советую использовать два заменителя точной математики: частоту упоминаний и статус менеджера. Если о проблеме говорят трое разных директоров - это звоночек. Если о ней говорит генеральный - это сирена.
Шаг третий: подбираем лекарство.
На каждый риск нужно накидать меры защиты. Тут включаем фантазию и делим всё на три корзины:
- Технические решения. Поставили антивирус, внедрили двухфакторку, настроили файрвол. Железо и софт - это то, что работает само, когда настроено правильно.
- Организационные штуки. Подписали бумажку, что пароль меняется раз в месяц. Провели инструктаж для новичков. Написали политику, что флешки с улицы не вставляем. Это дешевле техники, но требует постоянного контроля и напоминаний, потому что люди склонны забывать о договорённостях.
- Физическая защита. Поставили сейф для сервера, навесили замок на серверную, купили шредер для бумаг. Актуально реже, но если актуально - без этого никак.
Самое сложное - придумать меры, если у вас нет богатого опыта. Здесь выручают стандарты, о которых речь пойдёт дальше. Их можно использовать как шпаргалку.
Шаг четвёртый: синхронизация с менеджерами.
Возвращаетесь к тем, чьи страхи собирали, и показываете список: вот что вы боитесь, а вот что я предлагаю с этим сделать. На этом этапе часто удаётся договориться о помощи - например, что отдел кадров будет включать в офферы пункт о неразглашении, или что сисадмины выделят окно для обновлений.
Шаг пятый: думаем про отчётность.
Руководитель должен видеть результат вашей работы. Мой любимый формат - «было - стало». Показываем, что раньше риск утечки через почту висел дамокловым мечом, а после внедрения DLP-системы мы спим спокойнее. Графики, цифры, короткие выводы. Никто не хочет читать простыни текста, всем нужна динамика.
Второй подход: когда доверяемся коллективному разуму индустрии
Если у руководителей нет чётких страхов, или они говорят расплывчатое «сделайте нам безопасно», первый подход не работает. Приходится брать за основу то, что наработано мировой практикой. Стандартов много, я предпочитаю начинать с CIS Critical Security Controls.
Актуальная восьмая версия CIS Controls предлагает 18 направлений, от управления активами до реагирования на инциденты. Альтернатива - NIST Cybersecurity Framework, он более замороченный с организационной точки зрения, но покрывает не только технику, но и управленческие процессы.
Как работать с фреймворком.
Не надо тупо внедрять всё подряд. Сначала адаптируем стандарт под реальность. Не пишете софт - вычёркиваем всё про безопасность разработки. Нет Active Directory - убираем связанные с ней контроли. Оставляем только то, что физически применимо к вашей инфраструктуре.
Дальше полученный список нужно ранжировать. Тут без опроса руководителей снова не обойтись, но теперь их мнение не основной драйвер, а лишь один из факторов. Можно использовать модель ICE (Impact, Confidence, Ease) или просто опираться на собственную экспертизу.
Хороший приём - мониторить инциденты в новостях. Если очередной крупный банк лёг из-за атаки на веб-интерфейс, а у вас тоже есть внешние сервисы, контроли по защите веб-приложений улетают в топ приоритета.
Как продать это бизнесу.
Тут сложнее, чем в первом подходе. Вы приходите не с решением их прямой боли, а с абстрактным «так надо». Чтобы не нарваться на непонимание, договаривайтесь о прозрачной отчётности с самого начала. Показывайте план-факт: вот сколько контролей закрыли, сколько осталось, какая динамика. Люди любят наблюдать за движением к цели, даже если сама цель им не до конца ясна.
Где подвох в каждом из методов
Первый подход со страхами прекрасен тем, что бизнес видит ценность мгновенно. Вы закрываете то, что реально болит. Это даёт кредит доверия, ресурсы и лояльность коллег, которые понимают, зачем вы лезете в их процессы.
- Но у него есть ахиллесова пята. Вы можете построить защиту только вокруг того, о чём сказали вслух. А вдруг менеджеры не знают про какую-то угрозу? Вдруг они не в курсе, что инсайдеры сливают данные не по злому умыслу, а случайно, через криво настроенные общие папки? Фокус на моментальных потребностях оставляет слепые зоны.
- Кроме того, этот подход требует от вас высокой квалификации. Под каждый конкретный страх нужно придумать конкретное техническое или организационное решение. Если вы новичок, можете ошибиться. Хорошая новость - всегда можно нанять консультантов под конкретную задачу, это часто дешевле содержания целого отдела.
Второй подход на базе фреймворка страхует от забывчивости. Стандарты писали умные люди, которые уже учли все возможные векторы атак. Комплексность здесь главный козырь. Вы точно не пропустите что-то важное, если правильно выполнили адаптацию.
Плата за комплексность - сложность коммуникации. Коллеги из других отделов могут искренне не понимать, зачем вы просите их что-то делать. Прямой связи с их «хотелками» нет, приходится каждый раз изобретать язык убеждения. И ещё один минус - не все контроли внедряются один в один как в учебнике. Часто приходится искать компромиссы, договариваться, урезать функционал, и это нормально.
Для наглядности я свел основные различия в небольшую таблицу. Она помогает объяснить руководству, почему мы не можем просто выбрать один метод и забыть о другом.
| Критерий | Подход на страхах | Подход на фреймворках |
|---|---|---|
| Источник требований | Интервью с менеджментом | Отраслевые стандарты (CIS, NIST) |
| Скорость демонстрации ценности | Высокая (решаем конкретную боль) | Низкая (долгий процесс внедрения) |
| Риск пропустить угрозу | Высокий (слышим только то, о чём спросили) | Низкий (фреймворк даёт полную картину) |
| Сложность коммуникации с коллегами | Низкая (работаем на понятном языке бизнеса) | Высокая (приходится объяснять "почему это важно") |
| Требования к компетенциям ИБ-специалиста | Нужно придумывать решения самому или звать консультантов | Достаточно правильно адаптировать готовые контроли |
Как скрестить ужа с ежом
На самом деле эти два подхода не конкуренты, а отличная связка. Соберите сначала страхи и пожелания менеджеров. Получите список того, что волнует бизнес здесь и сейчас. А потом наложите этот список на выбранный фреймворк.
Смотрите: у вас есть контроли из CIS, и есть менеджерские риски. Вы приоритезируете внедрение тех контролей, которые закрывают актуальные страхи. Это даёт быструю победу и видимость результата. Но при этом вы не забываете про остальные контроли из фреймворка, просто ставите их во вторую и третью очередь.
Такой микс даёт лучшее из двух миров. С одной стороны, бизнес получает ответы на свои запросы и видит вашу полезность. С другой стороны, вы строите системную защиту, а не латаете дыры по крику. Плюс вам не нужно самостоятельно выдумывать меры защиты - стандарт уже подсказывает, что делать с каждой угрозой.
На практике я всегда рекомендую начинать именно с гибрида. Потратьте две недели на интервью с ключевыми людьми, запишите всё, что они боятся потерять или сломать. Параллельно выберите фреймворк, который ложится на вашу инфраструктуру. Потом сядьте и сопоставьте. Там, где страхи совпадают с контролями - делаем в первую очередь и громко отчитываемся о победе. Остальное внедряем планомерно, квартал за кварталом, не забывая объяснять команде, зачем мы это делаем.
Этот путь не самый быстрый и не самый простой. Но он единственный, который позволяет выстроить безопасность, которая действительно работает, а не просто висит мёртвым грузом на балансе.
