Quick question for software developers and auditors

[king_pellinor]

I've just been asked to verify that two controls over the security of an application we use are operating effectively.

One control is that we restrict developer access to particular people, and the other is that we ensure that the list of people permitted to access it through a certain security portal has been updated properly.

The application is developed by a third party, and we have no developer access at all.  Also, we don't use that security system, as  it's designed for mainframes and we work on Windows.

So as the two controls are utterly irrelevant to the application, are they "operating effectively" or not?

I'm threatened with "further action" if I get this wrong...

Comments

[purplecat]

I think you are safe on the first unless they belive that said particular people should have developer access, in which case you are doomed.

Not sure about the second, it would depend what they mean by "updated properly" - because the simplest thing, if no one needs to use that portal, would be to make sure the relevant list is empty, but again, if they believe that people should have access then you are in a difficult situation.

How bad would it be to query back and ask if "no one has access to either" would be a satisfactory answer?

[king-pellinor.livejournal.com]

Well we don't have access to the portal at all - it's a mainframe thing - so we don't even have a list, much less have it properly empty.

Querying things may be bad, I fear. This is a big checklist with people wanting to tick boxes (HAL is big on those), and "n/a" isn't a tick.

I suspect the only feasible course of action is to buy the company, integrate the development team into our business, and get them to port the software across to System z. Then I can tick the boxes with a clear conscience.

[purplecat]

My concern about the list would be that there may be some access point into the system you run that comes from this security portal, and that this front end in some way is supposed to act as a guardian to your system. So potentiallly, if you don't have it, there is an exploit which will allow someone to get into your bit of the system by pretending they've come through this portal which you don't have. I was assuming the list was on your side (and was the list of people allowed in by that means), if the list is on the mainframe side, not sure whether you have a problem or not.

If the security system genuinely doesn't exist for the software you are using and there is no version of it somewhere back at the company you have purchased the system from that might access your system, then I'd be inclined to say yes the list is being kept up-to-date properly on the grounds that there is no such list. If the security system does exist somewhere at the company and might potentially access yours then I'd bounce the query on to said company and ask if they're maintaing the list properly.

[purplecat]

NB. I am not a Lawyer, nor a software auditor.

[philmophlegm.livejournal.com]

Surely the absence of the correct answer on the form means that the form is wrong!

[king-pellinor.livejournal.com]

Yeah, right, like I'm going to tell them that! This is Corporate we're talking about!

[philmophlegm.livejournal.com]

"...unless they belive that said particular people should have developer access, in which case you are doomed."

Probably not (see below). I think they are most likely addressing the risk that some unqualified fiddler can come in and make uncontrolled changes to an installed system. For example if the system produces a key report, can anyone get in and fiddle with it so that the report no longer includes a certain category.

[bunn.livejournal.com]

Can you get the third party developer to tick the box?

(Mind, you, if I were the third party I'd be bloody reluctant to accept that particular poisoned chalice, carrying, as it does, an air of expensive legal things hidden like the Kings Shilling at the bottom.)

[philmophlegm.livejournal.com]

That sort of relationship may be built into the third party's SLA. (External) auditors won't contact a third party without permission from their client, but they may well ask for this if it is a key system.

[king-pellinor.livejournal.com]

I've gone back to them now and said "Yes, yes, we're compliant, nothing to see here", and ticked the boxes.

This is mostly because I noticed that they want a response by tomorrow, and buying the company and getting all the development work done by then might be awkward. Buying the company yes, but getting developers to do anything to timetable is never going to fly :-)

[philmophlegm.livejournal.com]

Someone asks an auditing AKICOLJ for the first (and probably last) time ever, and I miss it.

Are these internal or external auditors?


I think I can see what they're getting at here. Stuff like controls over the development of and changes to IT applications and access to those applications and the wider IT environment comes under the heading of 'General IT Controls' (or alternatively 'IT General Controls').

