4️⃣ Корректирующие меры (Corrective)
📌 Цель: Устранить причину инцидента и предотвратить его повторение.
🔐 Примеры:
- Исправление уязвимостей – изменение кода, обновление конфигурации.
- Блокировка скомпрометированных учетных записей.
- Обновление политики безопасности – например, усиление паролей или переход на MFA.
❓ Вопросы для выявления требований:
- Какие шаги необходимо предпринять для устранения последствий инцидента? Кто и как будет это делать?
- Как гарантировать, что корректирующие меры не повлияют на функционирование системы в целом?
- Как можно улучшить процессы, чтобы предотвратить повторение инцидентов?
- Каковы процедуры восстановления после инцидента, включая управление изменениями?

5️⃣ Компенсирующие меры (Compensating)
📌 Цель: Предоставить альтернативный способ защиты, если основная мера недоступна.
🔐 Примеры:
- Физический доступ вместо цифрового – вход в помещение по смарт-карте вместо системной аутентификации.
- Ограничения на сетевом уровне вместо защиты на уровне приложения – если приложение не поддерживает двухфакторную аутентификацию, можно ограничить доступ к нему только из корпоративной сети.
❓ Вопросы для выявления требований:
- Какие меры защиты можно применить, если основные средства безопасности недоступны?
- Каковы альтернативы для обеспечения защиты в случае отказа основной меры?
- Не создадут ли новых угроз безопасности компенсирующие меры?
- Какие требования должны быть выполнены для того, чтобы компенсирующие меры были эффективными?

🎯 Вывод
✅ Разные меры информационной безопасности работают в комплексе – от предотвращения атак до восстановления после инцидента.
✅ Использование разных типов мер повышает защиту и снижает риск реализации угроз.

🔐 Для обнаружения, предотвращения или смягчения рисков, связанных с угрозами информационной безопасности, принимаемые меры делятся на пять основных типов: превентивные, детективные, восстановительные, корректирующие и компенсирующие. В этом и следующем постах разберу зачем нужен каждый тип мер, приведу примеры таких мер и некоторые вопросы, которые помогут вам в выявлении требований к безопасности. ⬇️

1️⃣ Превентивные меры (Preventive)
📌 Цель: Предотвратить инцидент до его возникновения.
🔐 Примеры:
- Аутентификация и авторизация – ограничивает доступ к системе только для проверенных пользователей.
- Минимальные привилегии – пользователи и процессы получают только те права, которые им необходимы.
- Фильтрация входных данных – предотвращает SQL-инъекции и XSS-атаки.
- Юридические уведомления – предупреждение о правовых последствиях несанкционированного доступа.
❓ Вопросы для выявления требований:
- Какие потенциальные угрозы существуют для системы?
- Как можно минимизировать риски, связанные с каждой угрозой?
- Какие защитные меры должны быть внедрены для предотвращения инцидентов?
- Не создадут ли новых угроз безопасности внедрённые меры?
- Что нужно выполнить, чтобы предотвратить ошибки пользователей?
- Какие меры могут отпугнуть злоумышленников и снизить вероятность атаки?
- Какие процессы/инструкции должны быть разработаны для повышения осведомлённости сотрудников и пользователей о безопасности? Что для этого целесообразно реализовать на уровне ПО?

2️⃣ Детективные меры (Detective)
📌 Цель: Обнаружить инцидент и собрать данные для анализа.
🔐 Примеры:
- Логирование событий – запись действий пользователей и систем.
- Мониторинг аномалий – обнаружение подозрительной активности (например, SIEM-системы).
- Системы обнаружения вторжений (IDS) – выявляют несанкционированный доступ.
❓ Вопросы для выявления требований:
- Какие события в системе должны логироваться для выявления инцидентов?
- Какая информация о событиях потребуется при анализе инцидентов?
- Как интегрировать средства мониторинга с существующими системами безопасности?
- Какие методы защиты (маскирование, хеширование, анонимизация) должны быть применены для защиты конфиденциальной информации в логах, чтобы исключить её утечку в случае доступа к журналам?
- Какие механизмы отчётности и оповещений нужны для своевременного обнаружения угроз?
- Как обеспечить хранение и защиту данных для последующего анализа инцидентов?
- Как долго необходимо хранить информацию о событиях в системе?

