What should and shouldnt be audited in a Java EE Project

Question

I am in a need for advice in the matters of auditing a project.

Currently the project I am developing has many actions a "user" can perform such as:

• Changing his own password
• Adding, removing permissions
• Adding, removing roles
• Upload files
• Many others..

All these actions which are reachable to a User, are audited, however I don't know if its usual to for example audit the following:

Password policies state that the User password must include at least 1 symbol and 1 digit. Certain user at certain time tries to change his password without caring about the policies, of course he will get a message stating password policies are not respected, but should this be audited? I just want opinions from people that have audited before, or know on the matter.

Another possible case can be, when a user, tries to delete something that doesn't exist, for instance, having an empty list of permissions and trying to delete a non existing one, once again the user will get a message saying to select at least one permission to delete, but should this action be audited?

Any feedback is welcomed, my first time auditing a project, thanks :)

Answer 1

It strongly depends on you requirements. What does the client or regulations of the business require? Do you want to audit to make your system more secure? (by learning what malevolent users do)

And by "auditing", do you mean to log it in a file or to insert it in a DB to grab statistics?

EDIT Auditing everything might be a bit expensive, so I suggest you to make a list of items in order of priority. My list would look something like this.

• Any 500 http error (this is usually very easy to do)
• Logins (successful and failed)
• changes to any entity that is important to business (e.g. changes to personal data) and/or important to the application (as you mentioned adding / removing roles to users).
• Access denied errors (a logged in user, who tries to access a part of the site he's not allowed to access)
• Forged urls (access item with 666 although there's no item with that id in the DB)
• Urls that return 404 (potential user probing the application).

Again, that my list, you'll probably need to come up with your own. As you might want to have more advanced auditing such as "time spent on the site".

Another important thing: make the logs readable and search-able as much as you can.