V7.1.1 Log Content
Requirement:#
Verify that the application does not log credentials or payment details. Session tokens should only be stored in logs in an irreversible, hashed form. (C9, C10)
Explanation:#
Приложение должно быть спроектировано таким образом, чтобы не регистрировать какую-либо sensitive information. Сессионые токены, которые используются для поддержания пользовательских сессий, должны храниться в журналах только в необратимой, хешированной форме. Это означает, что даже если злоумышленник получит доступ к журналам, он не сможет использовать сессионые токены для идентификации пользователя.
Спроектируйте приложение так, чтобы оно не регистрировалоsensitive information:Приложение не должно регистрировать sensitive information, включая учетные данные и платежные реквизиты. Приложение должно регистрировать только то, что необходимо для мониторинга и устранения неполадок.
Внедрите методы безопасного ведения журналов: Если приложению необходимо регистрировать данные, внедрите безопасные методы ведения журналов, например, убедитесь, что журналы шифруются и хранятся в безопасном месте. Доступ к журналам должен быть ограничен только авторизованным персоналом.
Хешируйте сессионые токены перед записью в журнал: Если сессионые токены необходимо регистрировать в целях мониторинга или устранения неполадок, убедитесь, что они хранятся в необратимой, хешированной форме. Это не позволит злоумышленнику использовать сессионый токен для идентификации пользователя, даже если он получит доступ к журналам.
Регулярно просматривайте и анализируйте журналы:Регулярно просматривайте и анализируйте журналы для выявления любых потенциальных проблем безопасности или несанкционированного доступа. Любая подозрительная деятельность должна быть расследована незамедлительно.
Следуйте последним рекомендациям по безопасности:будьте в курсе последних рекомендаций по безопасности и следите за тем, чтобы приложение регулярно обновлялось для устранения любых новых уязвимостей или угроз.
Remediation:#
Никогда не регистрируйте данные, если это не разрешено законом. Например, перехват некоторых сообщений, мониторинг сотрудников и сбор некоторых данных без их согласия могут быть незаконными.
Никогда не исключайте какие-либо события от «известных» пользователей, таких как другие внутренние системы, «доверенные» третьи стороны, роботы поисковых систем, uptime мониторинг систем и других систем удаленного мониторинга, аудиторов безопасности. Однако вы можете захотеть включить флаг классификации для каждого из них в записанные данные.
Следующее обычно не должно записываться непосредственно в журналы, а вместо этого должно быть удалено, замаскировано, очищено, захэшировано или зашифровано:
Application source code
Session identification values (рассмотрите возможность замены хешированным значением, если это необходимо для отслеживания конкретных событий сессии)
Access tokens
Sensitive personal data and some forms of personally identifiable information (PII), например, здоровье, удостоверяющие личность, правительственные идентификаторы, социально незащищенные люди
Authentication passwords
Database connection strings
Encryption keys and other master secrets
Bank account or payment card holder data
Data of a higher security classification, которую разрешено хранить системе логирования
Commercially-sensitive information
Информация, сбор которой является незаконным в соответствующих юрисдикциях
Информация, которую пользователь отказался от сбора или не давал согласия, например, использование запрета на отслеживание или когда срок действия согласия на сбор истек
Иногда также могут существовать следующие данные, и хотя они могут быть полезны для последующего расследования, может потребоваться их особая обработка перед записью события:
- File paths
- Database connection strings
- Внутренние сетевые имена и адреса
- Non sensitive personal data, например имена, номера телефонов, адреса электронной почты