1. Определение требований информационной безопасности
Любая система безопасности строится не в вакууме, а для удовлетворения определенных требований. Эти требования поступают из трех основных источников:
- Законодательство и регуляторы: Государство и отраслевые регуляторы устанавливают обязательные для исполнения правила. Несоблюдение грозит огромными штрафами.
- GDPR (General Data Protection Regulation): Европейский регламент по защите персональных данных.
- 152-ФЗ "О персональных данных": Российский аналог GDPR.
- PCI DSS (Payment Card Industry Data Security Standard): Стандарт безопасности для компаний, работающих с данными банковских карт.
- HIPAA: Американский закон о защите медицинской информации.
- Контрактные обязательства: Требования, которые предъявляют к вам ваши клиенты и партнеры. Например, крупный заказчик может требовать от вас наличия сертификата ISO 27001.
- Внутренние бизнес-требования: Цели и задачи, которые ставит перед ИБ сама компания. Например, "обеспечить доступность веб-сайта на уровне 99.9%" или "защитить коммерческую тайну от утечек".
Задача GRC-специалиста — собрать все эти требования, проанализировать их и превратить в единый список задач для ИБ-отдела.
2. Оценка угроз безопасности информации
После того как мы поняли, *что* нам нужно защищать, мы должны понять, *от чего* мы это защищаем. Оценка угроз — это процесс идентификации и анализа потенциальных событий, которые могут нанести ущерб нашим активам.
Основные категории угроз:
- Внешние преднамеренные: Хакеры, киберпреступные группы, спонсируемые государствами группы (APT).
- Внутренние преднамеренные (Инсайдеры): Недовольные сотрудники, которые хотят украсть данные или навредить компании.
- Внутренние непреднамеренные: Ошибки сотрудников (случайно открыл фишинговое письмо, неправильно настроил сервер). Это самая частая причина инцидентов!
- Стихийные бедствия и техногенные катастрофы: Пожары, наводнения, отключение электричества.
- Сбои оборудования: Отказ жесткого диска, перегрев сервера.
Для систематизации угроз часто используют готовые каталоги, такие как БДУ ФСТЭК России или MITRE ATT&CK Framework. Последний — это глобальная база знаний о тактиках и техниках, используемых атакующими. Это "энциклопедия" для Red Team и Blue Team.
3. Разработка моделей угроз безопасности информации
Моделирование угроз — это структурированный подход к анализу безопасности конкретной системы или приложения. Мы как бы ставим себя на место атакующего и пытаемся найти все возможные способы "сломать" систему.
Одна из самых популярных методологий — STRIDE, разработанная Microsoft. Она предлагает искать 6 типов угроз:
| Категория (STRIDE) | Нарушаемое свойство ИБ | Пример |
|---|---|---|
| Spoofing (Подмена) | Аутентификация | Злоумышленник выдает себя за другого пользователя. |
| Tampering (Фальсификация) | Целостность | Злоумышленник изменяет данные в базе или в сети. |
| Repudiation (Отказ от авторства) | Апеллируемость | Пользователь совершил действие, но может отрицать это, т.к. нет логов. |
| Information Disclosure (Раскрытие информации) | Конфиденциальность | Утечка чувствительных данных. |
| Denial of Service (Отказ в обслуживании) | Доступность | DDoS-атака, которая делает сервис недоступным. |
| Elevation of Privilege (Повышение привилегий) | Авторизация | Обычный пользователь получает права администратора. |
Процесс моделирования включает построение диаграммы потоков данных (DFD), а затем анализ каждого элемента и потока на предмет угроз из STRIDE.
4. Составление перечня контролей по действующим требованиям
Контроль (или мера защиты) — это конкретное действие или механизм, направленный на снижение риска, связанного с угрозой. После того как мы определили требования и проанализировали угрозы, мы формируем перечень необходимых контролей.
Этот перечень часто базируется на известных стандартах, чтобы не изобретать велосипед.
- ISO 27001 (Приложение А): Содержит 114 универсальных контролей, от физической безопасности до управления инцидентами.
- CIS Controls (Center for Internet Security): Набор из 18 приоритезированных и очень практичных контролей, которые дают наибольший эффект.
- NIST SP 800-53: Огромный каталог контролей безопасности для федеральных систем США, который часто используется и в коммерческом секторе.
Результатом этого этапа является документ Statement of Applicability (SoA) или "Заявление о применимости", в котором для каждого контроля из стандарта указано, применяется ли он в нашей компании, почему (или почему нет) и как именно он реализован.
5. Разработка организационно-распорядительных документов (ОРД)
Технические контроли не будут работать без организационной поддержки. Документация — это фундамент, который формализует процессы ИБ в компании.
Иерархия документов выглядит так:
Верхний уровень: Политика ИБ
|
+-- Средний уровень: Частные политики (Политика паролей, Политика чистого стола)
|
+-- Нижний уровень: Регламенты, Инструкции (Регламент реагирования на инциденты, Инструкция по настройке Firewall)
- Политика верхнего уровня: Короткий документ, утверждаемый руководством, который декларирует цели и принципы ИБ в компании.
- Частные политики: Раскрывают конкретные области (например, "Политика управления доступом", "Политика резервного копирования").
- Регламенты и инструкции: Детальные пошаговые документы, описывающие, *как* именно выполнять тот или иной процесс. Это рабочие инструкции для инженеров и аналитиков.
Хорошая документация должна быть живой. Ее нужно регулярно пересматривать и актуализировать, особенно после инцидентов или значительных изменений в инфраструктуре.
6. Аудит информационной безопасности
Аудит — это независимая проверка системы на соответствие определенным требованиям (стандарту, политике, закону). Аудит отвечает на вопрос: "Делаем ли мы то, что заявляем в наших документах?".
Виды аудита:
- Внутренний аудит: Проводится силами самой компании (например, отделом внутреннего аудита) для подготовки к внешним проверкам и поиска слабых мест.
- Внешний аудит: Проводится независимой третьей стороной. Результатом может быть отчет о несоответствиях или официальный сертификат (например, сертификат соответствия ISO 27001).
Процесс аудита:
- Планирование: Определение области (что проверяем) и критериев (на соответствие чему проверяем) аудита.
- Проведение ("в поле"): Сбор доказательств. Аудитор проводит интервью с сотрудниками, изучает документацию, наблюдает за процессами, проверяет технические настройки.
- Формирование отчета: Аудитор документирует все свои находки (findings), разделяя их на несоответствия (non-conformities) и рекомендации (opportunities for improvement).
- Последующие действия: Компания разрабатывает план по устранению несоответствий, а аудитор через некоторое время проверяет его выполнение.
7. Практический кейс: Подготовка к аудиту PCI DSS
Вы — специалист по ИБ в интернет-магазине "Cortex Store", который принимает к оплате банковские карты. Ваша компания обязана соответствовать стандарту PCI DSS. Вам поручили провести внутренний аудит и подготовиться к визиту внешнего аудитора (QSA).
Ваша задача: Разработать чек-лист для проверки на основе нескольких требований PCI DSS.
Требования PCI DSS (упрощенно):
- Требование 1: Установить и поддерживать конфигурацию файрвола для защиты данных держателей карт.
- Требование 3: Защищать хранимые данные держателей карт (шифрование).
- Требование 8: Идентифицировать и аутентифицировать доступ к системным компонентам (уникальные ID для каждого пользователя).
Задание:
- Для каждого из трех требований придумайте 2-3 конкретных вопроса, которые вы зададите системному администратору или проверите в настройках.
- Приведите пример организационно-распорядительного документа (название и 2-3 пункта содержания), который должен существовать в компании, чтобы подтвердить выполнение Требования 8.
- Вы обнаружили, что администраторы используют одну общую учетную запись `admin` для управления серверами. Какому из требований это противоречит? Какую угрозу из модели STRIDE это создает?
Этот кейс научит вас "переводить" язык стандартов на язык конкретных технических проверок и документов, что является ключевым навыком GRC-специалиста.