Для проверки соблюдения принципа Fail Secure можно использовать следующие техники при анализе требований к ПО:
1️⃣ Анализ вариантов использования
Как применять:
1) Проверьте, какие могут быть исключительные ситуации на каждом шаге основного сценария и расширений.
2) Возможные причины исключений:
- Некорректное действие пользователя.
- Некорректный ответ сторонней системы.
- Бездействие пользователя или сторонней системы.
- Появление условий ("если...") в шагах сценария.
- Внутренние ошибки в разрабатываемой системе.
- Неожиданные ошибки, вызванные внешними факторами.
- Недостатки в производительности системы.
3) Убедитесь, что для каждой исключительной ситуации определены механизмы обработки, которые обеспечивают безопасное поведение системы.
4) Определите, как пользователю будет предоставляться информация об ошибке, чтобы избежать утечек (например, отправка обобщенного сообщения вместо технических деталей).
5) Исключите пересылку сообщений об ошибках сторонних систем в сыром виде, чтобы не передавать конфиденциальную информацию. Обрабатывайте ошибки локально и предоставляйте пользователю безопасные уведомления.
2️⃣ Диаграммы последовательностей UML
Как применять:
1) Используйте диаграммы последовательностей для визуализации взаимодействия между компонентами системы в случае исключений.
2) Убедитесь, что предусмотрено безопасное завершение операций или восстановление системы в каждом сценарии (особенно в блоках alt, opt, loop, break и других).
3) Задавайте вопросы “А что, если …?”
3️⃣ Сценарии BDD (Behavior-Driven Development)
Для каждой строки после ключевого слова Given в BDD-сценариях подставьте обратное значение условия.
Например, если сценарий выглядит так (условие: токен валидный):
добавьте обратное условие (токен невалидный) и опишите результат сценария (после ключевого слова Then), соответствующий такому условию
И аналогично выполнить для остальных строк с условиями и проверить для комбинаций таких условий.
4️⃣ Анализ корневых причин (Root Cause Analysis)
Анализируйте прошлые инциденты информационной безопасности, вызванные неэффективной обработкой исключений, и внедряйте меры для их предотвращения.
Пишите в комментариях, какие техники бизнес-анализа вы рекомендовали бы применять для проверки соблюдения описанного принципа!
#принципы_ИБ
1️⃣ Анализ вариантов использования
Как применять:
1) Проверьте, какие могут быть исключительные ситуации на каждом шаге основного сценария и расширений.
2) Возможные причины исключений:
- Некорректное действие пользователя.
- Некорректный ответ сторонней системы.
- Бездействие пользователя или сторонней системы.
- Появление условий ("если...") в шагах сценария.
- Внутренние ошибки в разрабатываемой системе.
- Неожиданные ошибки, вызванные внешними факторами.
- Недостатки в производительности системы.
3) Убедитесь, что для каждой исключительной ситуации определены механизмы обработки, которые обеспечивают безопасное поведение системы.
4) Определите, как пользователю будет предоставляться информация об ошибке, чтобы избежать утечек (например, отправка обобщенного сообщения вместо технических деталей).
5) Исключите пересылку сообщений об ошибках сторонних систем в сыром виде, чтобы не передавать конфиденциальную информацию. Обрабатывайте ошибки локально и предоставляйте пользователю безопасные уведомления.
2️⃣ Диаграммы последовательностей UML
Как применять:
1) Используйте диаграммы последовательностей для визуализации взаимодействия между компонентами системы в случае исключений.
2) Убедитесь, что предусмотрено безопасное завершение операций или восстановление системы в каждом сценарии (особенно в блоках alt, opt, loop, break и других).
3) Задавайте вопросы “А что, если …?”
3️⃣ Сценарии BDD (Behavior-Driven Development)
Для каждой строки после ключевого слова Given в BDD-сценариях подставьте обратное значение условия.
Например, если сценарий выглядит так (условие: токен валидный):
Feature: Retrieve client IDs based on phone numbers
Scenario: Successful request
Given the user sends a request with a list of valid phone numbers
And the authentication token is valid
And the token contains the required scope
And the request format is valid
When the system receives the request
Then the system verifies the authentication token
And checks required scope
And verifies the request format
And searches for client IDs matching the phone numbers
And responds with the phone numbers and their matching IDs with a 200 OK status
And logs the operation
добавьте обратное условие (токен невалидный) и опишите результат сценария (после ключевого слова Then), соответствующий такому условию
Feature: Retrieve client IDs based on phone numbers
Scenario: Authentication failed
Given the user sends a request with a list of valid phone numbers
And the authentication token is invalid
And the token contains the required scope
And the request format is valid
When the system receives the request
Then the system verifies the authentication token
And responds with a 401 Unauthorized status
And logs the operation
И аналогично выполнить для остальных строк с условиями и проверить для комбинаций таких условий.
4️⃣ Анализ корневых причин (Root Cause Analysis)
Анализируйте прошлые инциденты информационной безопасности, вызванные неэффективной обработкой исключений, и внедряйте меры для их предотвращения.
Пишите в комментариях, какие техники бизнес-анализа вы рекомендовали бы применять для проверки соблюдения описанного принципа!
#принципы_ИБ
❤2👍2
Создание C4-диаграмм и моделирование угроз с использованием PlantUML
Сегодня сделаю небольшую паузу в цикле постов о принципах информационной безопасности и поделюсь полезными инструментами для системных аналитиков.
📌 C4 + PlantUML
Если в своей работе вы используете C4-модели для визуализации архитектуры систем и вам нравится работать с PlantUML для создания UML-диаграмм, обратите внимание на C4-PlantUML. Вы сможете создавать C4-модели, используя синтаксис PlantUML. Одним из преимуществ такого подхода является возможность представления C4-моделей в виде кода (текста), что удобно для версионирования и командной работы.
📌 C4 + PlantUML + STRIDE
Аналогичный подход можно применить для моделирования угроз с использованием метода STRIDE на основе C4-модели. С помощью STRIDE-PlantUML вы можете аннотировать STRIDE-маркерами диаграмму C4-модели, используя синтаксис PlantUML. Такой подход позволяет создавать модель угроз в виде кода, а также использовать диаграммы в ChatGPT: например, предоставить анонимизированную архитектуру вашей системы и попросить сгенерировать модель угроз. Однако стоит учитывать, что результат может быть ограничен по детализации.
📚 Если вы ещё не умеете проводить моделирование угроз при выявлении требований по безопасности, приглашаю вас на мой воркшоп для системных аналитиков Основы разработки требований к информационной безопасности ИТ-систем, который стартует 14 января.
#C4 #PlantUML #ThreatModeling #STRIDE
Сегодня сделаю небольшую паузу в цикле постов о принципах информационной безопасности и поделюсь полезными инструментами для системных аналитиков.
📌 C4 + PlantUML
Если в своей работе вы используете C4-модели для визуализации архитектуры систем и вам нравится работать с PlantUML для создания UML-диаграмм, обратите внимание на C4-PlantUML. Вы сможете создавать C4-модели, используя синтаксис PlantUML. Одним из преимуществ такого подхода является возможность представления C4-моделей в виде кода (текста), что удобно для версионирования и командной работы.
📌 C4 + PlantUML + STRIDE
Аналогичный подход можно применить для моделирования угроз с использованием метода STRIDE на основе C4-модели. С помощью STRIDE-PlantUML вы можете аннотировать STRIDE-маркерами диаграмму C4-модели, используя синтаксис PlantUML. Такой подход позволяет создавать модель угроз в виде кода, а также использовать диаграммы в ChatGPT: например, предоставить анонимизированную архитектуру вашей системы и попросить сгенерировать модель угроз. Однако стоит учитывать, что результат может быть ограничен по детализации.
📚 Если вы ещё не умеете проводить моделирование угроз при выявлении требований по безопасности, приглашаю вас на мой воркшоп для системных аналитиков Основы разработки требований к информационной безопасности ИТ-систем, который стартует 14 января.
#C4 #PlantUML #ThreatModeling #STRIDE
👍4
📌 Сегодня поговорим о принципе информационной безопасности полного посредничества (Complete mediation). Этот принцип требует, чтобы доступ ко всем ресурсам системы проверялся на соответствие установленным правилам безопасности каждый раз, когда к ним обращаются. (CWE-638: Not Using Complete Mediation)
✏️ Основные аспекты принципа:
1. Проверка доступа при каждом запросе
Даже если доступ к ресурсу уже был разрешён, повторный запрос обязательно должен проходить проверку. Это предотвращает неавторизованный доступ, если права пользователя были изменены или отозваны.
2. Защита от кеширования
Система не должна полагаться на кеширование результатов проверок.
3. Применимость ко всем ресурсам
Принцип распространяется на все данные, сервисы, процессы и компоненты системы.
🛠 Техники системного анализа для проверки соблюдения данного принципа
1️⃣ Sequence Diagrams и BDD
Убедитесь, что на диаграммах и в BDD-сценариях:
- Проверка авторизации выполняется до бизнес-логики.
- Обработаны случаи неуспешной авторизации.
2️⃣ Описание вариантов использования
- Включите в предусловия сценария успешную аутентификацию и авторизацию пользователя или сервиса.
- Добавьте ссылки на сценарии аутентификации и авторизации (или укажите их шаги прямо в сценарии).
3️⃣ При проектировании API проверьте, что:
- Каждый запрос к API требует аутентификации.
- Авторизация проверяется на уровне каждого ресурса и операции (HTTP-методы).
- Права доступа проверяются при каждом запросе, даже если ранее тот же пользователь или сервис уже обращался к этому ресурсу.
4️⃣ Используйте контрольные списки, проверяющие:
- Учитываются ли проверки доступа при каждом запросе?
- Предусмотрены ли требования по обработке сессий и отзыву прав доступа?
- Указано ли, что результаты проверок не должны кешироваться?
#принципы_ИБ
✏️ Основные аспекты принципа:
1. Проверка доступа при каждом запросе
Даже если доступ к ресурсу уже был разрешён, повторный запрос обязательно должен проходить проверку. Это предотвращает неавторизованный доступ, если права пользователя были изменены или отозваны.
2. Защита от кеширования
Система не должна полагаться на кеширование результатов проверок.
3. Применимость ко всем ресурсам
Принцип распространяется на все данные, сервисы, процессы и компоненты системы.
🛠 Техники системного анализа для проверки соблюдения данного принципа
1️⃣ Sequence Diagrams и BDD
Убедитесь, что на диаграммах и в BDD-сценариях:
- Проверка авторизации выполняется до бизнес-логики.
- Обработаны случаи неуспешной авторизации.
2️⃣ Описание вариантов использования
- Включите в предусловия сценария успешную аутентификацию и авторизацию пользователя или сервиса.
- Добавьте ссылки на сценарии аутентификации и авторизации (или укажите их шаги прямо в сценарии).
3️⃣ При проектировании API проверьте, что:
- Каждый запрос к API требует аутентификации.
- Авторизация проверяется на уровне каждого ресурса и операции (HTTP-методы).
- Права доступа проверяются при каждом запросе, даже если ранее тот же пользователь или сервис уже обращался к этому ресурсу.
4️⃣ Используйте контрольные списки, проверяющие:
- Учитываются ли проверки доступа при каждом запросе?
- Предусмотрены ли требования по обработке сессий и отзыву прав доступа?
- Указано ли, что результаты проверок не должны кешироваться?
#принципы_ИБ
👍3
📢 Приглашаю на февральскую конференцию для SA/BA Analyst Marathon #12, где я расскажу о техниках Abuse cases и Attacker stories для выявления требований к информационной безопасности.
🗓 Когда: 15 февраля, с 10 до 17 ч. (мск)
🌐 Где: Онлайн
💰 Сколько стоит: от 2900 руб. (до 24 января)
Присоединяйтесь! 👉 analyst-marathon.timepad.ru
🗓 Когда: 15 февраля, с 10 до 17 ч. (мск)
🌐 Где: Онлайн
💰 Сколько стоит: от 2900 руб. (до 24 января)
Присоединяйтесь! 👉 analyst-marathon.timepad.ru
🔥4👍2
Сегодня рассмотрим важный принцип информационной безопасности - открытый дизайн (Open Design).
💡 Что это значит?
Принцип открытого дизайна диаметрально противоположен подходу «безопасность через сокрытие» (security through obscurity). Он утверждает, что безопасность системы должна зависеть не от сокрытия деталей реализации, а от надежности алгоритмов и методов защиты.
🔍 Исторический контекст:
В 1800-х годах Огюст Керкгоффс сформулировал принцип, применимый к криптографии: алгоритм шифрования должен быть полностью известен, а единственным секретом должен оставаться ключ. Этот подход известен как принцип Керкгоффса и лег в основу современных криптографических стандартов.
🚫 Уязвимость CWE-656: Reliance on Security Through Obscurity
Эта уязвимость описывает риски, возникающие при использовании сокрытия как основного метода защиты. Например, сокрытие критических данных в коде (CWE-259), вместо их надёжной защиты, обходится с помощью реверс-инжиниринга.
✅ Как надо делать:
1️⃣ Использовать открытые криптографические алгоритмы (AES, RSA ГОСТ), которые проверены экспертами.
2️⃣ Хранить конфиденциальные данные (ключи, пароли, токены) в защищенных хранилищах (например, HashiCorp Vault, AWS Secrets Manager).
3️⃣ Обеспечивать независимость безопасности системы от сокрытия её архитектуры.
⚙️ Какие техники помогут проверить соблюдение принципа:
1️⃣ Data Flow Diagram (DFD) или C4:
Проверьте, чтобы данные, передаваемые между системами, были защищены (например, шифрованием) и не зависели от скрытых механизмов.
2️⃣ Анализ решения (Decision Analysis)
Проведите анализ выбранного решения для защиты информации на предмет того, может ли злоумышленник получить чувствительную информацию с помощью реверс-инжиниринга.
3️⃣ Анализ вариантов использования (Use Case Analysis)
- Проверьте, что у вас имеются требования к ротации ключей. Система должна выполнять замену ключей через заданные интервалы времени без нарушения доступности данных и удалять устаревшие ключи.
- При необходимости подумайте о депонировании ключей. Это особенно актуально для приложений, которые поддерживают шифрование долгосрочных хранилищ данных. Данные, зашифрованные с утерянными криптографическими ключами, никогда не будут восстановлены.
❓Вопросы или хотите больше примеров?
❓Как бы вы проверили соблюдение этого принципа на этапе разработки требований и архитектуры?
#принципы_ИБ
💡 Что это значит?
Принцип открытого дизайна диаметрально противоположен подходу «безопасность через сокрытие» (security through obscurity). Он утверждает, что безопасность системы должна зависеть не от сокрытия деталей реализации, а от надежности алгоритмов и методов защиты.
🔍 Исторический контекст:
В 1800-х годах Огюст Керкгоффс сформулировал принцип, применимый к криптографии: алгоритм шифрования должен быть полностью известен, а единственным секретом должен оставаться ключ. Этот подход известен как принцип Керкгоффса и лег в основу современных криптографических стандартов.
🚫 Уязвимость CWE-656: Reliance on Security Through Obscurity
Эта уязвимость описывает риски, возникающие при использовании сокрытия как основного метода защиты. Например, сокрытие критических данных в коде (CWE-259), вместо их надёжной защиты, обходится с помощью реверс-инжиниринга.
✅ Как надо делать:
1️⃣ Использовать открытые криптографические алгоритмы (AES, RSA ГОСТ), которые проверены экспертами.
2️⃣ Хранить конфиденциальные данные (ключи, пароли, токены) в защищенных хранилищах (например, HashiCorp Vault, AWS Secrets Manager).
3️⃣ Обеспечивать независимость безопасности системы от сокрытия её архитектуры.
⚙️ Какие техники помогут проверить соблюдение принципа:
1️⃣ Data Flow Diagram (DFD) или C4:
Проверьте, чтобы данные, передаваемые между системами, были защищены (например, шифрованием) и не зависели от скрытых механизмов.
2️⃣ Анализ решения (Decision Analysis)
Проведите анализ выбранного решения для защиты информации на предмет того, может ли злоумышленник получить чувствительную информацию с помощью реверс-инжиниринга.
3️⃣ Анализ вариантов использования (Use Case Analysis)
- Проверьте, что у вас имеются требования к ротации ключей. Система должна выполнять замену ключей через заданные интервалы времени без нарушения доступности данных и удалять устаревшие ключи.
- При необходимости подумайте о депонировании ключей. Это особенно актуально для приложений, которые поддерживают шифрование долгосрочных хранилищ данных. Данные, зашифрованные с утерянными криптографическими ключами, никогда не будут восстановлены.
❓Вопросы или хотите больше примеров?
❓Как бы вы проверили соблюдение этого принципа на этапе разработки требований и архитектуры?
#принципы_ИБ
🔥1
🎉 У меня имеется 2 промокода на бесплатное участие в онлайн-конференции Analyst Marathon, которая пройдет 15 февраля с 10:00 до 17:00 (МСК).
Хочу их разыграть среди подписчиков канала 🚀
💡 Что нужно сделать?
Напишите в комментариях под этим постом тему для поста по информационной безопасности, которая будет интересна многим аналитикам. Это может быть вопрос, проблема или идея, связанная с ИБ, о которой вы давно хотели больше узнать.
🏆 Как победить?
Два автора комментариев, которые соберут больше всего реакций (👍, 🔥 и любых других), станут победителями и получат по промокоду.
⏳ Дедлайн:
Конкурс заканчивается 3 февраля в 10:00 (МСК). После этого я подведу итоги и объявлю победителей!
Пишите свои идеи, ставьте реакции на интересные комментарии и выигрывайте! 🚀
Хочу их разыграть среди подписчиков канала 🚀
💡 Что нужно сделать?
Напишите в комментариях под этим постом тему для поста по информационной безопасности, которая будет интересна многим аналитикам. Это может быть вопрос, проблема или идея, связанная с ИБ, о которой вы давно хотели больше узнать.
🏆 Как победить?
Два автора комментариев, которые соберут больше всего реакций (👍, 🔥 и любых других), станут победителями и получат по промокоду.
⏳ Дедлайн:
Конкурс заканчивается 3 февраля в 10:00 (МСК). После этого я подведу итоги и объявлю победителей!
Пишите свои идеи, ставьте реакции на интересные комментарии и выигрывайте! 🚀
Сегодня говорим о принципе 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
- Определите возможные состояния сущности и переходы между ними.
- Проверьте, нет ли состояния, в котором одна роль может завершить критически важную операцию без проверки.
Пример: Переход "Запрос на изменение -> Применено" не должен происходить без состояния "Рецензия".
📌 Чек-лист вопросов для проверки:
✅ Кто выполняет критически важные операции? Не делает ли один человек всё сам?
✅ Есть ли независимые проверки и утверждения?
✅ Можно ли разделить процесс между несколькими ролями?
✅ Возможно ли обойти разделение обязанностей?
#принципы_ИБ
💡 Что значит этот принцип?
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
- Определите возможные состояния сущности и переходы между ними.
- Проверьте, нет ли состояния, в котором одна роль может завершить критически важную операцию без проверки.
Пример: Переход "Запрос на изменение -> Применено" не должен происходить без состояния "Рецензия".
📌 Чек-лист вопросов для проверки:
✅ Кто выполняет критически важные операции? Не делает ли один человек всё сам?
✅ Есть ли независимые проверки и утверждения?
✅ Можно ли разделить процесс между несколькими ролями?
✅ Возможно ли обойти разделение обязанностей?
#принципы_ИБ
👍3❤1
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
Связанная уязвимость: В требовании 13.1.3 есть прямая ссылка на уязвимость CWE-598, которую закрывает данное требование. Рекомендую ознакамливаться, чтобы понимать, зачем необходимо это требование.
В описании уязвимости CWE-598 сказано, что если веб-приложение использует метод GET для обработки запроса и передает конфиденциальные данные в query string, то это может привести к их утечке, так как:
- URL с конфиденциальными данными может сохраняться в истории браузера.
- Данные передаются в HTTP Referer при переходе на другой сайт.
- Запросы с query string могут сохраняться в логах веб-сервера.
- Конфиденциальная информация может быть записана в кеш браузера или proxy-серверов.
📌 User Story из ASVS Agile Delivery Guide:
📌BDD cценарий из ASVS Agile Delivery Guide:
#ASVS #OWASP
Когда речь заходит о требованиях к безопасности, системные аналитики часто сталкиваются с вопросом: на что опираться? Один из самых полезных, на мой взгляд, документов — 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
👍4❤2
🚀 Приглашаю на Systems Design Online с докладом на тему по информационной безопасности!
Меня пригласили куратором секции по информационной безопасности на конференции Systems Design Online, и теперь моя задача — выбрать интересные доклады.
Тема этого года на конференции:
Компромиссы проектирования — баланс между атрибутами качества (включая безопасность), финансированием и сроками.
📌 Если у вас есть опыт, мысли или кейсы про:
🔹 Компромиссы между безопасностью, бюджетом и сроками
🔹 Встраивание безопасности в SDLC
🔹 Реальные истории про security-фейлы и как их избегать на этапе проектирования
🔹 Что угодно ещё на стыке security и системного проектирования,
…то давайте делать доклад!
🗓 Когда?
12 апреля (суббота) - день докладов
13 апреля (воскресенье) - воркшопы
🌏 Онлайн, так что можно участвовать из любой точки мира.
Пишите в личку или в комментариях, если хотите участвовать, обсудить тему или уточнить детали участия!
Меня пригласили куратором секции по информационной безопасности на конференции Systems Design Online, и теперь моя задача — выбрать интересные доклады.
Тема этого года на конференции:
Компромиссы проектирования — баланс между атрибутами качества (включая безопасность), финансированием и сроками.
📌 Если у вас есть опыт, мысли или кейсы про:
🔹 Компромиссы между безопасностью, бюджетом и сроками
🔹 Встраивание безопасности в SDLC
🔹 Реальные истории про security-фейлы и как их избегать на этапе проектирования
🔹 Что угодно ещё на стыке security и системного проектирования,
…то давайте делать доклад!
🗓 Когда?
12 апреля (суббота) - день докладов
13 апреля (воскресенье) - воркшопы
🌏 Онлайн, так что можно участвовать из любой точки мира.
Пишите в личку или в комментариях, если хотите участвовать, обсудить тему или уточнить детали участия!
systemsdesign.online
Systems Design Online — Регулярные онлайн-конференции, посвящённые проектированию современных информационных систем
Доклады, воркшопы от практиков для архитекторов, разработчиков, системных аналитиков, руководителей ИТ-проектов.
🔥1
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 <threat agent>, I want <threat> using <vulnerability> in order to <motive>.
Пример User Story и Attacker Stories
User Story:
👉 Как клиент, я хочу перевести деньги между своими счетами, чтобы управлять своими финансами.
Attacker Stories:
🔴 Как мошенник, я хочу подменить реквизиты перевода, используя возможность перехвата данных в незашифрованном канале, чтобы получить деньги на свой счёт вместо счёта жертвы.
🔴 Как мошенник, я хочу совершать переводы от имени клиента банка, используя украденный идентификатор сессии, чтобы перевести деньги клиента банка на свой счёт.
Что делать после выявления Attacker Stories?
После моделирования угроз с использованием Attacker Stories мы разрабатываем контрмеры (требования к ИБ), чтобы минимизировать риски от выявленных угроз. Эти контрмеры:
✅ Добавляются в Acceptance criteria для исходной User Story.
✅ Или оформляются как отдельные User Stories.
Использование Attacker Story помогает приоритизировать требования к ИБ, так как становится очевидно, какие угрозы они нейтрализуют (или снижают вероятность их реализации) и какие последствия могут наступить для бизнеса в случае игнорирования этих угроз.
#ThreatModeling #OWASP #AttackerStory
В субботу я выступал на конференции 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 <threat agent>, I want <threat> using <vulnerability> in order to <motive>.
Пример User Story и Attacker Stories
User Story:
👉 Как клиент, я хочу перевести деньги между своими счетами, чтобы управлять своими финансами.
Attacker Stories:
🔴 Как мошенник, я хочу подменить реквизиты перевода, используя возможность перехвата данных в незашифрованном канале, чтобы получить деньги на свой счёт вместо счёта жертвы.
🔴 Как мошенник, я хочу совершать переводы от имени клиента банка, используя украденный идентификатор сессии, чтобы перевести деньги клиента банка на свой счёт.
Что делать после выявления Attacker Stories?
После моделирования угроз с использованием Attacker Stories мы разрабатываем контрмеры (требования к ИБ), чтобы минимизировать риски от выявленных угроз. Эти контрмеры:
✅ Добавляются в Acceptance criteria для исходной User Story.
✅ Или оформляются как отдельные User Stories.
Использование Attacker Story помогает приоритизировать требования к ИБ, так как становится очевидно, какие угрозы они нейтрализуют (или снижают вероятность их реализации) и какие последствия могут наступить для бизнеса в случае игнорирования этих угроз.
#ThreatModeling #OWASP #AttackerStory
👍7🔥4
Сегодня продолжим рассмотрение принципов информационной безопасности и поговорим о принципе "Минимальные привилегии" (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 матрица: определите, кто отвечает за выполнение каждой задачи, и убедитесь, что роли не обладают избыточными полномочиями.
📰 Матрица доступа: составьте таблицу соответствия ролей и разрешений.
#принципы_ИБ
Принцип минимальных привилегий означает, что каждому пользователю, процессу или системе должны быть предоставлены только минимальные разрешения на минимальный период времени, необходимые для выполнения данной операции.
Как реализовать принцип минимальных привилегий?
🔹 Использовать правило "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 матрица: определите, кто отвечает за выполнение каждой задачи, и убедитесь, что роли не обладают избыточными полномочиями.
#принципы_ИБ
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4❤1
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 - практический инструмент для архитекторов, инженеров и аналитиков. Они не заменяют процессы безопасности, но делают их структурированными, воспроизводимыми и адаптивными.
Если вы работаете с безопасностью, то знаете: одни и те же проблемы встречаются снова и снова. Вместо того чтобы каждый раз придумывать решение с нуля, можно использовать 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 - практический инструмент для архитекторов, инженеров и аналитиков. Они не заменяют процессы безопасности, но делают их структурированными, воспроизводимыми и адаптивными.
👍4
🔐 Для обнаружения, предотвращения или смягчения рисков, связанных с угрозами информационной безопасности, принимаемые меры делятся на пять основных типов: превентивные, детективные, восстановительные, корректирующие и компенсирующие. В этом и следующем постах разберу зачем нужен каждый тип мер, приведу примеры таких мер и некоторые вопросы, которые помогут вам в выявлении требований к безопасности. ⬇️
1️⃣ Превентивные меры (Preventive)
📌 Цель: Предотвратить инцидент до его возникновения.
🔐 Примеры:
- Аутентификация и авторизация – ограничивает доступ к системе только для проверенных пользователей.
- Минимальные привилегии – пользователи и процессы получают только те права, которые им необходимы.
- Фильтрация входных данных – предотвращает SQL-инъекции и XSS-атаки.
- Юридические уведомления – предупреждение о правовых последствиях несанкционированного доступа.
❓ Вопросы для выявления требований:
- Какие потенциальные угрозы существуют для системы?
- Как можно минимизировать риски, связанные с каждой угрозой?
- Какие защитные меры должны быть внедрены для предотвращения инцидентов?
- Не создадут ли новых угроз безопасности внедрённые меры?
- Что нужно выполнить, чтобы предотвратить ошибки пользователей?
- Какие меры могут отпугнуть злоумышленников и снизить вероятность атаки?
- Какие процессы/инструкции должны быть разработаны для повышения осведомлённости сотрудников и пользователей о безопасности? Что для этого целесообразно реализовать на уровне ПО?
2️⃣ Детективные меры (Detective)
📌 Цель: Обнаружить инцидент и собрать данные для анализа.
🔐 Примеры:
- Логирование событий – запись действий пользователей и систем.
- Мониторинг аномалий – обнаружение подозрительной активности (например, SIEM-системы).
- Системы обнаружения вторжений (IDS) – выявляют несанкционированный доступ.
❓ Вопросы для выявления требований:
- Какие события в системе должны логироваться для выявления инцидентов?
- Какая информация о событиях потребуется при анализе инцидентов?
- Как интегрировать средства мониторинга с существующими системами безопасности?
- Какие методы защиты (маскирование, хеширование, анонимизация) должны быть применены для защиты конфиденциальной информации в логах, чтобы исключить её утечку в случае доступа к журналам?
- Какие механизмы отчётности и оповещений нужны для своевременного обнаружения угроз?
- Как обеспечить хранение и защиту данных для последующего анализа инцидентов?
- Как долго необходимо хранить информацию о событиях в системе?
3️⃣ Восстановительные меры (Recovery)
📌 Цель: Вернуть систему в нормальное состояние после инцидента и минимизировать последствия.
🔐 Примеры:
- Восстановление данных из резервных копий.
- Переключение на резервный сервер (failover).
- Выполнение Disaster Recovery Plan (DRP).
❓ Вопросы для выявления требований:
- Какие компоненты системы должны быть восстановлены в первую очередь после инцидента?
- Какие данные должны быть защищены и восстановлены, чтобы минимизировать последствия инцидента?
- Какую информацию нужно предоставить пользователям о восстановлении системы?
- Какие процедуры тестирования должны быть внедрены для проверки восстановления?
- Какое максимальное время простоя системы или её компонентов является приемлемым для бизнеса, чтобы минимизировать убытки?
- Какие процессы восстановления необходимо автоматизировать, чтобы ускорить время восстановления?
- Какое количество данных может быть потеряно без значительного ущерба для бизнеса?
продолжение в следующем посте
1️⃣ Превентивные меры (Preventive)
📌 Цель: Предотвратить инцидент до его возникновения.
🔐 Примеры:
- Аутентификация и авторизация – ограничивает доступ к системе только для проверенных пользователей.
- Минимальные привилегии – пользователи и процессы получают только те права, которые им необходимы.
- Фильтрация входных данных – предотвращает SQL-инъекции и XSS-атаки.
- Юридические уведомления – предупреждение о правовых последствиях несанкционированного доступа.
- Какие потенциальные угрозы существуют для системы?
- Как можно минимизировать риски, связанные с каждой угрозой?
- Какие защитные меры должны быть внедрены для предотвращения инцидентов?
- Не создадут ли новых угроз безопасности внедрённые меры?
- Что нужно выполнить, чтобы предотвратить ошибки пользователей?
- Какие меры могут отпугнуть злоумышленников и снизить вероятность атаки?
- Какие процессы/инструкции должны быть разработаны для повышения осведомлённости сотрудников и пользователей о безопасности? Что для этого целесообразно реализовать на уровне ПО?
2️⃣ Детективные меры (Detective)
📌 Цель: Обнаружить инцидент и собрать данные для анализа.
🔐 Примеры:
- Логирование событий – запись действий пользователей и систем.
- Мониторинг аномалий – обнаружение подозрительной активности (например, SIEM-системы).
- Системы обнаружения вторжений (IDS) – выявляют несанкционированный доступ.
- Какие события в системе должны логироваться для выявления инцидентов?
- Какая информация о событиях потребуется при анализе инцидентов?
- Как интегрировать средства мониторинга с существующими системами безопасности?
- Какие методы защиты (маскирование, хеширование, анонимизация) должны быть применены для защиты конфиденциальной информации в логах, чтобы исключить её утечку в случае доступа к журналам?
- Какие механизмы отчётности и оповещений нужны для своевременного обнаружения угроз?
- Как обеспечить хранение и защиту данных для последующего анализа инцидентов?
- Как долго необходимо хранить информацию о событиях в системе?
3️⃣ Восстановительные меры (Recovery)
📌 Цель: Вернуть систему в нормальное состояние после инцидента и минимизировать последствия.
🔐 Примеры:
- Восстановление данных из резервных копий.
- Переключение на резервный сервер (failover).
- Выполнение Disaster Recovery Plan (DRP).
- Какие компоненты системы должны быть восстановлены в первую очередь после инцидента?
- Какие данные должны быть защищены и восстановлены, чтобы минимизировать последствия инцидента?
- Какую информацию нужно предоставить пользователям о восстановлении системы?
- Какие процедуры тестирования должны быть внедрены для проверки восстановления?
- Какое максимальное время простоя системы или её компонентов является приемлемым для бизнеса, чтобы минимизировать убытки?
- Какие процессы восстановления необходимо автоматизировать, чтобы ускорить время восстановления?
- Какое количество данных может быть потеряно без значительного ущерба для бизнеса?
продолжение в следующем посте
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4
4️⃣ Корректирующие меры (Corrective)
📌 Цель: Устранить причину инцидента и предотвратить его повторение.
🔐 Примеры:
- Исправление уязвимостей – изменение кода, обновление конфигурации.
- Блокировка скомпрометированных учетных записей.
- Обновление политики безопасности – например, усиление паролей или переход на MFA.
❓ Вопросы для выявления требований:
- Какие шаги необходимо предпринять для устранения последствий инцидента? Кто и как будет это делать?
- Как гарантировать, что корректирующие меры не повлияют на функционирование системы в целом?
- Как можно улучшить процессы, чтобы предотвратить повторение инцидентов?
- Каковы процедуры восстановления после инцидента, включая управление изменениями?
5️⃣ Компенсирующие меры (Compensating)
📌 Цель: Предоставить альтернативный способ защиты, если основная мера недоступна.
🔐 Примеры:
- Физический доступ вместо цифрового – вход в помещение по смарт-карте вместо системной аутентификации.
- Ограничения на сетевом уровне вместо защиты на уровне приложения – если приложение не поддерживает двухфакторную аутентификацию, можно ограничить доступ к нему только из корпоративной сети.
❓ Вопросы для выявления требований:
- Какие меры защиты можно применить, если основные средства безопасности недоступны?
- Каковы альтернативы для обеспечения защиты в случае отказа основной меры?
- Не создадут ли новых угроз безопасности компенсирующие меры?
- Какие требования должны быть выполнены для того, чтобы компенсирующие меры были эффективными?
🎯 Вывод
✅ Разные меры информационной безопасности работают в комплексе – от предотвращения атак до восстановления после инцидента.
✅ Использование разных типов мер повышает защиту и снижает риск реализации угроз.
📌 Цель: Устранить причину инцидента и предотвратить его повторение.
🔐 Примеры:
- Исправление уязвимостей – изменение кода, обновление конфигурации.
- Блокировка скомпрометированных учетных записей.
- Обновление политики безопасности – например, усиление паролей или переход на MFA.
- Какие шаги необходимо предпринять для устранения последствий инцидента? Кто и как будет это делать?
- Как гарантировать, что корректирующие меры не повлияют на функционирование системы в целом?
- Как можно улучшить процессы, чтобы предотвратить повторение инцидентов?
- Каковы процедуры восстановления после инцидента, включая управление изменениями?
5️⃣ Компенсирующие меры (Compensating)
📌 Цель: Предоставить альтернативный способ защиты, если основная мера недоступна.
🔐 Примеры:
- Физический доступ вместо цифрового – вход в помещение по смарт-карте вместо системной аутентификации.
- Ограничения на сетевом уровне вместо защиты на уровне приложения – если приложение не поддерживает двухфакторную аутентификацию, можно ограничить доступ к нему только из корпоративной сети.
- Какие меры защиты можно применить, если основные средства безопасности недоступны?
- Каковы альтернативы для обеспечения защиты в случае отказа основной меры?
- Не создадут ли новых угроз безопасности компенсирующие меры?
- Какие требования должны быть выполнены для того, чтобы компенсирующие меры были эффективными?
🎯 Вывод
✅ Разные меры информационной безопасности работают в комплексе – от предотвращения атак до восстановления после инцидента.
✅ Использование разных типов мер повышает защиту и снижает риск реализации угроз.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4
🔐 Многим, кто погружается в тему ИБ, хорошо известен проект OWASP Top Ten - список наиболее распространённых уязвимостей. Есть также отдельные списки для разных типов приложений:
- OWASP API Security Top 10
- OWASP Mobile Top 10
Однако для системных аналитиков, на мой взгляд, гораздо полезнее (после OWASP ASVS) может оказаться другой проект OWASP — Top 10 Proactive Controls.
🛠 Proactive Controls предлагает список из 10 практик по обеспечению безопасности, которые стоит использовать на этапе проектирования. Предыдущая версия 2018 года содержала немного другой набор практик, их периодически актуализируют.
Каждая из практик описана структурированно:
- Описание практики
- Угрозы, которым противодействует
- Способы реализации практики
- Уязвимости, которых позволяет избежать данная практика
- Ссылки на инструменты и дополнительные материалы.
📚 Актуальный список 2024 года включает такие практики, как:
C1: Implement Access Control (Реализуйте управление доступом)
C2: Use Cryptography to Protect Data (Используйте криптографию для защиты данных)
C3: Validate all Input & Handle Exceptions (Проверяйте весь ввод и обрабатывайте исключения)
C4: Address Security from the Start (Учитывайте безопасность с самого начала)
C5: Secure By Default Configurations (Используйте безопасные настройки по умолчанию)
C6: Keep your Components Secure (Обеспечьте безопасность компонентов)
C7: Secure Digital Identities (Защищайте цифровые идентификаторы)
C8: Leverage Browser Security Features (Используйте функции безопасности браузера)
C9: Implement Security Logging and Monitoring (Реализуйте журналирование и мониторинг безопасности)
C10: Stop Server Side Request Forgery (Предотвращайте SSRF)
#OWASP #ProactiveControls
- OWASP API Security Top 10
- OWASP Mobile Top 10
Однако для системных аналитиков, на мой взгляд, гораздо полезнее (после OWASP ASVS) может оказаться другой проект OWASP — Top 10 Proactive Controls.
🛠 Proactive Controls предлагает список из 10 практик по обеспечению безопасности, которые стоит использовать на этапе проектирования. Предыдущая версия 2018 года содержала немного другой набор практик, их периодически актуализируют.
Каждая из практик описана структурированно:
- Описание практики
- Угрозы, которым противодействует
- Способы реализации практики
- Уязвимости, которых позволяет избежать данная практика
- Ссылки на инструменты и дополнительные материалы.
📚 Актуальный список 2024 года включает такие практики, как:
C1: Implement Access Control (Реализуйте управление доступом)
C2: Use Cryptography to Protect Data (Используйте криптографию для защиты данных)
C3: Validate all Input & Handle Exceptions (Проверяйте весь ввод и обрабатывайте исключения)
C4: Address Security from the Start (Учитывайте безопасность с самого начала)
C5: Secure By Default Configurations (Используйте безопасные настройки по умолчанию)
C6: Keep your Components Secure (Обеспечьте безопасность компонентов)
C7: Secure Digital Identities (Защищайте цифровые идентификаторы)
C8: Leverage Browser Security Features (Используйте функции безопасности браузера)
C9: Implement Security Logging and Monitoring (Реализуйте журналирование и мониторинг безопасности)
C10: Stop Server Side Request Forgery (Предотвращайте SSRF)
#OWASP #ProactiveControls
👍9
Прежде чем формулировать требования по информационной безопасности, важно понять, зачем они вообще нужны.
Цели могут быть разными:
- соблюдение регуляторных требований, чтобы минимизировать штрафы;
- снижение риска утечек данных;
- поддержание доверия клиентов и партнёров;
- защита репутации и активов.
Чтобы не скатиться в формальность, аналитик может уточнить: что именно мы защищаем, от кого и зачем. Иногда помогает техника 5 Why - она позволяет дойти до истинных мотивов.
Следующий шаг - определить угрозы, которые могут помешать достижению этих целей.
Упрощённый пример: партнёрская система передаёт нам персональные данные через API. В запросе - имя, телефон, паспорт. Аутентификация по API-ключу.
Для анализа возможных угроз можно использовать подход STRIDE:
🔤 – Spoofing (Подмена личности)
→ кто-то может выдать себя за партнёра
→ возможные решения: аутентификация с помощью X.509-сертификатов (mTLS), IP allow list
🔤 – Tampering (Подмена данных)
→ данные могут быть изменены в пути
→ возможные решения: HTTPS, использование JWS или HMAC-подписи для контроля целостности передаваемых данных
🔤 – Repudiation (Отказ от действий)
→ партнёр может отрицать факт передачи
→ возможные решения: использование JWS, логирование с защитой от модификации
🔤 – Information Disclosure (Утечка данных)
→ персональные данные нужно защитить
→ возможные решения: шифрование, ограничение доступа
🔤 – Denial of Service (Отказ в обслуживании)
→ злоумышленник может засыпать нас запросами
→ возможные решения: rate limiting, circuit breaker
🔤 – Elevation of Privilege (Повышение привилегий)
→ API-ключ может дать доступ к чужим данным
→ возможные решения: ограничение прав, принцип минимальных привилегий
Дополнительно аналитик может использовать:
- Abuse Cases (в этой книге целая глава по Misuse Cases) - негативные сценарии взаимодействия, описывающие, как может действовать злоумышленник
- Attacker Stories - формулировка целей и мотивации атакующего
#STRIDE #AttackerStory
Цели могут быть разными:
- соблюдение регуляторных требований, чтобы минимизировать штрафы;
- снижение риска утечек данных;
- поддержание доверия клиентов и партнёров;
- защита репутации и активов.
Чтобы не скатиться в формальность, аналитик может уточнить: что именно мы защищаем, от кого и зачем. Иногда помогает техника 5 Why - она позволяет дойти до истинных мотивов.
Следующий шаг - определить угрозы, которые могут помешать достижению этих целей.
Упрощённый пример: партнёрская система передаёт нам персональные данные через API. В запросе - имя, телефон, паспорт. Аутентификация по API-ключу.
Для анализа возможных угроз можно использовать подход STRIDE:
→ кто-то может выдать себя за партнёра
→ возможные решения: аутентификация с помощью X.509-сертификатов (mTLS), IP allow list
→ данные могут быть изменены в пути
→ возможные решения: HTTPS, использование JWS или HMAC-подписи для контроля целостности передаваемых данных
→ партнёр может отрицать факт передачи
→ возможные решения: использование JWS, логирование с защитой от модификации
→ персональные данные нужно защитить
→ возможные решения: шифрование, ограничение доступа
→ злоумышленник может засыпать нас запросами
→ возможные решения: rate limiting, circuit breaker
→ API-ключ может дать доступ к чужим данным
→ возможные решения: ограничение прав, принцип минимальных привилегий
Дополнительно аналитик может использовать:
- Abuse Cases (в этой книге целая глава по Misuse Cases) - негативные сценарии взаимодействия, описывающие, как может действовать злоумышленник
- Attacker Stories - формулировка целей и мотивации атакующего
#STRIDE #AttackerStory
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5
Сейчас читаю интересную книгу Adversarial AI Attacks, Mitigations, and Defense Strategies с большим количеством примеров кода на GitHub.
Одна из глав, на которой я сейчас остановился, про Privacy-Preserving AI.
Privacy-Preserving AI - это подходы к использованию AI и ML, которые позволяют работать с данными, не раскрывая их содержимого и защищая приватность (privacy) пользователей.
Цель: обеспечить полезность данных для задач AI, сохранив их конфиденциальность.
В книге подчёркивается, что нет единого решения для защиты данных и всё зависит от контекста и требует баланса между приватностью и полезностью данных, а также эшелонированной обороны (defense in depth). И прежде, чем выбирать техники и инструменты, они предлагаю выполнить стандартный набор действий:
1️⃣ Оценка рисков и сценариев использования. Понимание конкретных рисков и требований к данным помогает выбрать подходящие техники, например анонимизацию и способы её применения.
2️⃣ Моделирование угроз. Выявление потенциальных угроз, включая скрытые связи данных, помогает понять уязвимости.
3️⃣ Минимизация данных. Сокращение объёма чувствительных данных снижает поверхность атак.
4️⃣ Баланс между полезностью и безопасностью данных. Итерации оценки угроз и мер защиты помогают найти баланс между безопасностью и применимостью.
5️⃣ Эшелонированная оборона. Одна анонимизация не решает всех рисков, поэтому нужны дополнительные меры защиты: контроль доступа, защита данных и другие.
Далее я привожу краткое описание указанных в книге техник сохранения конфиденциальности данных в AI со ссылками на соответствующие инструменты.
Простое и продвинутое (K-анонимность) обезличивание данных
Простое обезличивание изменяет идентифицирующую информацию в наборах данных, чтобы предотвратить идентификацию личности при сохранении полезности данных. K-анонимность гарантирует, что каждая запись в наборе данных неразличима от k-1 других записей, что затрудняет связывание данных с отдельным лицом.
Примеры инструментов: SDK Presidio (Microsoft), который автоматически находит и обезличивает PII в тексте. Приложения ARX, Anonimatron и Amnesia (предлагает также REST API).
Обезличивание медиа (изображения, аудио, видео)
Используются методы обработки медиа: размытие, пикселизация, изменение голоса, синтез речи и др.
Примеры инструментов: OpenCV для размытия и маскирования изображений. BMW-Anonymization-API обнаруживает чувствительную информацию на изображениях и видео и скрывает с помощью размытия, пикселизации или маскирования
Differential privacy (DP)
DP обеспечивает математически строгую защиту, гарантируя, что результат вычислений не раскрывает данные об отдельных записях, обычно через добавление шума.
Примеры инструментов: TensorFlow Privacy (расширение TensorFlow для применения DP), IBM Differential Privacy Library, OpenDP.
Federated learning
Подход использует общую предварительно обученную модель. Сотрудничающие стороны загружают и обучают общую модель с использованием их собственных данных, а затем загружают модель (только обученную модель или весы) обратно на сервер.
Примеры инструментов: TensorFlow Federated (например Federated Learning для классификации изображений).
Split Learning
В отличие от federated learning, где обучение модели происходит локально на каждом устройстве и передаются только параметры модели, в split learning нейронная сеть разделяется между клиентом и сервером: клиент обрабатывает данные до определённого слоя и на сервер передаются только выходы этого слоя, который затем выполняет оставшиеся вычисления.
Имеется исследование, показывающее, что split learning не гарантирует конфиденциальность, поскольку «честный, но любопытный» сервер может восстанавливать входные данные или извлекать модель.
Homomorphic encryption (HE)
Позволяет выполнять вычисления непосредственно над зашифрованными данными, не расшифровывая их.
Примеры инструментов: Microsoft SEAL, TFEncrypted, OpenMined PySyft.
Одна из глав, на которой я сейчас остановился, про Privacy-Preserving AI.
Privacy-Preserving AI - это подходы к использованию AI и ML, которые позволяют работать с данными, не раскрывая их содержимого и защищая приватность (privacy) пользователей.
Цель: обеспечить полезность данных для задач AI, сохранив их конфиденциальность.
В книге подчёркивается, что нет единого решения для защиты данных и всё зависит от контекста и требует баланса между приватностью и полезностью данных, а также эшелонированной обороны (defense in depth). И прежде, чем выбирать техники и инструменты, они предлагаю выполнить стандартный набор действий:
1️⃣ Оценка рисков и сценариев использования. Понимание конкретных рисков и требований к данным помогает выбрать подходящие техники, например анонимизацию и способы её применения.
2️⃣ Моделирование угроз. Выявление потенциальных угроз, включая скрытые связи данных, помогает понять уязвимости.
3️⃣ Минимизация данных. Сокращение объёма чувствительных данных снижает поверхность атак.
4️⃣ Баланс между полезностью и безопасностью данных. Итерации оценки угроз и мер защиты помогают найти баланс между безопасностью и применимостью.
5️⃣ Эшелонированная оборона. Одна анонимизация не решает всех рисков, поэтому нужны дополнительные меры защиты: контроль доступа, защита данных и другие.
Далее я привожу краткое описание указанных в книге техник сохранения конфиденциальности данных в AI со ссылками на соответствующие инструменты.
Простое и продвинутое (K-анонимность) обезличивание данных
Простое обезличивание изменяет идентифицирующую информацию в наборах данных, чтобы предотвратить идентификацию личности при сохранении полезности данных. K-анонимность гарантирует, что каждая запись в наборе данных неразличима от k-1 других записей, что затрудняет связывание данных с отдельным лицом.
Примеры инструментов: SDK Presidio (Microsoft), который автоматически находит и обезличивает PII в тексте. Приложения ARX, Anonimatron и Amnesia (предлагает также REST API).
Обезличивание медиа (изображения, аудио, видео)
Используются методы обработки медиа: размытие, пикселизация, изменение голоса, синтез речи и др.
Примеры инструментов: OpenCV для размытия и маскирования изображений. BMW-Anonymization-API обнаруживает чувствительную информацию на изображениях и видео и скрывает с помощью размытия, пикселизации или маскирования
Differential privacy (DP)
DP обеспечивает математически строгую защиту, гарантируя, что результат вычислений не раскрывает данные об отдельных записях, обычно через добавление шума.
Примеры инструментов: TensorFlow Privacy (расширение TensorFlow для применения DP), IBM Differential Privacy Library, OpenDP.
Federated learning
Подход использует общую предварительно обученную модель. Сотрудничающие стороны загружают и обучают общую модель с использованием их собственных данных, а затем загружают модель (только обученную модель или весы) обратно на сервер.
Примеры инструментов: TensorFlow Federated (например Federated Learning для классификации изображений).
Split Learning
В отличие от federated learning, где обучение модели происходит локально на каждом устройстве и передаются только параметры модели, в split learning нейронная сеть разделяется между клиентом и сервером: клиент обрабатывает данные до определённого слоя и на сервер передаются только выходы этого слоя, который затем выполняет оставшиеся вычисления.
Имеется исследование, показывающее, что split learning не гарантирует конфиденциальность, поскольку «честный, но любопытный» сервер может восстанавливать входные данные или извлекать модель.
Homomorphic encryption (HE)
Позволяет выполнять вычисления непосредственно над зашифрованными данными, не расшифровывая их.
Примеры инструментов: Microsoft SEAL, TFEncrypted, OpenMined PySyft.
👍6❤1
RFC как первоисточники
В работе системного аналитика часто возникают вопросы о корректности интеграционных решений, выборе протоколов и форматов данных и связанных с ними нюансах. Можно гуглить статьи, искать на Stack Overflow или спрашивать у ChatGPT. Но есть риск наткнуться на чью-то интерпретацию.
Если вы хотите быть уверенными в своих требованиях, то я рекомендую использовать RFC (Request for Comments) как первоисточник и ссылаться на них.
Вот некоторые полезные RFC:
Безопасность, токены
RFC 6749 (OAuth 2.0)
RFC 6819 - модель угроз и сценарии атак на OAuth 2.0
RFC 6750 (Bearer Token)
RFC 7519 (JWT) - структура токена, claims, ограничения на использование
RFC 7515 (JWS) - как формируется и проверяется подпись
RFC 7516 (JWE) - как шифруются токены
RFC 7517 (JWK) - формат хранения и ротации ключей
RFC 7518 (JWA) - допустимые алгоритмы
RFC 5280 (X.509) - сертификаты, CRL, цепочки доверия, поля сертификатов, требования к валидации
RFC 4949 - термины по информационной безопасности
Интеграция
RFC 9110-9112 (HTTP) - методы, статусы, идемпотентность, кеширование
RFC 3986 (URI) - как формируются идентификаторы ресурсов и параметры
RFC 8259 (JSON)
RFC 7807 (Problem Details) - формат ошибок для API
RFC 6455 (WebSocket)
RFC 3339 (Date and time) - формат времени для событий
Криптография
RFC 2104 (HMAC) - контроль целостности и аутентичности сообщений
RFC 5869 (HKDF) - корректное получение ключей из секретов
RFC 8017 (RSA/PKCS#1) - требования к использованию RSA
#RFC
В работе системного аналитика часто возникают вопросы о корректности интеграционных решений, выборе протоколов и форматов данных и связанных с ними нюансах. Можно гуглить статьи, искать на Stack Overflow или спрашивать у ChatGPT. Но есть риск наткнуться на чью-то интерпретацию.
Если вы хотите быть уверенными в своих требованиях, то я рекомендую использовать RFC (Request for Comments) как первоисточник и ссылаться на них.
Вот некоторые полезные RFC:
Безопасность, токены
RFC 6749 (OAuth 2.0)
RFC 6819 - модель угроз и сценарии атак на OAuth 2.0
RFC 6750 (Bearer Token)
RFC 7519 (JWT) - структура токена, claims, ограничения на использование
RFC 7515 (JWS) - как формируется и проверяется подпись
RFC 7516 (JWE) - как шифруются токены
RFC 7517 (JWK) - формат хранения и ротации ключей
RFC 7518 (JWA) - допустимые алгоритмы
RFC 5280 (X.509) - сертификаты, CRL, цепочки доверия, поля сертификатов, требования к валидации
RFC 4949 - термины по информационной безопасности
Интеграция
RFC 9110-9112 (HTTP) - методы, статусы, идемпотентность, кеширование
RFC 3986 (URI) - как формируются идентификаторы ресурсов и параметры
RFC 8259 (JSON)
RFC 7807 (Problem Details) - формат ошибок для API
RFC 6455 (WebSocket)
RFC 3339 (Date and time) - формат времени для событий
Криптография
RFC 2104 (HMAC) - контроль целостности и аутентичности сообщений
RFC 5869 (HKDF) - корректное получение ключей из секретов
RFC 8017 (RSA/PKCS#1) - требования к использованию RSA
#RFC
👍5❤3🔥3
Как настолка заменяет скучные митинги по моделированию угроз
Моделирование угроз часто воспринимается как очередная бюрократическая задача. Но что, если превратить поиск угроз в игру?
Для этого можно использовать Elevation of Privilege (EoP), карточная игра, созданная Адамом Шостаком для поиска угроз по STRIDE (он же и один из авторов этого подхода). Есть и альтернативы: Cornucopia от OWASP, LINNDUN GO.
Существует множество вариантов для онлайн игры. Например, шаблон в Miro, онлайн Croupier для раздачи карт. Мы в команде пробовали эти варианты, но нам не зашло. В онлайне теряется динамика, а обсуждение превращается в очередной унылый созвон.
В итоге мы приобрели физическую колоду и собрались всей командой за одним столом. Кстати, карты можно просто распечатать (по первой ссылке найдёте исходники карт).
Плюсы игры (особенно оффлайн):
• Максимальное вовлечение: Когда у тебя в руках физическая карта, то мозг включается иначе. Это уже не заполнение таблицы или документа, а квест.
• Прокачка security мышления: Участники игры (аналитики, тестировщики, разработчики) начинают видеть архитектурные решения и Use Cases под углом векторов атак (которые можно фиксировать в виде Attacker Story).
• Живая дискуссия: Спор о том, применима ли карта к конкретному флоу, рождает гораздо больше инсайтов, чем сухой опросник.
• Тимбилдинг: Это весело. Страх перед сложным AppSec исчезает, когда безопасность подается через механику игры.
Правила игры простые, но мы немного адаптировали их под себя.
Чтобы игра была эффективной, важно:
1. Подготовить схему вашей системы. Заранее отрисуйте DFD или C4 (Container/Component diagram). Не забудьте указать границы доверия на схеме.
2. Зафиксировать Assumptions. Опишите контекст: какие контрмеры уже внедрены, кого мы рассматриваем как злоумышленника и т.д.
3. Фиксируйте все найденные угрозы. Даже отклоненные. Позже их стоит добавить в Assumptions.
#ThreatModeling #STRIDE #AttackerStory
Моделирование угроз часто воспринимается как очередная бюрократическая задача. Но что, если превратить поиск угроз в игру?
Для этого можно использовать Elevation of Privilege (EoP), карточная игра, созданная Адамом Шостаком для поиска угроз по STRIDE (он же и один из авторов этого подхода). Есть и альтернативы: Cornucopia от OWASP, LINNDUN GO.
Существует множество вариантов для онлайн игры. Например, шаблон в Miro, онлайн Croupier для раздачи карт. Мы в команде пробовали эти варианты, но нам не зашло. В онлайне теряется динамика, а обсуждение превращается в очередной унылый созвон.
В итоге мы приобрели физическую колоду и собрались всей командой за одним столом. Кстати, карты можно просто распечатать (по первой ссылке найдёте исходники карт).
Плюсы игры (особенно оффлайн):
• Максимальное вовлечение: Когда у тебя в руках физическая карта, то мозг включается иначе. Это уже не заполнение таблицы или документа, а квест.
• Прокачка security мышления: Участники игры (аналитики, тестировщики, разработчики) начинают видеть архитектурные решения и Use Cases под углом векторов атак (которые можно фиксировать в виде Attacker Story).
• Живая дискуссия: Спор о том, применима ли карта к конкретному флоу, рождает гораздо больше инсайтов, чем сухой опросник.
• Тимбилдинг: Это весело. Страх перед сложным AppSec исчезает, когда безопасность подается через механику игры.
Правила игры простые, но мы немного адаптировали их под себя.
Чтобы игра была эффективной, важно:
1. Подготовить схему вашей системы. Заранее отрисуйте DFD или C4 (Container/Component diagram). Не забудьте указать границы доверия на схеме.
2. Зафиксировать Assumptions. Опишите контекст: какие контрмеры уже внедрены, кого мы рассматриваем как злоумышленника и т.д.
3. Фиксируйте все найденные угрозы. Даже отклоненные. Позже их стоит добавить в Assumptions.
#ThreatModeling #STRIDE #AttackerStory
👍7
Делюсь личным достижением - я сдал экзамен и получил сертификат CSSLP (Certified Secure Software Lifecycle Professional) от ISC².
В мире кибербезопасности одна из самых известных сертификаций это CISSP. Она очень широкая и охватывает всё: от управления рисками до физической защиты дата-центров. Однако я для себя выбрал CSSLP, потому что меня больше интересует Secure SDLC.
Что полезного аналитик может найти при подготовке к сертификации CSSLP?
Многие привыкли, что безопасность - это набор фичей, которые определяет кто-то из департамента ИБ. Но CSSLP учит, что безопасность должна начинаться на самых первых этапах создания ПО с участием бизнеса и в том числе на этапе анализа бизнес-требований.
Подготовка к сертификации CSSLP помогает аналитику прокачать:
• Threat modeling: навык находить угрозы и уязвимости еще до начала разработки, анализируя DFD и сценарии использования.
• Risk assessment: умение оценивать риски, исходя из вероятности реализации угроз и потенциального ущерба. Это позволяет приоритизировать требования и брать в работу в первую очередь то, что действительно критично для бизнеса.
• Security requirements: проработку abuse cases и формирование требований с учётом классификации данных и актуальных угроз, включая требований регуляторов (PCI DSS, GDPR).
• Attack surface management: оценка и минимизация поверхности атаки (attack surface) на этапе анализа и дизайна; понимание того, как уменьшить количество точек входа, доступных злоумышленнику, без потери бизнес-ценности.
• Security principles: применение фундаментальных принципов (Least Privilege, Separation of Duties, Fail-safe Defaults) при проектировании системы.
Что внутри CSSLP? (8 доменов)
Экзамен проверяет знания по всей цепочке создания продукта:
1️⃣ Secure software concepts - основные концепции, принципы информационной безопасности, триада CIA, AAA, управление рисками.
2️⃣ Lifecycle management - интеграция ИБ в SDLC, патч-менеджмент, метрики.
3️⃣ Requirements - сбор и анализ требований безопасности, abuse cases, классификация данных.
4️⃣ Architecture and design - моделирование угроз, минимизации поверхности атаки, безопасная архитектура.
5️⃣ Implementation - безопасное кодирование, защитные механизмы, управление памятью, безопасность сборки.
6️⃣ Testing - порядок и виды тестирования, управление тестовыми данными.
7️⃣ Deployment, operations, maintenance - логирование, мониторинг, управление конфигурацией и управление инцидентами.
8️⃣ Supply chain - оценка поставщиков, анализ Open Source (SCA), проверка подлинности компонентов, риски аутсорсинга.
Более подробное описание каждого домена здесь.
Если интересно, какие материалы и как я использовал для подготовки, то пишите, постараюсь ответить.
#CSSLP #AppSec #SecurityByDesign #SecureSDLC
В мире кибербезопасности одна из самых известных сертификаций это CISSP. Она очень широкая и охватывает всё: от управления рисками до физической защиты дата-центров. Однако я для себя выбрал CSSLP, потому что меня больше интересует Secure SDLC.
Что полезного аналитик может найти при подготовке к сертификации CSSLP?
Многие привыкли, что безопасность - это набор фичей, которые определяет кто-то из департамента ИБ. Но CSSLP учит, что безопасность должна начинаться на самых первых этапах создания ПО с участием бизнеса и в том числе на этапе анализа бизнес-требований.
Подготовка к сертификации CSSLP помогает аналитику прокачать:
• Threat modeling: навык находить угрозы и уязвимости еще до начала разработки, анализируя DFD и сценарии использования.
• Risk assessment: умение оценивать риски, исходя из вероятности реализации угроз и потенциального ущерба. Это позволяет приоритизировать требования и брать в работу в первую очередь то, что действительно критично для бизнеса.
• Security requirements: проработку abuse cases и формирование требований с учётом классификации данных и актуальных угроз, включая требований регуляторов (PCI DSS, GDPR).
• Attack surface management: оценка и минимизация поверхности атаки (attack surface) на этапе анализа и дизайна; понимание того, как уменьшить количество точек входа, доступных злоумышленнику, без потери бизнес-ценности.
• Security principles: применение фундаментальных принципов (Least Privilege, Separation of Duties, Fail-safe Defaults) при проектировании системы.
Что внутри CSSLP? (8 доменов)
Экзамен проверяет знания по всей цепочке создания продукта:
1️⃣ Secure software concepts - основные концепции, принципы информационной безопасности, триада CIA, AAA, управление рисками.
2️⃣ Lifecycle management - интеграция ИБ в SDLC, патч-менеджмент, метрики.
3️⃣ Requirements - сбор и анализ требований безопасности, abuse cases, классификация данных.
4️⃣ Architecture and design - моделирование угроз, минимизации поверхности атаки, безопасная архитектура.
5️⃣ Implementation - безопасное кодирование, защитные механизмы, управление памятью, безопасность сборки.
6️⃣ Testing - порядок и виды тестирования, управление тестовыми данными.
7️⃣ Deployment, operations, maintenance - логирование, мониторинг, управление конфигурацией и управление инцидентами.
8️⃣ Supply chain - оценка поставщиков, анализ Open Source (SCA), проверка подлинности компонентов, риски аутсорсинга.
Более подробное описание каждого домена здесь.
Если интересно, какие материалы и как я использовал для подготовки, то пишите, постараюсь ответить.
#CSSLP #AppSec #SecurityByDesign #SecureSDLC
🔥18❤1👏1🫡1
На днях внёс небольшой вклад в Open Source, добавил перевод на русский язык для обновлённой версии проекта OWASP Cornucopia.
Что это такое?
Это карточная игра для моделирования угроз. Для системного аналитика это отличный инструмент, чтобы на этапе дизайна системы выявить риски, о которых часто забывают.
В чём главная ценность (помимо геймификации):
Каждая карта это не просто описание угрозы, а набор ссылок для проработки требований:
- ASVS. Ссылка на стандарт верификации безопасности (помогает сразу прописать необходимые требования).
- Классификация угрозы по методологии STRIDE.
- CAPEC, SAFECODE, OWASP DevGuide и др. База знаний о том, как именно угроза может быть реализована и как защититься.
Почему стоит попробовать?
Это бесплатно и онлайн. Не нужно ничего покупать или распечатывать. Можно играть с распределенной командой прямо в браузере.
Прокачка навыков.
По каждой карте на сайте есть подробное описание и гиперссылки. Это позволяет узнавать новое и развиваться прямо в процессе сессии моделирования угроз.
#ASVS #ThreatModeling #OWASP
Что это такое?
Это карточная игра для моделирования угроз. Для системного аналитика это отличный инструмент, чтобы на этапе дизайна системы выявить риски, о которых часто забывают.
В чём главная ценность (помимо геймификации):
Каждая карта это не просто описание угрозы, а набор ссылок для проработки требований:
- ASVS. Ссылка на стандарт верификации безопасности (помогает сразу прописать необходимые требования).
- Классификация угрозы по методологии STRIDE.
- CAPEC, SAFECODE, OWASP DevGuide и др. База знаний о том, как именно угроза может быть реализована и как защититься.
Почему стоит попробовать?
Это бесплатно и онлайн. Не нужно ничего покупать или распечатывать. Можно играть с распределенной командой прямо в браузере.
Прокачка навыков.
По каждой карте на сайте есть подробное описание и гиперссылки. Это позволяет узнавать новое и развиваться прямо в процессе сессии моделирования угроз.
#ASVS #ThreatModeling #OWASP
2🔥8👏5❤2