3️⃣ Восстановительные меры (Recovery)
📌 Цель: Вернуть систему в нормальное состояние после инцидента и минимизировать последствия.
🔐 Примеры:
- Восстановление данных из резервных копий.
- Переключение на резервный сервер (failover).
- Выполнение Disaster Recovery Plan (DRP).
❓ Вопросы для выявления требований:
- Какие компоненты системы должны быть восстановлены в первую очередь после инцидента?
- Какие данные должны быть защищены и восстановлены, чтобы минимизировать последствия инцидента?
- Какую информацию нужно предоставить пользователям о восстановлении системы?
- Какие процедуры тестирования должны быть внедрены для проверки восстановления?
- Какое максимальное время простоя системы или её компонентов является приемлемым для бизнеса, чтобы минимизировать убытки?
- Какие процессы восстановления необходимо автоматизировать, чтобы ускорить время восстановления?
- Какое количество данных может быть потеряно без значительного ущерба для бизнеса?

продолжение в следующем посте

Security Patterns: Как применять их в проектах?

Если вы работаете с безопасностью, то знаете: одни и те же проблемы встречаются снова и снова. Вместо того чтобы каждый раз придумывать решение с нуля, можно использовать security patterns — шаблоны защиты для типовых угроз.
На сайте securitypatterns.io есть отличное руководство How to Write a Security Pattern, которое объясняет:
✅ Как описывать угрозы, контекст и меры защиты в виде понятных шаблонов.
✅ Как связать угрозы с конкретными мерами безопасности (и обосновать их выбор).

Второй полезный гайд - How to Use a Security Pattern - как внедрять security patterns в проекты.
Security patterns отлично вписываются в Agile, позволяя внедрять безопасность итеративно, без торможения процессов. Это значит:
✅ Фокус на конкретных активах и угрозах.
✅ Интеграция security patterns в спринты.
✅ Четкое понимание приоритетов мер защиты через риск-ориентированный подход.

Вопросы, которые помогает решить security patterns:
🔹 Какие меры защиты стоит внедрять в первую очередь?
🔹 Как отслеживать выполнение требований безопасности?

На сайте есть примеры security patterns:
🔹 Code Management
🔹 Container Platform
🔹 Container Orchestration
🔹 Service Mesh
🔹 API Microservices
🔹 API Services

Security patterns - практический инструмент для архитекторов, инженеров и аналитиков. Они не заменяют процессы безопасности, но делают их структурированными, воспроизводимыми и адаптивными.

Сегодня продолжим рассмотрение принципов информационной безопасности и поговорим о принципе "Минимальные привилегии" (Least privilege).

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

Как реализовать принцип минимальных привилегий?
🔹 Использовать правило "deny by default" (или "Запрещено всё, что явно не разрешено") - по умолчанию запрещать доступ и разрешать его только при явной необходимости.
🔹 Ограничение административных привилегий: не назначайте пользователям права администратора, если это не необходимо.
🔹 Разделение обязанностей: пользователи и процессы должны иметь доступ только к тем данным и функциям, которые им нужны. (согласуется с принципом Separation of Duties)
🔹 Использование ролевой модели контроля доступа (RBAC, Role-Based Access Control) или атрибутной модели (ABAC, Attribute-Based Access Control).
🔹 Минимизация привилегий у системных сервисов.
🔹 Регулярные аудиты прав доступа и их пересмотр по мере необходимости.

Примеры реализации принципа Least Privilege:
1️⃣ Пользователь с ролью "Оператор отчётов" должен иметь доступ только к функциям просмотра и выгрузки отчетов, но не к настройке системы.
2️⃣ Сервисный аккаунт, выполняющий резервное копирование, должен обладать правами только на чтение исходных данных и запись в область резервных копий, но не на их удаление.
3️⃣ База данных предоставляется приложению с минимальным набором разрешений (например, только SELECT, INSERT, UPDATE, а не полный доступ с правами DELETE и DROP).
4️⃣ Доступ к конфигурационным файлам системы ограничен только для пользователей, которым действительно необходимо их редактировать.

