what you require in an audit normally

[Ramkumar Devanathan]

Hi all,

1. what do sys ad's like to have ready for an audit? what information, what reports, etc.

2. how do you feel distributed computing systems like OV (+SPI's) would help here?

of course this being a sys ad forum, impetus is more on the first question.

- ramd.

[Brian Bergstrand · Accepted solution]

Alcohol, and lots of it.

Seriously (for a start):

-All system logs for the covered period. Including wtmp/btmp, and su's.
-A list of all changes made to the system, and who made them. This would cover system patches and other software installs; as well as configuration changes.
-Deleted/disabled accounts.
-Performance stats from sar/measureware.
-A whole lot of other things I can't remember right now.

If OV could log all of this, that would be great!

[Kent Ostby]

Some other questions that are likely to come up would include:

a) What is your password scheme on the machine with regards to the kinds of passwords accepted (special characters, length) as well as how often you force users to change passwords.

b) storage of backup tapes (is there offsite storage for say a monthly with dailies kept onsite ) ?

c) what kind of testing of your backup tapes have you done to see if they are valid ?

d) Are there any modems configured on the system ? If so, what types of security is in place for modem access.

[Jean-Luc Oudart]

- Your security policy
- Its implementation
- Its monitoring

- DR plan , test and report

Rgds,
Jean-Luc

[Chris Wilshaw]

We get an annual visit from the audit-vampires.

What do they want? A close encounter with an industrial grinder would be a start.

Seriously though, we're asked to prove that we're monitoring a number of security aspects.

- last login details
- failed login attempts
- invalid accounts (local admin people tend to improvise on the format from time to time).
- valid/invalid uses of su
- backup/recovery strategies
- general security policy (access authorisation, processing of new ID requests, password policy)

Our last review prompted the setting up of weekly/monthly reports to show much of the above.

Hopefully, I've taken it a step further by cross referencing a list of company leavers to the ID's set up at each location, so that the local admins can then tidy up old ID's promptly.

There's also a couple of other changes that I plan to make in advance of their next visit (in a few months time) - then it's just a case of hoping that they don't come up with something else.

[Chris Vail]

We haven't been through an audit except where the auditors have a pre-defined list of things they want to see. If they don't have such a list, they're not worth the money they're being paid.

Mostly, they've been interested in the written security policies, and whether/how these have been implemented. Also, they're pretty good at telling us what we need to pass the audit, and then criticising/reviewing intermediate steps along the way.

For example, their initial requirement was for limiting access to specific hosts. Our developers had been making SQL connections between a development system and the production database. This was (and still is) non-standard. But the developers presented a good business case for this practice to continue, so the auditors accepted this.

Usually, the audit is a positive experience. I think of it as a scorecard, with opportunity to improve. Certainly, the efforts made showed up in my annual review.


Chris

[John Bolene]

we lock down our systems at the start and only those allowed on can get on after that

passwords expire after 30 days (not 35 as we would like to allow monthly changes)

passwords must be 6 to 12 in length, must contain at least one letter and one number, and cannot contain the words from the dictionary

services disabled include ftp, telnet, and all remote commands

ssh and sftp must be used for access

SEOS from CA is used on all machines, this allows designated users to sesu to root to do what they need, this product also logs EVERYTHING that you do in audit trails only accessable by the SEOS admins (not even root can get to them)

So, in our case, SPI's will not help.

[W.C. Epperson]

Around here, they're also very interested in file permissions, particularly world writeable, group writeable, and suid stuff. We always review a list of those for anything we can't readily justify.

Generally, we find that starting by installing Bastille gets us off the hook for most promiscuities--those of the servers, anyway. ;)

What distributed stuff we do is largely cron jobs emailing checksums, configuration details, etc., to a central sysadmin server (which also runs Big Brother network monitor).

[Zigor Buruaga]

Hi,

- Can't log on the systems directly as root ( but console ).
- Security policies ( expire 30 days, cycle passwords, not null password, etc )
- Storage of backup tapes out of the computer room.
- If the existing defined users still have a reason to "live".
- Computer room conditions ( not near to bathrooms, temperature is OK, fire alarms, etc ).
- Monitoring/reporting of system status.
- Changes made to the system, who, why, when ...
- Permissions and who has access to command line.
- Of course, those "fantastic and unreal and abstract and ..." disaster recovery plans.

And several things more, some already mentioned here, and others that I don't want to remember.

Hope this helps.
Regards,
Zigor

[Keith Bevan_1]

Auditors - welcomed with as much enthusiasm as a person with flatulence in a crowded lift/elevator.

Only joking !

1) Company policy & Documentary evidence for Invocation and Recovery from a Disaster.

2) System documentation to support current installation & configuration.

3) Company security policy and documentary evidence to support regular security review.

4) Role seperation and segregation of duties and responsibilities.

5) Server room and system access restrictions and monitoring.

6) System log file reviews.

7) Change control documentation.

8) Backup Cycle and storage (including off site).

9) Review of outstanding issues from previous Audits (if any !).

Certainly not an exhaustive list of our annual IT Audit.

Keith

[Mike Fisher_5]

Ramkumar
No points please

An interesting thread & I dig your personal quote

My observations...

1] Documentation:
Proofread carefully to see if you any words out

2] Philosophy:
The old standby if you've got to talk your way out of trouble
'Make it idiot proof and someone will make a better idiot'

[John Meissner]

All our audits are done by an external company. They send us a script to run that gathers A LOT of information on the server in question. After the script runs they take the information and put together a report for us. They then sit down with us and go over it and show us what our good/bad/ugly aspects are. we correct some of the issues brought up and some of them we decide are "acceptable" risks.

To prepare for this is part of our every day job. We make sure out patch bundle strategy is implemented on all servers and that our security practices are followed. sometimes we miss something and that's the whole point of having an audit.