When auditing, we auditors will usually prefer to rely on a company's internal controls to some extent, because by doing so, we can reduce the level of detailed substantive testing. (Example: We want to test that additions to fixed assets actually exist and are proper business expenses that should have been included in fixed assets and not charged against profits immediately. We will probably pick a mathematical sample (using monetary unit sampling) of those additions, but if we are able to rely on an internal control (say something like all fixed asset additions have to be approved and documented by the financial controller), then that sample can be reduced.

To be able to rely on a control, the auditor has to test that control's design and implementation (this is often done by walking through a sample transaction, recording the controls along the way and considering if those controls were working effectively, would they mitigate the risk of misstatement through fraud or error). If the control is properly designed and implemented, then its operating effectiveness must be tested.

For manual controls (like the financial controller approving fixed asset additions), this would be done with a sample test, where the size of the sample depends upon the frequency of the control and the risk of failure. For automated controls (sometimes called 'application controls'), a sample size of 1 is usually sufficient if you are confident that the general IT controls are effective. A properly implemented accounts package (or 'Enterprise Resource Planning' package for the grander ones) should work as well on the millionth transaction as on the first if you are confident that only people who should be are messing around in it and that the correct checks were made when it was installed and tailored. Hence the need for your auditors to check general IT controls.


You mentioned that this particular application was developed by a third party and that you have no developer access at all. It may be that the auditors don't know that. You should supply them with details of the third party. If these are external auditors we are talking about and this is a key system then it may well be that they will need to rely on controls at the third party. This is often done by simply reviewing that third party's SAS 70* report (a report on the third party's own controls that would be issued independently (probably by their own auditors)). Your auditors would probably also want to review the Service Level Agreement you have with them.




* Statement of Auditing Standards no. 70 - Service Organisations, issued by the Auditing Standards Board of the American** Institute of Certified Public Accountants.

** A rare example in auditing of the American standard being the globally accepted one.

[king-pellinor.livejournal.com]

I don't think the auditors care :-)

As far as I can tell, someone once thought the application needed to come under this set of controls, and so it's now on the list of things controlled. Looking at the criteria it probably shouldn't be in the regime at all, but obviously it must need to be as otherwise it wouldn't be - QED ;-)

Frankly the risk is pretty much nil, but HAL is very fond of process and box-ticking, so I think we're stuck with it :-)

My main worry is that someone has suggested that the group tax accounting summary spreadsheet I've put together for internal reporting purposes comes under the same rules... I really need to resist that :-D

[philmophlegm.livejournal.com]

"My main worry is that someone has suggested that the group tax accounting summary spreadsheet I've put together for internal reporting purposes comes under the same rules... I really need to resist that :-D"


Ah. Now that is what we auditors refer to as "end-user computing". We consider that sort of thing to be higher risk than a report automatically generated by the system because of the risk that incompetent tax accountants from some small island can't make a spreadsheet that adds up properly...

(Don't be offended if they want to check it more rigorously!)

[king-pellinor.livejournal.com]

Well, that one gets externally audited, so the IT controls are arguably unnecessary :-)

Not that the external auditors understand it, of course ;-) They're very good at picking away at small numbers, but the big ones just go right over their heads. Well, if they were any good they'd be in industry rather than stuck in the Big 4.

[philmophlegm.livejournal.com]

Don't expect Big 4 auditors to understand tax!

[king-pellinor.livejournal.com]

I don't expect Big 4 auditors to understand anything :-)

That's why I talk slowly and reassuringly to them, without pausing to let them ask questions... ;-)

[philmophlegm.livejournal.com]

To be fair, so do I...

[philmophlegm.livejournal.com]

Of course, your company is also (I imagine) what is called a 'substantial role' affiliate / subsidiary of an SEC-listed company. That means the external auditors also have to pay a lot more attention to internal controls than they otherwise would have to because of the provisions of the Sarbanes-Oxley Act (s404) brought in in the US in the wake of the Enron thing. This means that auditors have to report explicitly on internal controls over financial freporting ('ICOFR') rather than simply testing those controls as part of their work to report on the truth and fairness of the financial statements.

SOx 404 work is absolutely not-my-subject. I did a course many years ago, and turned down a promotion* that would have involved doing a lot of this work several years back, but since then I've not had any involvement with it.



* Mostly because it would have involved moving to Reading.