Как оценить инженеров безопасности: правильный подход
Ловушка найма специалистов по безопасности
Большинство компаний оценивают таланты в области кибербезопасности так же, как любого инженера: тесты кода и триvia. Инженер безопасности пишет код. Они должны быть хороши в алгоритмах и системном дизайне. Но если вы нанимаете только на основе этого, вы упускаете реальный сигнал безопасности — и в итоге получаете умных инженеров, которые не умеют думать об угрозах.
Решение — создать оценку, которая измеряет то, что действительно делают инженеры безопасности: моделирование угроз, рассуждение о компромиссах и архитектурное суждение.
Три компонента оценки, которые работают
1. Сценарий моделирования угроз (30 минут, домашнее задание)
Формат: Опишите систему (например, "Веб-приложение для планирования расписания в здравоохранении с аутентификацией пользователя, обменом календарём и напоминаниями о встречах через SMS"). Попросите кандидата выявить 3 главные риски безопасности, ранжировать их по серьёзности и объяснить смягчение для наивысшего.
Что вы измеряете:
- Могут ли они думать с позиции злоумышленника?
- Рассматривают ли они полную поверхность атаки (API, фронтенд, интеграции третьих сторон, данные в покое)?
- Могут ли они ранжировать риск по вероятности и влиянию, а не по фактору страха?
- Практичны ли их смягчения или теоретичны?
Хороший ответ: Не "убедитесь, что используете HTTPS и параметризованные запросы" — все это знают. Хороший ответ выглядит так: "Самый высокий риск — перехват SMS для напоминаний о встречах, потому что канал SMS не зашифрован и злоумышленник с доступом к SMS может перепланировать встречи или прочитать имена пациентов. Смягчение: не отправляйте идентификаторы пациентов в SMS, только код, который они используют для локального поиска. Второй риск: неавторизованный обмен календарём, если логика обмена не валидирует владение правильно — тестируйте, что вы не можете поделиться календарём кого-то другого. Третий: credential stuffing при входе — внедрите ограничение по IP и по имени пользователя, и предложите вход без пароля."
Этот ответ специфичен, основан на реальной системе, и различает неизбежный и предотвратимый риск.
2. Обзор кода + суждение об уязвимостях (45 минут)
Представьте реалистичный фрагмент кода с скрытой уязвимостью. Примеры:
Python фрагмент с риском SQL-инъекции, маскирующейся под "безопасный":
query = f"SELECT * FROM users WHERE email = '{email}'" # Отмечено как плохо
Но спросите: "Каков реальный риск здесь?" Кандидат, который скажет "SQL-инъекция" технически прав, но неполный. Кандидат, который скажет "SQL-инъекция, да, но только если входные данные email не валидированы сначала — какая валидация?" думает как инженер безопасности.
Что вы измеряете:
- Могут ли они заметить уязвимость?
- Понимают ли они контекст (является ли она действительно эксплуатируемой)?
- Рекомендуют ли они чрезмерные исправления или пропорциональные?
Хороший ответ: "Это инъекционный SQL. Исправление — параметризованные запросы, что является стандартом. Но перед тем как это рекомендовать, я бы проверил: уже ли email валидируется с безопасным паттерном выше по течению? Если да, риск ниже. Если нет, да, исправляйте немедленно. Также, возвращает ли этот запрос чувствительные данные? Если это просто поиск для общего эндпоинта, профиль риска отличается от возврата хешей паролей."
3. Оценка архитектуры: защита в глубину (60 минут)
Дайте им проблему архитектуры: "Разработайте слой аутентификации для платформы с публичными и приватными API, где компрометация токена катастрофична. Защитите ваши выборы."
Что вы измеряете:
- Слоят ли они защиты (токены + ограничение по частоте + ограничение по IP)?
- Могут ли они объяснить, почему одного управления недостаточно?
- Думают ли они об обнаружении и восстановлении, а не только о предотвращении?
- Могут ли они обосновать компромиссы (безопасность против трения разработчика)?
Хороший ответ: "Я бы использовал короткоживущие токены доступа (15 минут) с токеном обновления в HttpOnly cookie. Публичные API получают более агрессивное ограничение по частоте. Для приватных API я бы добавил ограничение по пользователю и подписание запроса (HMAC). Для компрометации токена: немедленно ротируйте секреты и принудительно переаутентифицируйте. Я бы также логировал всё создание токенов и следил за паттернами быстрых запросов токенов. Это переусложено для всех систем? Да. Но для платформы, чувствительной к данным, стоимость взлома превышает стоимость инженерии."
Как взвешивать оценку
Если вы нанимаете обобщённого специалиста по безопасности:
- 40% моделирование угроз (могут ли они думать об риске?)
- 30% обзор кода (могут ли они найти проблемы?)
- 30% архитектура (могут ли они проектировать защитно?)
Если это инженер безопасности (в отличие от pentester'а или архитектора безопасности), вы можете сместить 50/30/20. Аналитик SOC имел бы другой приоритет: упор на триаж и сценарии реагирования на инциденты.
Последующий интервью важен
Асинхронная оценка даёт вам сигнал, но не полный. В последующем интервью спросите:
- "Пройдитесь по вашему моделированию угроз. Что вы упустили? Что бы вы пересмотрели?"
- "Как бы вы объяснили это смягчение инженеру, который говорит 'это переусложено'?"
- "Расскажите о времени, когда вы должны были уравновесить безопасность и скорость."
Последующее интервью показывает, может ли он объяснить себя и терпеть возражения — критично для инженера безопасности, который должен влиять на всю организацию.
Чего НЕ оценивать
- Запомненный OWASP Top 10 (они могут загуглить)
- "Какой шифр лучший?" trivia (контекстзависимо в любом случае)
- Скорость решения головоломок в стиле LeetCode (не релевантно работе безопасности)
- Прохождение конкретного сертификата (сертификаты — пол, не потолок)
Собственная или готовая оценка
Некоторые платформы предлагают готовые оценки кибербезопасности. Они — начало. Но лучшие оценки кастомизированы под вашу роль и модель угроз. Инженер безопасности в здравоохранении и в fintech сталкиваются с разными проблемами. Покупайте платформу; создавайте вопросы.
ClarityHire предлагает кастомизируемые оценки безопасности с живыми комнатами кода, загрузкой файлов для диаграмм архитектуры и многоэтапной оценкой. Вы также можете сочетать оценки с живыми техническими интервью для более глубокого погружения в рассуждения.
Результат
Оценивайте рассуждение об угрозах, не trivia, и вы нанимаете инженеров, которые думают защитно по умолчанию. Эти инженеры становятся умножителями силы — они влияют на всю инженерную культуру вашей организации в сторону принятия решений, ориентированных на безопасность.
Это найм, который имеет значение.