Skip main navigation

£199.99 £139.99 for one year of Unlimited learning. Offer ends on 28 February 2023 at 23:59 (UTC). T&Cs apply

Find out more

Accounting Considerations

In this video, you will learn about accounting considerations.
Finally, we’re going to look at accounting. In accounting we’re talking about linking all of the access, so our identification, our authentication and our authorization, through to the accountability section. We’re trying to show what people have done. And accountability then arises from the effectiveness of our identity authentication and authorization processes. If we do not have effective identity authentication and authorization, then the accountability piece falls away. Part of the accountability is produced through the logging of data. So the authentication and the ongoing authorization helps us maintain a record of the activities undertaken by that identity or by that account.
So accountability is the end goal, this is why we’re doing the identity management, the authentication, the authorization – to give us this accountability, to understand what people have been trying to do, what they have successfully done, who has done what, when, and where. So what can undermine accountability? What can remove accountability? Well we’ve said having non-unique credentials or credential sharing. So if you have a username and a password on a Post-it note, then at that point the credential becomes in effect non-unique. We’ll lose the accountability. And this is something I’m guessing you guys see similarly, if you have senior members of staff, their executive assistants or personal assistants quite often have access to the credentials for that person.
If they undertake, if that identity undertakes an illegal or inappropriate action, who is responsible? Is it the senior figure, or is it their executive assistant? We have no way of knowing. Or it becomes much more difficult to prove. And logging does have a cost. Logging has a cost in terms of processor utilization, in terms of memory, and in terms of storage. Particularly in terms of storage. On network devices, on Cisco devices, if you type the command ‘show debug all’ – if anybody’s ever done this, this can actually overwhelm the device.
Turning on the logging can if a device is running at 60% CPU utilization, a router or firewall, turning on the debugging, showing all that logging can actually cause the device to fail. So we need to be very sensitive to the fact that resources are required. And we need, as with other parts of our identity and access management system, we need a policy and a set of processes that inform this. How long are we keeping our successful and unsuccessful logins and log off events for? Is it differentiated? Are we saying that within the accounting team, we keep the logs for six months, but for the rest of the organization we keep it for one month?
You need to understand what your requirements are and implement them accordingly, and adapt accordingly, and to resource it accordingly. Bear in mind that, by default, when you’re looking at workstation logging for application events, system events, and security events, Windows – it’s retention is defined based on the size of the log. So how long the log file is retained for is a function of how many events you’ve had. So if you have a very busy workstation, doing lots of different things that are recorded in the log files, those logs can be erased within one or two days. Conversely, you may keep those logs for a year if the device is used infrequently.
Far better than relying on just the size of the storage is to specify a policy. And we see log aggregation and SIEM systems helping us with that; they can help take all of the logs and protect them. What we also want is for any logging activity that we do to be protected, for the integrity of the logs to be protected, to prevent people from altering them. And so be aware of the cost, of the overhead. We also want any logs, any accounting that we undertake, to be to be enforceable.
If we have shared credentials then people can– the person undertaking, the actual account owner could repudiate the assertion that they have misused their privileges or that they’ve tried to misuse their privileges. So we do not want to undermine the accountability. This is why it’s important that we have an account linked to a person. It’s interesting – strong authentication with the one-time passwords really does help us with this because the one-time password is typically issued through something like a soft token that is linked to an individual. Much harder to share those credentials at that point. So, we also need to define an accounting scope, what logs do we have and what’s required.
What we’re talking about with logging at the moment is very, very big data. We have too many logs to actively interrogate for most IT security functions. What do we want to audit? The use of particular privileges, start up or shut down events, log in or log off events – we need to understand what we want to log and what we want to retain and for how long we want to retain it.
So protecting our accounting data, we’ve said we need to protect our logs. We need to define our log retention schedules. And logs at the point of generation are often disaggregated. Individual workstations, individual applications, individual clients will generate logs. These are not helpfully created often in a standard format either. So ideally, we want to normalize the logs and centralize them. We want to enforce integrity protection for our logs. We want to remove the ability for individual users to remove those logs as well. We want a network time synchronisation to help ensure that the log timestamps are trusted. Very hard to correlate data if the time is not consistent or can be amended.
If somebody can change their workstation clock and time, then the logs associated with that workstation would reflect the altered time. We also want to preserve the confidentiality of our logs. Very important – things like API keys, sensitive URLs, session data, can all be contained within logs. So our web server logs particularly, we want to make sure are secured. Far too often you see web servers publishing their logs folder as part of the website. So if you go to a website and type /logs or /admin, occasionally you will see administrative interfaces that can be accessed. Sometimes the logs directory can be accessed without any authentication. It’s just published as part of a site.
Or the administration section being something that could brute forced. So this is something we want to be very careful about. Our log files, increasingly, things like API keys, can be contained within the URL, session data can be contained within the URL. This could lead to session hijacking or the reuse of existing authenticated sessions.

In this video, you will learn about accounting considerations. Effective identity authentication and authorization should result in high data logging accountability.

Investigate and share: Review your own accounting approach in light of what you have learned. Are there any useful insights you can share with your fellow learners? Share in the comments below.

This article is from the free online

Cyber Security Foundations: Identity and Access Management

Created by
FutureLearn - Learning For Life

Our purpose is to transform access to education.

We offer a diverse selection of courses from leading universities and cultural institutions from around the world. These are delivered one step at a time, and are accessible on mobile, tablet and desktop, so you can fit learning around your life.

We believe learning should be an enjoyable, social experience, so our courses offer the opportunity to discuss what you’re learning with others as you go, helping you make fresh discoveries and form new ideas.
You can unlock new opportunities with unlimited access to hundreds of online short courses for a year by subscribing to our Unlimited package. Build your knowledge with top universities and organisations.

Learn more about how FutureLearn is transforming access to education