Техническое задание на платформу Security Awareness: что проверить до закупки
изображение: grok
При закупке платформы для обучения сотрудников ИБ-команда часто получает длинный список функций: LMS, фишинговые рассылки, отчёты, интеграции, плагины, автоматизация. Проблема начинается позже, когда выясняется, что формулировки из ТЗ сложно проверить.
Например, требование «система должна поддерживать учебные фишинговые атаки» само по себе мало что говорит. Какие сценарии нужны? Можно ли работать с вложениями, архивами и фишинговыми формами? Как строится сегментация? Что происходит после инцидента? Какие данные попадут в отчёт?
Чем точнее эти условия зафиксированы до закупки, тем проще сравнивать предложения поставщиков и проводить приёмку.
Поэтому ТЗ на платформу Security Awareness лучше строить вокруг рабочих процессов ИБ: обучение, проверка навыков, реакция на действия сотрудника, автоматизация, отчётность и интеграции с существующей инфраструктурой.
Что должно быть в ТЗ
Универсальный шаблон можно разделить на несколько крупных блоков:
- назначение и цели системы;
- общие требования к программному обеспечению;
- обучение сотрудников;
- учебные фишинговые атаки и другие сценарии проверки навыков;
- плагины и расширения;
- автоматизация;
- отчётность;
- интеграции;
- требования к инфраструктуре;
- техническая поддержка и сопровождение;
- порядок проверки соответствия требованиям.
Такое разделение удобно и для ИБ-команды, и для закупщиков. Каждый блок можно связать с конкретным способом проверки.
Например, если в ТЗ указана интеграция с LDAP, при приёмке должна быть возможность подключить тестовый каталог и проверить синхронизацию. Если требуется SSO, нужно заранее определить протокол и сценарий авторизации тестового пользователя.
Обучение: смотрите не на количество курсов, а на управление процессом
Платформа должна закрывать не только сам просмотр учебного материала.
В ТЗ имеет смысл отдельно зафиксировать:
- наличие встроенной LMS или интеграцию с используемой LMS;
- автоматическое назначение курсов;
- уведомления о назначении и приближении дедлайна;
- напоминания о незавершённом обучении;
- возможность отменять и редактировать назначения;
- поддержку SCORM и загрузку собственного контента;
- конструктор учебных материалов;
- тестирование сотрудников;
- сертификаты и срок их действия;
- авторизацию пользователей без повторного ввода логина и пароля;
- управление обучением через веб-интерфейс и API.
Отдельно стоит описать содержание обучения.
В базовом наборе обычно нужны темы, связанные с фишингом, вредоносными вложениями, паролями, конфиденциальной информацией, безопасной работой с компьютером и мобильными устройствами, социальной инженерией, удалённой работой, мессенджерами и социальными сетями.
Сейчас в ТЗ также имеет смысл отдельно учитывать безопасную работу с ИИ. Сотрудник должен понимать, какие корпоративные данные нельзя передавать внешнему сервису и какие риски возникают при использовании ИИ в рабочих процессах.
Одного списка тем недостаточно. Для каждой темы полезно определить, какой навык должен сформироваться и каким способом его можно проверить.
Учебные атаки: заранее зафиксируйте сценарии
Для ИБ-команды этот раздел обычно важнее красивого каталога курсов. Именно здесь можно проверить, умеет ли сотрудник распознавать атаку в рабочем контексте.
В шаблоне предусмотрены разные варианты учебных фишинговых сценариев:
- ссылки;
- вложенные файлы;
- архивы;
- архивы с паролем, который указан в письме;
- фишинговые страницы для ввода учётных данных;
- имитация скачивания вредоносного файла с поддельного сайта.
Для вложений в шаблоне отдельно указано требование поддерживать не менее 15 типов файлов, включая офисные документы.
Полезно также прописать возможности, которые влияют на реалистичность кампаний: планирование рассылок, пакетную отправку, сегментацию пользователей, использование разных шаблонов и привязку следующей кампании к результатам предыдущей.
Например, сотрудникам, которые перешли по ссылке в учебном письме, можно назначить дополнительный курс. Для другой группы можно запланировать повторную проверку через определённый период.
Такой сценарий уже можно проверять как рабочий процесс, а не как наличие отдельной кнопки в интерфейсе.
Не ограничивайтесь электронной почтой
Фишинговая атака может прийти сотруднику не только по email.
В шаблоне предусмотрены учебные сценарии с использованием USB- и HID-устройств, QR-кодов, социальных сетей и мессенджеров.
Это особенно актуально для компаний, где сотрудники регулярно работают со смартфонами, используют корпоративные мессенджеры или имеют доступ к физической инфраструктуре.
При подготовке ТЗ здесь лучше описывать конкретный сценарий. Например: система должна создавать учебную ссылку для QR-кода, учитывать переход пользователя и передавать результат в общую статистику кампании.
Так поставщику сложнее заменить требуемую функцию формальной демонстрацией другой возможности.
Автоматизация: что должно происходить после ошибки сотрудника
Ручное назначение обучения после каждой учебной атаки быстро превращается в отдельную административную работу.
Поэтому в ТЗ стоит описать правила автоматизации.
Например:
- сотрудник перешёл по учебной ссылке;
- открыл вложение;
- заполнил фишинговую форму;
- сообщил о подозрительном письме;
- недавно появился в системе.
После этого система должна выполнять заранее заданное действие: назначить курс, включить пользователя в группу, отправить уведомление или сообщить ответственному сотруднику.
Отдельно стоит проверить автоматизацию для новых сотрудников. При добавлении пользователя система должна уметь определить его как нового и запустить заданный сценарий обучения.
Для крупных компаний также полезна синхронизация пользователей по LDAP или LDAPS с сохранением структуры групп. Тогда организационную структуру не приходится вручную переносить в платформу.
Отчётность должна отвечать на вопросы ИБ
Отчёт «обучение пройдено на 87%» редко помогает принять решение. ИБ-команде нужны данные, по которым можно понять, где именно сохраняется риск.
В ТЗ стоит зафиксировать статистику по учебным атакам:
- сколько писем отправлено;
- сколько открыто;
- сколько пользователей перешло по ссылке;
- сколько совершило небезопасное действие с файлом;
- сколько заполнило фишинговую форму;
- сколько сотрудников сообщили о фишинге.
Для обучения полезны отдельные статусы: назначено, пройдено, не пройдено, просрочено, не начато.
Ещё один полезный показатель, который предусмотрен в шаблоне, это уровень риска пользователей и групп. Он помогает перейти от общей статистики к работе с конкретными категориями сотрудников.
Отчёты должны выгружаться как минимум в используемые внутри компании форматы. В шаблоне предусмотрены CSV, PDF и XLSX, а также передача данных в SIEM через syslog.
Интеграции нужно описывать конкретно
Формулировка «наличие API» сама по себе мало полезна. В ТЗ лучше указывать, какие данные и операции должны быть доступны через API и какие системы требуется подключить.
В шаблоне предусмотрены:
- REST API;
- LDAP и LDAPS;
- SSO на базе SAML 2.0;
- синхронизация по OData V2;
- интеграция с LMS;
- передача событий в SIEM через syslog;
- загрузка пользователей из XLSX, CSV и TXT.
Если в компании уже используются конкретные системы, их стоит указать в ТЗ отдельно. Например, не просто «поддержка SSO», а конкретный протокол и ожидаемый сценарий авторизации.
То же относится к операционной системе и варианту размещения. Для изолированного контура может потребоваться On-Premise-развертывание и работа без доступа в интернет. Это лучше определить до закупки, а не после выбора поставщика.
Плагин для сообщения о фишинге
Отдельная задача, которую стоит включить в ТЗ, это сообщение сотрудником о подозрительном письме.
В шаблоне предусмотрен плагин для почтовых клиентов с передачей исходного сообщения в службу ИБ. Также предусмотрено браузерное расширение для Chromium-совместимых браузеров, которое может уведомлять подразделение ИБ при вводе учётных данных на фишинговом сайте.
Для таких компонентов стоит описать не только факт наличия плагина, но и данные, которые передаются в систему. Например, сообщение пользователя о фишинге должно учитываться в отчётности. Тексты уведомлений и адрес подразделения ИБ должны настраиваться. Это уже можно проверить во время приёмочных испытаний: отправить тестовое письмо, сообщить о нём через плагин и убедиться, что событие появилось в отчёте.
Как превратить ТЗ в инструмент проверки поставщика
Одна из частых проблем закупки платформы состоит в том, что ТЗ существует отдельно от приёмки. Лучше сразу связать требование со способом его проверки.
Например:
| Требование | Как проверить |
| LDAP/LDAPS | Подключить тестовый каталог и проверить синхронизацию |
| SSO SAML 2.0 | Авторизовать тестового пользователя |
| Учебная фишинговая кампания | Создать и запустить тестовый сценарий |
| Автоматическое назначение курса | Выполнить заданное условие и проверить назначение |
| Отчётность | Провести тестовую кампанию и выгрузить отчёт |
| Плагин сообщения о фишинге | Отправить тестовое сообщение и проверить его появление в системе |
Такой подход сокращает пространство для разночтений. Поставщик заявляет поддержку функции, а заказчик заранее знает, какое действие подтвердит её наличие.
Что проверить перед публикацией ТЗ
Готовый шаблон всё равно нельзя использовать без адаптации.
Перед закупкой ИБ-команде нужно определить собственные параметры:
- количество пользователей;
- количество администраторов;
- вариант размещения;
- используемые ОС;
- действующую LMS;
- каталоги пользователей;
- систему единого входа;
- требования к SIEM;
- необходимые почтовые клиенты и браузеры;
- требования к технической поддержке;
- сроки и порядок обновления;
- формат отчётности;
- порядок проведения приёмочных испытаний.
Отдельно стоит разделить требования на обязательные и дополнительные. Иначе в сравнительной таблице поставщиков можно получить длинный перечень функций, которые выглядят одинаково на бумаге, но имеют разное значение для конкретной инфраструктуры.
Ещё одна практическая задача, которую стоит решить до публикации закупки, это проверка требований на избыточную привязку к конкретному продукту. Если формулировка описывает внутреннюю архитектуру определённого решения, но не связана с реальной задачей заказчика, её лучше заменить на измеримое требование к результату.
Скачать шаблон ТЗ
Чтобы не собирать документ с нуля, можно использовать готовый шаблон и адаптировать его под свою инфраструктуру и процесс закупки.
Шаблон включает требования к обучению, учебным атакам, автоматизации, отчётности, интеграциям, плагинам, инфраструктуре и сопровождению. Перед использованием его нужно сверить с фактической архитектурой компании и оставить только те требования, которые действительно будут проверяться при выборе и приёмке платформы.
