Вопросы на собеседовании: Инженер безопасности

Триада CIA определяет три главные цели безопасности: конфиденциальность, целостность и доступность.

• Конфиденциальность ограничивает чтение зарплатных данных авторизованными людьми.
• Целостность выявляет несанкционированные изменения, например через подпись артефакта релиза.
• Доступность поддерживает работу сервиса с помощью резервирования, бэкапов и защиты от отказа в обслуживании.

Угроза может причинить вред, уязвимость является слабым местом, а риск объединяет вероятность и влияние эксплуатации.

• Интернет-злоумышленник является угрозой, а непропатченный публичный сервер является уязвимостью.
• Риск растет, если сервер хранит данные клиентов, а рабочий эксплойт опубликован.
• Патч или ограничение внешнего доступа снижает риск, хотя угроза остается.

Вероятность оценивает реальность события, а влияние оценивает возможный ущерб.

• Активная эксплуатация делает атаку на публичный сервис вероятнее, чем на изолированный лабораторный хост.
• Потеря тестовой страницы влияет меньше, чем кража платежных данных из продакшена.
• Команды используют обе оценки для приоритизации, а не считают все находки равными.

Поверхность атаки включает все доступные точки взаимодействия злоумышленника с системой.

• В нее входят API, порты, страницы входа, загрузки, аккаунты, интеграции и физический доступ.
• Забытые поддомены и неиспользуемые административные эндпоинты учитываются, пока доступны.
• Удалить ненужный сервис или право надежнее, чем только наблюдать за ним.

Принцип наименьших привилегий дает пользователю или сервису только права для текущей задачи.

• Сервис отчетов, читающий счета, не должен иметь право удаления в базе.
• Административный доступ лучше выдавать временно, а не привязывать к повседневному аккаунту.
• Периодические ревью убирают доступ, оставшийся после смены роли или обязанностей.

Эшелонированная защита использует независимые уровни, чтобы отказ одного контроля не открыл всю систему.

• Параметризованные запросы предотвращают SQL-инъекцию, а узкие права базы снижают оставшийся ущерб.
• MFA помогает после кражи пароля, а мониторинг сессий все еще выявляет злоупотребление.
• Проверенные бэкапы снижают ущерб, если превентивные и детективные меры не сработали.

После оценки команда может избежать, снизить, передать или принять риск.

• Избежание может убрать ненужный публичный сервис, а снижение может установить патч и ограничить доступ.
• Страховка или договор передает часть потерь, но не снимает техническую ответственность.
• Принятие должно быть явным, ограниченным по времени, записанным и иметь уполномоченного владельца.

Тип контроля показывает, останавливает ли он событие, выявляет его или возвращает безопасное состояние.

• MFA является превентивным контролем, блокирующим многие входы с украденным паролем.
• Алерт о невозможном перемещении является детективным и выявляет подозрительное использование.
• Отзыв сессий и восстановление бэкапа являются корректирующими действиями после компрометации.

Безопасность по умолчанию означает, что новая система начинает работу в безопасном состоянии без ручного усиления.

• Новый аккаунт не получает привилегированную роль до явной выдачи.
• Новое объектное хранилище изначально приватно, а не публично для чтения.
• Опции совместимости не должны незаметно отключать проверку TLS, аутентификацию или аудит.

Граница доверия находится там, где данные или управление переходят между компонентами с разным доверием.

• Ввод браузера при переходе в API остается недоверенным, даже если его создал обычный интерфейс.
• Вызов базы приложением пересекает границу, управляемую учетными данными и сетевыми правилами.
• Каждый переход требует идентификации стороны, валидации, авторизации и полезного журнала безопасности.

Каждая часть HTTP-запроса под контролем клиента является недоверенной.

• Путь, параметры, заголовки, cookie и тело можно изменить через curl или прокси.
• Content-Type описывает данные, но не доказывает их безопасность.
• Сервер проверяет тип, длину, формат, бизнес-правила и авторизацию до использования.

HTTP-методы выражают намерение, поэтому контроли учитывают чтение или изменение состояния.

• GET и HEAD не должны удалять данные, потому что их могут вызвать ссылки и роботы.
• Изменяющие методы требуют авторизации и защиты от CSRF при сессиях на cookie.
• Название метода не является контролем доступа, поэтому каждый эндпоинт проверяет права.

Ошибка должна помогать клиенту действовать, не раскрывая полезные злоумышленнику детали.

• Возвращайте стабильное сообщение, а не стек, SQL-запрос, путь или секрет.
• Подробности пишите на сервере с ID корреляции для сопоставления с ответом.
• Ошибка входа не должна подтверждать существование конкретного аккаунта.

Сессионные cookie обычно используют Secure, HttpOnly и подходящее значение SameSite.

• Secure передает cookie только по HTTPS.
• HttpOnly запрещает чтение из JavaScript и ограничивает кражу токена при многих XSS.
• SameSite сокращает межсайтовую отправку, а узкие Domain, Path и срок дополнительно снижают риск.

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

• Источник объединяет схему, хост и порт, поэтому HTTP и HTTPS различаются.
• Некоторые запросы к другому источнику отправляются, но JavaScript обычно не читает их ответы.
• CORS ослабляет границу для разрешенных источников, а формы и встроенные ресурсы имеют отдельные правила.

CORS является браузерной политикой, определяющей, какие источники могут читать ответы от другого источника.

• Браузер отправляет Origin и может выполнить предварительный OPTIONS-запрос.
• Серверу следует разрешать конкретные источники, особенно при передаче учетных данных.
• CORS не является аутентификацией, не останавливает curl и не заменяет защиту от CSRF.

Клиентская валидация улучшает интерфейс, но пользователь контролирует клиент.

• Злоумышленник удалит JavaScript-проверки, изменит скрытые поля или применит Burp Suite.
• Сервер обязан проверять значения, размер, бизнес-правила и владение.
• Скрытая кнопка администратора не защищает эндпоинт от прямого запроса.

TLS обеспечивает конфиденциальность, целостность и аутентификацию стороны для передаваемых данных.

• Шифрование не дает сетевому наблюдателю читать трафик приложения.
• Проверка целостности делает незаметное изменение практически невозможным.
• Проверка сертификата подтверждает сервер, но TLS не делает код приложения безопасным.

Предупреждение означает, что браузер не смог подтвердить доверенную подлинность сайта, поэтому не обходите его и не вводите чувствительные данные.

• Проверьте URL и часы устройства, потому что неверное имя хоста или дата могут вызвать предупреждение.
• Обычно браузер проверяет имя хоста и цепочку сертификатов до доверенного центра сертификации.
• Остановитесь и сообщите о проблеме, не вводите пароль или платежные данные до исправления.

DNS находит IP по имени, порт выбирает сервис, а межсетевой экран управляет соединениями.

• Браузер может разрешить app.example.com и подключиться к TCP-порту 443.
• Имя хоста все еще нужно для проверки TLS и виртуального хостинга HTTP.
• За разрешенным портом все равно нужны безопасный код, аутентификация и авторизация.