Shared General Controls
Later on in this article, we’ll talk about Business Impact Analysis (BIA) and its place within the organization. At this point, when we want to talk about logical security, the BIA must have already been completed; the system and data owners identified; and the primary and supporting assets identified.
You will recall that the primary assets consist of two elements: 1) Business processes & activities and 2) Information. It’s this second element which drives logical security and that, put simply is;
- How is the access to the information to be controlled?
- How is it to be secured?
Or even more basically,
- What is the logical security for this business process?
So let’s look at logical security from an IT auditor’s perspective. As a starting point, in the auditor’s interview of the client, they might state something like; “Show me your most recent Business Impact Analysis.” Just as an aside notice that the auditor didn’t ask, “Do you have a Business Impact Analysis?” The last question is a simple yes/no question and can be responded to by the client with a simple yes or no. The auditor did say “Show me…” which requires the client to produce the BIA or to state that one doesn’t exist.
Just a couple of quick words about the BIA. Every organization should go through a process of identifying all the business processes. Then once they have identified the processes they need to identify the assets that support that process, both primary (processes and information) and secondary (hardware, software, network, people, site and organization). Then they will need to identify the criteria which determines whether the process is sensitive or not and do a process profile where they identify key players like system owner, data owner, system administrator, data custodian and the like. Then they will need to classify the data according to sensitivity — not forgetting legal requirements — and they will wrap it up with the recovery time objective, recovery point objective and the system boundary (who the system or data is shared with).
The next thing the IT auditor might say would be something like; “I see in your BIA you have identified Payroll as a business process. Show me the data classification which you did for all the data elements within the Payroll process.” Again notice the format of the question; state the obvious, “Payroll is a business process” and then follow that with an action statement not a yes/no question. In this case, again, “Show me the data classification…”
Speaking of data classification, you as an IT auditor will also need to look at HOW the data classification was done and how the data elements are classified. This is where your professional judgment comes into play. You might want to consider having a copy of NIST SP 800-60 so that you can cite industry best practices for classification of data.
Now that you’ve seen the data classification, what should you look for? The obvious next question is logical access control. You should be saying things like, “Show me the roles and responsibilities you have established for the people who have access to the payroll information.” And from this information, you would ask, “Show me who has access to each of these defined roles.” From that information you should be able determine if there is adequate separation of duties. Be sure to follow this up with the question of, “Show me which IT staff have access to the data files and what their rights are.” What we’re looking for is who, from a system point of view, has –rwx or full control access to the data.
Let’s keep talking about access control for a few more lines, but let’s bring encryption into the picture. Access can be logical or physical and when it is logical it can be local or remote. In either of the cases, that information needs to be protected while “at rest” and while “in transit.”
From an IT audit perspective let’s look at just the remote logical access for a moment. Let’s say that when you look at the BIA you notice that part of the boundary statement includes remote access by payroll administrative staff. Your question might take the form of, “How is the information that is accessed remotely by the payroll administrative staff encrypted?” Here again I want you to notice the particular framing of the question. You’re not asking if the data is encrypted which would be a yes/no question but how is it encrypted. That requires the client to explain. Now I’m sure at some point someone will say they aren’t encrypting the data and that will cause you to go down a whole set of other questions, but for this article, let’s assume that the client says they are using CISCO VPN and SecurID from RSA. So think for a second before you read on, what questions would you ask? Let’s look at VPN first:
- Is the CISCO VPN client installed on company owned equipment or on the user’s personal equipment (the risks are different)?
- Is the CISCO device IOS current?
- Who maintains the VPN configuration?
- Where does the VPN tunnel terminate within the client’s network and what are the protections between the end of the tunnel and the payroll data files?
Now’s let’s look at some questions for SecurID from RSA.
- Who controls the RSA server configuration?
- Who controls the RSA SecurIDs?
- Are you aware of the recent RSA data breach and what steps are you taking to address the compromise announced by Lockheed?
That addresses the data while “in transit,” now let’s see what we might ask to determine if encryption is used for “at rest” data.
- Do the remote devices have hard disk encryption installed?
- What encryption standard is used for the payroll application data files?
- How are hard copy documents which contain payroll data protected?
This should give you an idea of some questions to ask regarding encryption.
Let’s stay with the payroll BIA process for a while longer and look at change management. What are you concerned with? This is a real easy one – any and all changes go through change control – period – end of story. No exceptions. Not only do all changes go through change control, they need to be tested, prior to being implemented into production and the changes need to be approved by management, scheduled to be implemented at the appropriate time, etc. And if you have a COTS payroll package (common off-the-shelf), then you’ll also need to make sure that the system has a patch management process in place, and yes patches are changes and they too must go through change control.
Can you imagine what management would say if the payroll manager said to their boss, “The payroll system is down and we won’t be able to run payroll this pay period and it looks like it will be several days/weeks/or a month before we’re back online.” The boss is probably going to start firing people indiscriminately starting with the payroll manager, most of the IT department, and then coming looking for you the IT auditor because you didn’t make them aware of the risk associated with not having a BCP/DRP.
So let’s get you some questions, so you don’t have to worry about losing your job because you forgot this area. The first question should be, “Show me your current Business Continuity Plan and your current Disaster Recovery Plan.” And as soon as the client hands you those plans say, “Now show me the tests results of your most recent tests of the BCP and the DRP.” And follow that without even taking a breath by saying “And also show me what you documented as Lessons Learned and where the changes are to reflect those lessons learned in the BCP and DRP.”
If the client doesn’t have either of those plans or if they haven’t tested them, then you should immediately make the payroll manager’s boss know, because this is one of those situations where you have identified a risk that needs to be communicated immediately and not after the final audit report is written. Be careful how you communicate, you don’t want to be over zealous. Be calm and state the facts, “I have identified a significant deficiency within the payroll application which represents a risk to the organization. What I have identified is there is no contingency plan in place for processing payroll should the system which supports payroll become unavailable.”
The payroll manager should hear this first and you should ask if the finding is correct. If the payroll manager says the finding is correct then you need to say to the payroll manager that it represents a significant deficiency and you have to report this to senior management as soon as possible. You could even ask the payroll manager to call their boss to schedule the appointment and to accompany you when you tell senior management. I’m sure senior management will be more than just a little concerned to find out they might not be getting paid.
So the last few lines cover a little of the audit strategy and hopefully sheds some light on some of the shared general controls and IT audits involvement. Let me take just a few sentences and talk about application control.
Application control, and in particular the payroll business process which I have been writing about is a very good example to look at some basic application controls. I will not be discussing all the application controls which deal with internal program calculations for taxes or net pay for those would be more appropriate for the Financial Auditor, rather I will address only the access to the application. For example, some of the things you want to look at are who has access to the source code; do all changes go through change management; are all changes tested before being put into production; do application developers have access to production source code; is there separation of duties when it comes to test changes and moving source code between the development, test, and production libraries; are changes logged (automatically); is QA performed on the changes; are the changes current (in payroll, tax changes are time sensitive); is access to the production application data restricted such that developers do not have access; if production data is used to populate the development and test instances, is it sanitized before being used?
When I talk about application control, I would be remiss if I didn’t at least mention the application development environment. Some application departments are small (as in a single programmer – I have a client who has a staff of one), and some are very large where separation of duties is not even an issue. It’s in the smaller shops that you will need to be more cognizant of when you’re doing your application audit and remember that while it may appear they aren’t doing something, always ask if there are compensating controls which you might see at first that would answer one of your questions.
Until next time, happy reading.