V1.2.4 Authentication Architecture

Requirement:

Verify that the application uses a single vetted authentication mechanism that is known to be secure, can be extended to include strong authentication, and has sufficient logging and monitoring to detect account abuse or breaches.

Explanation:

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

1. Consistent Authentication Security Control Strength:

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

2. Uniformity Matters:

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

3. Avoiding Weaker Alternatives:

Требование не допускает использования более слабых методов аутентификации в одних частях приложения при одновременном использовании более сильных методов в других. Например, использование многофакторной аутентификации (MFA) для одного входа в систему и простого имени пользователя/пароля для другого потенциально может создать диcбаланс в безопасности.

4. Risk-Based Approach:

Безопасность не является универсальной. Различные части приложения могут иметь разный уровень риска безопасности в зависимости от таких факторов, как тип обрабатываемых данных, подверженность внешним угрозам и критичность для всей системы. Несмотря на важность единого подхода, он должен быть сбалансирован с учетом рисков. Это означает, что уровень контроля аутентификации должен соответствовать специфике риска каждого участка кода с аутентификацией или API.

5. Customization for Risk:

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

6. Security Control Consistency:

Согласованность не означает, что каждый метод аутентификации должен быть одинаково сильным. Напротив, это означает, что в каждой категории методов аутентификации (например, MFA, на основе пароля) средства контроля должны быть одинаковыми. Например, если вы используете MFA в одной части приложения, убедитесь, что одни и те же механизмы MFA и стандарты безопасности последовательно применяются во всех путях, поддерживающих MFA.

7. Overall Security Posture:

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

8. Audit and Compliance:

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

Remediation:

Для выполнения требований необходимо выполнить следующие действия:

1. Identify Authentication Pathways and Identity Management APIs:

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

2. Assess the Security Control Strength:

Для каждого участка с аутентификацией и управлением идентификацией для API-интерфейса, оценить надежность контроля безопасности, применяемый в настоящее время. Определить, не используются ли более слабые альтернативы.

3. Perform a Risk Assessment:

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

4. Define a Consistent Security Control Strategy:

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

5. Implement Security Controls:

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

6. Use Risk-Based Customization:

Настроить контроль безопасности в соответствии с профилем риска каждого участка кода с аутентификацией. Для областей с высоким уровнем риска используйте более надежные методы аутентификации, например MFA. Для объектов с низким уровнем риска следует использовать более простые контроли аутентификации.

7. Document Your Strategy:

Задокументировать свою последовательную стратегию управления безопасностью и обосновать её. Эта документация необходима для проведения аудита и обеспечения соответствия нормативным требованиям.

8. Test and Verify:

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

9. Monitor and Audit:

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

10. Remediate Discrepancies:

Если в ходе тестирования или мониторинга были обнаружены несоответствия в эффективности контроля безопасности, необходимо незамедлительно устранить их. При необходимости скорректировать контроль безопасности для поддержания согласованности.

11. Stay Informed:

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

Additional:

https://owasp.org/www-project-mobile-top-10/2014-risks/m5-poor-authorization-and-authentication