📢 Добро пожаловать на канал Application Security Business Partner!
Привет! Меня зовут Алексей Краснов, и я рад приветствовать вас здесь.
О чём этот канал?
Этот канал создан для тех, кто хочет:
- Понять, как обеспечить безопасность программного обеспечения.
- Внедрить ИБ на каждом этапе жизненного цикла разработки (SDLC).
- Углубить знания в анализе и разработке требований безопасности.
Что вас ждёт?
- Разбор принципов информационной безопасности и их применение на практике.
- Методы бизнес-анализа для выявления и проверки требований ИБ.
- Методы обеспечения безопасности ПО.
- Инструменты, процессы и подходы для создания безопасного ПО.
Для кого этот канал?
- Для системных и бизнес-аналитиков, которые хотят научиться работать с требованиями ИБ.
- Для всех, кто разрабатывает или участвует в создании безопасного ПО.
Присоединяйтесь! Впереди – полезные материалы и практические советы. 🚀
Привет! Меня зовут Алексей Краснов, и я рад приветствовать вас здесь.
О чём этот канал?
Этот канал создан для тех, кто хочет:
- Понять, как обеспечить безопасность программного обеспечения.
- Внедрить ИБ на каждом этапе жизненного цикла разработки (SDLC).
- Углубить знания в анализе и разработке требований безопасности.
Что вас ждёт?
- Разбор принципов информационной безопасности и их применение на практике.
- Методы бизнес-анализа для выявления и проверки требований ИБ.
- Методы обеспечения безопасности ПО.
- Инструменты, процессы и подходы для создания безопасного ПО.
Для кого этот канал?
- Для системных и бизнес-аналитиков, которые хотят научиться работать с требованиями ИБ.
- Для всех, кто разрабатывает или участвует в создании безопасного ПО.
Присоединяйтесь! Впереди – полезные материалы и практические советы. 🚀
❤1👍1
Принципы информационной безопасности и их применение в бизнес-анализе
В ближайших публикациях на канале я буду говорить о принципах информационной безопасности и о том, как бизнес-аналитики и системные аналитики могут использовать эти принципы при выявлении и анализе требований к информационной безопасности программного обеспечения.
Основой для обсуждений станут классические Design Principles, описанные почти 50 лет назад в статье The Protection of Information in Computer Systems авторами Jerome Saltzer и Michael Schroeder. Несмотря на возраст, эти принципы остаются фундаментом для проектирования безопасных систем:
- Economy of mechanism (Экономия механизма)
- Fail-safe defaults (Отказ в безопасном состоянии)
- Complete mediation (Полное посредничество )
- Open design (Открытый дизайн)
- Separation of privilege или Separation of duties (Разделение обязанностей)
- Least privilege (Минимальные привилегии)
- Least common mechanism (Минимальный общий механизм)
- Psychological acceptability (Психологическая приемлемость)
А также дополнительные принципы, которые широко применяются в информационной безопасности:
- Defense in depth или Layered defense (Эшелонированная оборона)
- Weakest link (Самое слабое звено)
- Leveraging existing components (Использование существующих компонентов)
- Single point of failure (Единая точка отказа)
- Good enough security (Достаточная безопасность)
Каждую тему я рассмотрю с двух сторон:
1️⃣ Что означает сам принцип и почему он важен?
2️⃣ Какие методы бизнес-анализа можно использовать, чтобы убедиться в соблюдении этого принципа при анализе требований и возможных решений?
#принципы_ИБ
В ближайших публикациях на канале я буду говорить о принципах информационной безопасности и о том, как бизнес-аналитики и системные аналитики могут использовать эти принципы при выявлении и анализе требований к информационной безопасности программного обеспечения.
Основой для обсуждений станут классические Design Principles, описанные почти 50 лет назад в статье The Protection of Information in Computer Systems авторами Jerome Saltzer и Michael Schroeder. Несмотря на возраст, эти принципы остаются фундаментом для проектирования безопасных систем:
- Economy of mechanism (Экономия механизма)
- Fail-safe defaults (Отказ в безопасном состоянии)
- Complete mediation (Полное посредничество )
- Open design (Открытый дизайн)
- Separation of privilege или Separation of duties (Разделение обязанностей)
- Least privilege (Минимальные привилегии)
- Least common mechanism (Минимальный общий механизм)
- Psychological acceptability (Психологическая приемлемость)
А также дополнительные принципы, которые широко применяются в информационной безопасности:
- Defense in depth или Layered defense (Эшелонированная оборона)
- Weakest link (Самое слабое звено)
- Leveraging existing components (Использование существующих компонентов)
- Single point of failure (Единая точка отказа)
- Good enough security (Достаточная безопасность)
Каждую тему я рассмотрю с двух сторон:
1️⃣ Что означает сам принцип и почему он важен?
2️⃣ Какие методы бизнес-анализа можно использовать, чтобы убедиться в соблюдении этого принципа при анализе требований и возможных решений?
#принципы_ИБ
Принцип экономии механизмов: ключ к упрощению безопасности
Принцип экономии механизмов (Economy of mechanism) является одним из фундаментальных принципов информационной безопасности. Его суть заключается в минимизации сложности программного обеспечения и систем, чтобы повысить их безопасность. Чем проще система, тем легче ее понять, а следовательно, обнаружить и устранить уязвимости. Простые механизмы уменьшают вероятность ошибок, обеспечивают легкость администрирования и снижают риск возникновения уязвимостей.
Почему это важно?
Сложность — враг безопасности. Системы с избыточным функционалом, часто включающим ненужные “украшательства” (“bells-and-whistles”), увеличивают поверхность атаки. Например, вероятность наличия уязвимостей у приложения с условно 2 миллионами строк кода намного больше, чем у приложения с 4000 строк (CWE-1120: Excessive Code Complexity). Упрощение систем снижает вероятность сбоев и упрощает процесс устранения неполадок.
Примеры применения:
1️⃣ Отключение ненужных сервисов и функций. В программном обеспечении часто остаются активными по умолчанию сервисы и функции, которые не нужны для текущих задач. Устранение таких сервисов и функций сокращает возможные точки входа для злоумышленников.
2️⃣ Упрощение механизмов аутентификации. Внедрение единого входа (SSO) упрощает процесс проверки подлинности для пользователей и уменьшает сложность системы управления учетными записями.
3️⃣ Упрощение проверки данных. Использование простых и понятных правил для проверки данных вместо сложных регулярных выражений снижает вероятность ошибок и уязвимостей, связанных с избыточной сложностью (например, CWE-407: Inefficient Algorithmic Complexity).
Для проверки соблюдения принципа экономии механизмов при анализе требований можно использовать следующие техники бизнес-анализа:
1️⃣Матрица трассировки требований (Requirement Traceability Matrix). Убедитесь, что все функции программного обеспечения связаны с конкретными бизнес-требованиями и бизнес-целями. Это помогает понять необходимость требований и исключить избыточные функции.
2️⃣Анализ корневых причин (Root Cause Analysis). Определяйте первопричины избыточной сложности или ошибок, чтобы устранить их на этапе проектирования.
3️⃣Моделирование и анализ бизнес-процессов. Упрощение процессов помогает снизить требования к функционалу системы, что, в свою очередь, упрощает безопасность.
4️⃣Проверка на избыточную функциональность. Проводите регулярные обсуждения с заинтересованными сторонами для выявления функций, которые не добавляют ценности, но увеличивают сложность.
5️⃣User stories с указанием целей. Формулируйте пользовательские истории так, чтобы они четко отражали связь функций с бизнес-целями.
6️⃣Use case (варианты использования). Используйте сценарии, чтобы убедиться, что каждая функция системы соответствует бизнес-целям и не выходит за их рамки.
7️⃣SWOT-анализ функций. Оценивайте преимущества и риски каждой функции, чтобы определить, какие из них стоит исключить.
Вывод
Принцип экономии механизмов - это не просто упрощение для удобства, но и важная стратегическая мера для обеспечения безопасности. Используя техники бизнес-анализа, аналитик может анализировать требования и оптимизировать их в соответствии с этим принципом. Простые, функциональные и безопасные системы - это результат правильного баланса между необходимой сложностью и минимизацией лишнего.
#принципы_ИБ
Пишите в комментариях, какие еще техники бизнес-анализа можно применять для проверки соблюдения описанного принципа!
Принцип экономии механизмов (Economy of mechanism) является одним из фундаментальных принципов информационной безопасности. Его суть заключается в минимизации сложности программного обеспечения и систем, чтобы повысить их безопасность. Чем проще система, тем легче ее понять, а следовательно, обнаружить и устранить уязвимости. Простые механизмы уменьшают вероятность ошибок, обеспечивают легкость администрирования и снижают риск возникновения уязвимостей.
Почему это важно?
Сложность — враг безопасности. Системы с избыточным функционалом, часто включающим ненужные “украшательства” (“bells-and-whistles”), увеличивают поверхность атаки. Например, вероятность наличия уязвимостей у приложения с условно 2 миллионами строк кода намного больше, чем у приложения с 4000 строк (CWE-1120: Excessive Code Complexity). Упрощение систем снижает вероятность сбоев и упрощает процесс устранения неполадок.
Примеры применения:
1️⃣ Отключение ненужных сервисов и функций. В программном обеспечении часто остаются активными по умолчанию сервисы и функции, которые не нужны для текущих задач. Устранение таких сервисов и функций сокращает возможные точки входа для злоумышленников.
2️⃣ Упрощение механизмов аутентификации. Внедрение единого входа (SSO) упрощает процесс проверки подлинности для пользователей и уменьшает сложность системы управления учетными записями.
3️⃣ Упрощение проверки данных. Использование простых и понятных правил для проверки данных вместо сложных регулярных выражений снижает вероятность ошибок и уязвимостей, связанных с избыточной сложностью (например, CWE-407: Inefficient Algorithmic Complexity).
Для проверки соблюдения принципа экономии механизмов при анализе требований можно использовать следующие техники бизнес-анализа:
1️⃣Матрица трассировки требований (Requirement Traceability Matrix). Убедитесь, что все функции программного обеспечения связаны с конкретными бизнес-требованиями и бизнес-целями. Это помогает понять необходимость требований и исключить избыточные функции.
2️⃣Анализ корневых причин (Root Cause Analysis). Определяйте первопричины избыточной сложности или ошибок, чтобы устранить их на этапе проектирования.
3️⃣Моделирование и анализ бизнес-процессов. Упрощение процессов помогает снизить требования к функционалу системы, что, в свою очередь, упрощает безопасность.
4️⃣Проверка на избыточную функциональность. Проводите регулярные обсуждения с заинтересованными сторонами для выявления функций, которые не добавляют ценности, но увеличивают сложность.
5️⃣User stories с указанием целей. Формулируйте пользовательские истории так, чтобы они четко отражали связь функций с бизнес-целями.
6️⃣Use case (варианты использования). Используйте сценарии, чтобы убедиться, что каждая функция системы соответствует бизнес-целям и не выходит за их рамки.
7️⃣SWOT-анализ функций. Оценивайте преимущества и риски каждой функции, чтобы определить, какие из них стоит исключить.
Вывод
Принцип экономии механизмов - это не просто упрощение для удобства, но и важная стратегическая мера для обеспечения безопасности. Используя техники бизнес-анализа, аналитик может анализировать требования и оптимизировать их в соответствии с этим принципом. Простые, функциональные и безопасные системы - это результат правильного баланса между необходимой сложностью и минимизацией лишнего.
#принципы_ИБ
Пишите в комментариях, какие еще техники бизнес-анализа можно применять для проверки соблюдения описанного принципа!
👍4
AppSec Business Partner pinned «📢 Добро пожаловать на канал Application Security Business Partner! Привет! Меня зовут Алексей Краснов, и я рад приветствовать вас здесь. О чём этот канал? Этот канал создан для тех, кто хочет: - Понять, как обеспечить безопасность программного обеспечения.…»
Сегодня рассмотрим следующий принцип информационной безопасности - принцип "отказ в безопасном состоянии" (Fail secure)
Все системы сталкиваются с отказами. Принцип "отказ в безопасном состоянии" (Fail secure или Fail-safe, который чаще встречается в физической безопасности) заключается в том, что при возникновении любого сбоя система должна быстро вернуться в безопасное состояние, сохраняя конфиденциальность, целостность и доступность данных. Это также подразумевает, что система может надежно продолжать функционировать даже во время атаки.
Один из способов реализации этого принципа - использование концепции явного запрета (запрещено всё, что явно не разрешено), что часто противоречит требованиям по удобству использования, поэтому здесь необходимо найти баланс.
Кроме того, для реализации этого принципа применяется управление исключениями, т.е ситуациями, когда система сталкивается с неизвестным состоянием или получает ввод, который приводит к ошибке. Это может быть, например, когда удаленный ресурс не отвечает или возникает ошибка связи - независимо от причины ошибки, важно, чтобы система реагировала должным образом.
Для безопасного управления исключениями необходимо учитывать несколько критериев:
❗️ Во-первых, все исключения должны быть обнаружены и обработаны.
✅ Во-вторых, система должна быть спроектирована таким образом, чтобы не переходить в небезопасное состояние.
🔒 В-третьих, все сообщения, связанные с исключениями, не должны содержать конфиденциальную и служебную информацию (например, наименование и версия сервиса, библиотек и т.п.).
Примеры реализации принципа Fail secure:
1️⃣ После достижения максимального количества попыток аутентификации пользователю по умолчанию отказывается в доступе, а учетная запись блокируется.
2️⃣ Недопущение ситуации, при которой исключения в коде игнорируется и выполнение программы продолжается, как будто ничего не произошло. Вместо этого все исключения должны обрабатываться безопасным образом, что обычно включает логирование ошибки для последующего анализа.
3️⃣ Ограничение объема информации, передаваемой пользователю в случае возникновения проблемы. Это предотвращает утечку данных, которые злоумышленник мог бы использовать для атаки на конкретную уязвимость.
В следующем посте я рассмотрю техники бизнес-анализа, которые могут помочь проверить соблюдение принципа Fail secure при анализе требований к программному обеспечению.
#принципы_ИБ
Все системы сталкиваются с отказами. Принцип "отказ в безопасном состоянии" (Fail secure или Fail-safe, который чаще встречается в физической безопасности) заключается в том, что при возникновении любого сбоя система должна быстро вернуться в безопасное состояние, сохраняя конфиденциальность, целостность и доступность данных. Это также подразумевает, что система может надежно продолжать функционировать даже во время атаки.
Один из способов реализации этого принципа - использование концепции явного запрета (запрещено всё, что явно не разрешено), что часто противоречит требованиям по удобству использования, поэтому здесь необходимо найти баланс.
Кроме того, для реализации этого принципа применяется управление исключениями, т.е ситуациями, когда система сталкивается с неизвестным состоянием или получает ввод, который приводит к ошибке. Это может быть, например, когда удаленный ресурс не отвечает или возникает ошибка связи - независимо от причины ошибки, важно, чтобы система реагировала должным образом.
Для безопасного управления исключениями необходимо учитывать несколько критериев:
❗️ Во-первых, все исключения должны быть обнаружены и обработаны.
✅ Во-вторых, система должна быть спроектирована таким образом, чтобы не переходить в небезопасное состояние.
🔒 В-третьих, все сообщения, связанные с исключениями, не должны содержать конфиденциальную и служебную информацию (например, наименование и версия сервиса, библиотек и т.п.).
Примеры реализации принципа Fail secure:
1️⃣ После достижения максимального количества попыток аутентификации пользователю по умолчанию отказывается в доступе, а учетная запись блокируется.
2️⃣ Недопущение ситуации, при которой исключения в коде игнорируется и выполнение программы продолжается, как будто ничего не произошло. Вместо этого все исключения должны обрабатываться безопасным образом, что обычно включает логирование ошибки для последующего анализа.
3️⃣ Ограничение объема информации, передаваемой пользователю в случае возникновения проблемы. Это предотвращает утечку данных, которые злоумышленник мог бы использовать для атаки на конкретную уязвимость.
В следующем посте я рассмотрю техники бизнес-анализа, которые могут помочь проверить соблюдение принципа Fail secure при анализе требований к программному обеспечению.
#принципы_ИБ
❤3
Для проверки соблюдения принципа 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