Protective Monitoring/Audit
Protective monitoring or audit for large-scale systems is probably one of the most important parts of a software application. Wait, don’t run away. As someone who has been on both sides of the fence, I thought it would be worth writing my thoughts on why an audit is important, what is a good idea to put in as a software development team and what information or services the audit team can provide to make implementing audit logging easier.
Ennio Dybeli from Unsplash
So, what is protective monitoring anyway?
In a nutshell, it is providing logs to another application which can be used to search across them, to make sure the application is being used correctly. It is also to make sure that the application is being used by the correct people. For example, logging who has used the application to make sure they are using the application appropriately and if they are even allowed to use the application. This is especially important in an application which handles personally identifiable data. There are a few ways to do this.
You can have a Security Operations Centre (SOC). This team can look at the raw infrastructure logs and host-based logs to make sure the systems are being used as they should. This team would also typically be used to monitor networks to ensure that there are no unauthorised persons trying to access your network. Or indeed if there is someone within your organisation who is trying to do something they are not supposed to.
These types of logs are very useful and tooling for this is widely available especially if you use cloud platforms like AWS or Azure.
Example of Application-Level Monitoring
However, this type of logging is quite broad, wouldn’t it be beneficial to have a more detailed view of what a user has done in an application? To take a very simple note taking application as an example, it might be a good idea to log who logged into your application, when they added/edited/removed a note and when they logged out. This way you can get a timeline of what a user has done when they have used your application during that day.
Some consideration would need to be given to what to log, for example, if you need to know what that user put in the note they added. There is a privacy vs risk mitigation decision that might need to be made here depending on the sensitivity of the application you are talking about. In a basic to do list, you probably wouldn’t want to capture what a user was looking at, however, in a hospital’s record system you might want to log what record’s a particular member of staff has looked at so they can be randomly audited to make sure they are only looking at patient’s data they need to be looking at. Such logs can be beneficial for compliance purposes as well.
Basic events to provide as an audit
A basic question a developer can ask themselves if they are required to send actions to audit, is what someone might find useful when looking at the user activity of a particular person. It would generally be when a user:
· Has logged in/out
· Has added/edited/removed some data
· Has performed a search
· Has viewed a search result
· When a user has exported data from the system
So those are the actions. To make these useful, you would need the username of who performed the search and what time the action occurred at a minimum. There may be some other things that you wish to provide such as importing data into the system. Finally, engaging with the protective monitoring team early is generally a good idea. If you have already thought about the above all the better and then they can inform you of any more complex requirements or what data not to include in your logs. From personal experience, it is easier to provide your audit team with a dedicated set of audit logs tailored to their requirements rather than just sending them all your application logs which may be too noisy or contain events they are not interested in.
What can a Protective Monitoring Team provide?
If you have multiple web-based applications that you need to provide protective monitoring for, it could be useful to provide a rest API to which multiple different applications could write their audit. This helps application teams check that the data they are sending is wanted. Also being upfront about what your requirements are to the team is also a plus. In addition, if your requirements change then informing the application team as soon as you are able makes the application team’s lives easier.
Summary
So, to sum up then when developing applications, we should consider how they might be audited early in the development process. We should make sure we have an idea ourselves of what audit events we could provide. Finally, we should engage with the protective monitoring/audit team early in the development process to clearly understand the audit requirements. Obviously, if a team can provide detail on what level of audit, they can provide that makes a good starting point. Protective monitoring is a complicated task to do but audit and application teams working together will be able to provide a useful audit to help make sure systems are secured and used in a compliant way.
However, I am just one developer. I would be keen to hear your thoughts and experiences on audit/protective monitoring, on either delivering an application or on the audit side of the fence.
More Information
Logging and monitoring — NCSC.GOV.UK
About the Author
Niall Richards is a Senior Java Developer here at Version 1
