Создание программы безопасности с нуля

Быть нанятым первым специалистом по безопасности в компании — это особый вид хаоса. Нет очереди задач, нет установленного набора инструментов, и обычно нет выделенного бюджета. Дальше идёт примерная карта того, как обычно проходят первые 90–180 дней, и что действительно движет стрелку вперёд, а что просто кажется продуктивным.

Что обычно означает "ничего"

Когда говорят, что в компании нет функции безопасности, редко имеют в виду полное отсутствие контролей. Имеют в виду отсутствие ответственного лица. Engineering, вероятно, включил базовые политики AWS IAM, IT развернул какой-то антивирус через MDM, а кто-то в финансовом отделе имеет мнение о SOC 2, потому что это спросил клиент. Ваша первая задача — инвентаризация, а не внедрение. Прежде чем писать одну политику, узнайте, что уже работает: облачные аккаунты (и сколько их никто не помнит создавших), SaaS-инструменты с администраторским доступом к исходному коду, и есть ли единый источник истины для offboarding сотрудников. Таблица для этого подойдёт. GRC-платформа — не приоритет на данном этапе.

Первые 30 дней: видимость вместо контроля

Устойте к искушению писать политику приемлемого использования на первой неделе. Никто её не прочитает и она не остановит реальные риски. Вместо этого получите видимость по трём направлениям:

• Identity: скачайте полный список пользователей из вашего провайдера идентификации (Okta, Google Workspace, Azure AD) и сопоставьте с активным списком сотрудников из HR. Вы найдёте неактивные аккаунты.
• Cloud footprint: запустите что-то вроде aws organizations list-accounts, если вы на AWS, или проверьте Asset Inventory в GCP, чтобы увидеть, сколько окружений существует против того, сколько может кто-то назвать по памяти.
• Code and secrets exposure: запустите gitleaks detect или trufflehog filesystem . на основных репозиториях. Найти захардкодированный API ключ в истории коммитов двухлетней давности практически гарантировано, и это быстрый способ продемонстрировать ценность.

Документируйте находки, но не превращайте это в 40-страничный отчёт, который никто не откроет. Однострочное резюме по рискам с пятью пунктами прочитает CTO. Длинный PDF — нет.

Выбор первых трёх контролей

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

1. MFA везде, где его ещё нет, начиная с провайдера идентификации, затем GitHub/GitLab, потом облачные консоли. Одно это закрывает самый частый путь перехвата аккаунта.
2. Централизованное логирование облачных событий и аутентификации. Даже бесплатный уровень SIEM-подобного инструмента или просто отправка CloudTrail/GCP audit logs в bucket с retention лучше, чем ничего, когда происходит инцидент.
3. Письменный, краткий план реагирования на инциденты, даже если это две страницы: кого вызывать, кто говорит с клиентами, кто имеет полномочия отключить что-либо. Никто не вспоминает строить это, пока не понадобится, а к тому времени уже поздно.

Обратите внимание, что ничего из этого не требует крупного контракта с поставщиком. Требуются решения и исполнение.

Получение поддержки без выделенного бюджета на безопасность

Быстрый способ потерять доверие как первый специалист по безопасности — прийти со списком желаемых инструментов, прежде чем показать какие-то результаты. Вместо этого привязывайте каждую просьбу к чему-то конкретному: "мы нашли три IAM пользователей с неротировавшимися ключами доступа с 2021 года" звучит лучше, чем "нам нужен CSPM инструмент". Формулируйте просьбы на языке, который уже интересует engineering и finance: сокращение радиуса повреждения, более быстрые аудиты, меньше звонков в 2 часа ночи. Если компания гонится за SOC 2 или ISO 27001, этот дедлайн соответствия часто ваша лучшая точка рычага для получения ресурсов, даже если само соответствие не цель.

Частые ошибки в первый год

Покупка дорогой платформы (SIEM, EDR, CSPM) до того, как у вас есть процессы или сотрудники для её реального управления — самая частая трата раннего бюджета. Инструмент за $50k, который никто не настраивает, генерирует шум, а не обнаружения. Точно так же, писание политик, скопированных из шаблона без адаптации к тому, как компания на самом деле работает, гарантирует, что их проигнорируют в первый раз, когда кому-то понадобится исключение. И попытка владеть всем в одиночку больше первых шести месяцев — это путь к выгоранию; в момент, когда есть продвижение, следующий наём обычно должен быть кто-то, кто может владеть обнаружением и реагированием, чтобы вы могли продолжить строить структуру программы.

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

Если вас интересует этот вид работы по внедрению программы с самого начала, в Korra Studio есть связанные материалы по основам реагирования на инциденты и облачной безопасности, которые хорошо дополняют этот.