Security Monitoring and Tracking Standards

Question

I am working on a system that processes authentication / authorization and should track login attempts, make changes to permissions / users, failed attempts, etc. We want to be able to analyze this information in a database for further analysis / search at a later time.

In our current implementation, we use the home standard, which is registered using the registration framework (Log4j in this case, but this is not that important). Is the logging system the right mechanism to track this information? It seems to me that this is not so; I always understood that registration is a form of code breaking - to find out more about what happened when for debugging, etc. This is more like a reporting mechanism for me. Are there any standards for this type of problem? Are there standard solutions / formats that people use? Does the logging system use the right solution for this, or is there a better way to process this type of data? What sources can be referenced when viewing this information and presenting it to interested parties?

I should note that the data that is recorded is already filtered based on compliance / security standards (no passwords, etc.), and all logging takes place in our internal environment. I'm more looking for a way that we can manage information about changing the authentication and authorization system.

Answer 1

It seems that you are using log4J for auditing (and probably for logging diagnostics or tracking information). To answer your question:

Is a logging system the right mechanism to track this information?

simple answer: "No, the logging structure is not the right mechanism." There are certain attributes that, if present as part of logging, will provide the ability to be used as an audit framework.

Some of these requirements are presented below, and log4j can be used to satisfy some of these requirements. This is not exhaustive, and I would recommend that you take a look at the implementation of audit structures (like LAUS) for a more complete list.

• The audit framework should provide a secure audit of events. This may depend on how the application uses the framework, but the basic requirement is that if the audit fails, then the application should also be applied. The application does not process any request if the event cannot be verified. The logging structure usually does not meet this requirement.
• The audit framework should ideally provide storage that is one-time and read-only. In other words, events recorded in the audit trail should and should not be deleted. The audit framework does not usually implement this protection on its own, instead relying on a combination of other factors to ensure that the journal is protected against unauthorized access.
• The audit framework should provide for the storage of audit logs in another system. This ensures that a compromise of one system does not compromise audit logs.
• The framework should also allow capturing important information and ideally not leave it to programmers. Important information will constitute a timestamp from the synchronized time source, the user responsible for the request (or any information to identify the user), the request source, the status of the request (regardless of whether it was successful or not), any errors that occurred during processing request, etc.

Answer 2

Fundamental registration is not, of course, bad. Writing to a file is usually faster than logging in a database. Although, with Log4j you can implement or use an existing JDBC attachment that will insert all your data into the database as it is registered. To ensure reliability, you can have both files and databases configured for audit logging, for backup in the event of a registration database failure.

Other alternatives may be aspects of AOP around your security / business logic that will insert data directly into the logging database.

I do not think there is a common standard for this kind of data.