Как системные аналитики могут проверять соблюдение этого принципа?
🔍 Анализ вариантов использования (Use Cases): определите, какие операции необходимо выполнять каждому субъекту, и проверьте, какие права ему выданы.
📜 RACI матрица: определите, кто отвечает за выполнение каждой задачи, и убедитесь, что роли не обладают избыточными полномочиями.
📰 Матрица доступа: составьте таблицу соответствия ролей и разрешений.

#принципы_ИБ

Attacker Story: инструмент для работы с угрозами ИБ
В субботу я выступал на конференции Analyst Marathon #12 с докладом о двух практиках моделирования угроз: Abuse Cases и Attacker Story. По Abuse Cases у OWASP есть Cheat Sheet.

Про Attacker Story решил рассказать коротко в этом посте.
В традиционной разработке мы используем User Stories, описывая, как пользователь взаимодействует с системой для достижения своих целей.
Но что, если пользователь — злоумышленник?

Здесь на помощь приходит Attacker Story - техника, позволяющая структурированно описывать угрозы и учитывать их при разработке требований к ИБ. Я встречал ещё термины Evil User Stories и Abuser Stories.

Я использую следующую структуру Attacker Story:
📌 As a , I want using in order to .

Пример User Story и Attacker Stories
User Story:
👉 Как клиент, я хочу перевести деньги между своими счетами, чтобы управлять своими финансами.

Attacker Stories:
🔴 Как мошенник, я хочу подменить реквизиты перевода, используя возможность перехвата данных в незашифрованном канале, чтобы получить деньги на свой счёт вместо счёта жертвы.
🔴 Как мошенник, я хочу совершать переводы от имени клиента банка, используя украденный идентификатор сессии, чтобы перевести деньги клиента банка на свой счёт.

Что делать после выявления Attacker Stories?
После моделирования угроз с использованием Attacker Stories мы разрабатываем контрмеры (требования к ИБ), чтобы минимизировать риски от выявленных угроз. Эти контрмеры:
✅ Добавляются в Acceptance criteria для исходной User Story.
✅ Или оформляются как отдельные User Stories.

Использование Attacker Story помогает приоритизировать требования к ИБ, так как становится очевидно, какие угрозы они нейтрализуют (или снижают вероятность их реализации) и какие последствия могут наступить для бизнеса в случае игнорирования этих угроз.

#ThreatModeling #OWASP #AttackerStory

🚀 Приглашаю на Systems Design Online с докладом на тему по информационной безопасности!

Меня пригласили куратором секции по информационной безопасности на конференции Systems Design Online, и теперь моя задача — выбрать интересные доклады.

Тема этого года на конференции:
Компромиссы проектирования — баланс между атрибутами качества (включая безопасность), финансированием и сроками.

📌 Если у вас есть опыт, мысли или кейсы про:
🔹 Компромиссы между безопасностью, бюджетом и сроками
🔹 Встраивание безопасности в SDLC
🔹 Реальные истории про security-фейлы и как их избегать на этапе проектирования
🔹 Что угодно ещё на стыке security и системного проектирования,

…то давайте делать доклад!

🗓 Когда?
12 апреля (суббота) - день докладов
13 апреля (воскресенье) - воркшопы

🌏 Онлайн, так что можно участвовать из любой точки мира.

Пишите в личку или в комментариях, если хотите участвовать, обсудить тему или уточнить детали участия!

ASVS: практическое руководство по требованиям к безопасности
Когда речь заходит о требованиях к безопасности, системные аналитики часто сталкиваются с вопросом: на что опираться? Один из самых полезных, на мой взгляд, документов — OWASP Application Security Verification Standard (ASVS).

Что такое ASVS?
ASVS – это стандарт проверки безопасности приложений, разработанный OWASP (Open Worldwide Application Security Project). Он представляет собой список требований безопасности, которые необходимо учитывать при разработке приложений. Имеется перевод на русский язык.

Документ структурирован по 14 категориям:
1️⃣ Архитектура, проектирование и моделирование угроз
2️⃣ Аутентификация
3️⃣ Управление сессиями
4️⃣ Контроль доступа
5️⃣ Валидация входных данных
6️⃣ Криптография и защита данных
7️⃣ Обработка ошибок и логирование
8️⃣ Безопасность API и web-сервисов
9️⃣ Защита от вредоносного кода
🔟 Безопасность бизнес-логики
... и другие.

