¿Qué datos deben registrarse?

Para ampliar las recomendaciones de Rory, realmente tienes que preguntarte qué es lo que impulsa tu registro y qué información necesitas para lograr esos objetivos.

Por ejemplo, ¿necesita la atribución del usuario? Si es así, entonces es probable que necesites

• nombre de usuario
• marca de tiempo
• IP de origen
• cadena GET y posiblemente variables POST
• ID de sesión
• Información de la cookie (caducidad, fichas, si corresponde, chocolate / azúcar / sin gluten, etc.)

¿Está buscando intentos de acceso no autorizados?

• marca de tiempo
• IP de origen
• Acción realizada (inicio de sesión, consulta de datos, etc.)
• Información relacionada con la acción, (nombre de usuario, cadena de consulta, etc.)

¿Tiene una política / contractual / regulatorio / etc que requiere la reconstrucción de la sesión completa? Bueno, eso es mucho más difícil y requerirá todo tipo de datos de miedo en cada solicitud. Esto probablemente requerirá una integración profunda de la aplicación y posiblemente necesite elementos como seguimientos de pila, volcados de variables, captura de paquetes, etc.

Realmente necesitas ver esto al revés, ¿para qué necesitas registrarte? Eso debería guiar su decisión sobre qué registrar.

• ¿Está comprobando un comportamiento sospechoso de una IP o rango de IP?
• ¿Está intentando monitorear el uso o las estadísticas de rendimiento?
• ¿Necesita poder ayudar a sus usuarios con su sesión si algo sale mal?
• ¿Necesita trabajar dentro de un marco regulatorio que especifica el manejo de datos?

etc.

Ciertamente hay valor en el registro de los encabezados HTTP. Exactamente cuáles registrar varían mucho dependiendo de la aplicación web específica.

Eche un vistazo a la hoja informativa de registro de OWASP que es especialmente adecuada para el desarrollo web. El consenso general es almacenar la mayor cantidad de información relevante posible sin información personal identificable o información comercial sensible. La recomendación de OWASP es más específica que IEC / ISO-27k .

Categorías para el registro:

• Seguridad: intentos de ataque, sesiones fallidas, problemas de codificación, errores de aplicación, etcétera.
• Autenticación: intentos de autenticación de usuario y resultados
• Autorización: suponiendo que esté utilizando los controles de acceso basados en roles (RBAC): cambios en los roles, permisos de roles y funciones de roles, etcétera.
• Auditoría: qué usuario intentó qué tipo de acceso (Lectura / Escritura / Eliminar / Archivar / Crear / Importar / Exportar) a qué recurso de datos con qué resultado
• Rendimiento: las estadísticas de CPU, RAM y E / S se pueden medir con cada solicitud HTTP, lo que puede ser útil para la medición de respuesta de la aplicación (ARM).

Evita el peligro de almacenar todos los datos POST o todos los encabezados HTTP, el vector de ataque solo será más grande.

No olvide para otorgar a la aplicación web una cuenta de solo escritura para el recurso de registro, y almacenar el registro en un lugar seguro donde no se pueda cambiar ni ver sin el permiso adecuado, por ejemplo en un servidor de registro con un sistema de gestión de información y eventos de seguridad (SIEM).

A menudo, existen requisitos legales para almacenar registros de 6 a 24 meses como mínimo y para acceder al registro de la aplicación.