Каждая категория содержит конкретные требования, разбитые на 3 уровня соответствия, каждый из которых усиливает требования предыдущего:
Уровень 1 – базовые требования для всех приложений.
Уровень 2 – для приложений, обрабатывающих конфиденциальные данные (является рекомендуемым).
Уровень 3 – для критичных приложений с высокими рисками.

ASVS в Agile
Чтобы интегрировать требования ASVS в гибкие методологии разработки, существует ASVS Agile Delivery Guide. Он помогает формулировать требования безопасности в виде User Stories и BDD сценариев.

Пример использования ASVS и ASVS Agile Delivery Guide
📌 Требование ASVS 13.1.3
URL-адреса API не содержат конфиденциальной информации (ключ API, сессионный токен и т.д.)
Связанная уязвимость: В требовании 13.1.3 есть прямая ссылка на уязвимость CWE-598, которую закрывает данное требование. Рекомендую ознакамливаться, чтобы понимать, зачем необходимо это требование.
В описании уязвимости CWE-598 сказано, что если веб-приложение использует метод GET для обработки запроса и передает конфиденциальные данные в query string, то это может привести к их утечке, так как:
- URL с конфиденциальными данными может сохраняться в истории браузера.
- Данные передаются в HTTP Referer при переходе на другой сайт.
- Запросы с query string могут сохраняться в логах веб-сервера.
- Конфиденциальная информация может быть записана в кеш браузера или proxy-серверов.

📌 User Story из ASVS Agile Delivery Guide:
Как инженер по безопасности, я хочу убедиться, что конфиденциальная информация не передается в URL API, чтобы защитить её от несанкционированного раскрытия

📌BDD cценарий из ASVS Agile Delivery Guide:
Scenario: Использование метода POST для передачи конфиденциальных данных
Given необходимость обработки 'конфиденциальной информации', такой как API-ключи, токены сессий, учетные данные
When передается эта 'конфиденциальная информация'
Then используется метод POST, чтобы информация не отображалась в URL

#ASVS #OWASP

Сегодня говорим о принципе Separation of Duties (Разделение обязанностей) в информационной безопасности.
💡 Что значит этот принцип?
Separation of duties основан на том, что важные операции должны выполняться не одним человеком или системой, а разделяться между несколькими участниками. Это снижает риск мошенничества, ошибок и злоупотреблений.

🔍 Примеры применения:
1️⃣ В банках: один сотрудник инициирует перевод, другой – подтверждает.
2️⃣ В разработке ПО: один человек пишет код, другой проверяет (код-ревью).
3️⃣ В администрировании: админ не должен иметь права утверждать свои же запросы на доступ.
4️⃣ В бухгалтерии: один сотрудник выписывает счета, другой их оплачивает.

⚙️ Какие техники анализа помогут проверить соблюдение принципа?
1️⃣ Data Flow Diagram (DFD) или Use Case Diagram
- Определите, какие пользователи или системы выполняют операции с чувствительными данными.
- Проверьте, не замыкается ли весь процесс на одной роли или системе без независимого контроля.
Пример: Если один человек отправляет и утверждает платежи, это нарушение данного принципа.
2️⃣ Sequence Diagram, Activity diagram или BPMN
- Проверьте последовательность шагов выполнения процесса.
- Убедитесь, что критически важные операции (например, подтверждение финансовой транзакции) требуют участия разных ролей.
Пример: На диаграмме должна быть отдельная роль для инициатора платежа и для его утверждения.
3️⃣ State Machine Diagram
- Определите возможные состояния сущности и переходы между ними.
- Проверьте, нет ли состояния, в котором одна роль может завершить критически важную операцию без проверки.
Пример: Переход "Запрос на изменение -> Применено" не должен происходить без состояния "Рецензия".

📌 Чек-лист вопросов для проверки:
✅ Кто выполняет критически важные операции? Не делает ли один человек всё сам?
✅ Есть ли независимые проверки и утверждения?
✅ Можно ли разделить процесс между несколькими ролями?
✅ Возможно ли обойти разделение обязанностей?

#принципы_ИБ