1 2 Security Audit Issues The Audit example essay topic

The University of Melbourne 615-667 E-Commerce Security Semester 1, 2003 Project 2: Information Security Audit of the Department of Information Systems - Report- Sebastian Wie mann Student No 172372 June 1st, 2003 TABLE OF CONTENTS EXECUTIVE SUMMARY 3 PART I! V REPORT DETAILS 1 Audit Characteristics 4 1.1 Security Audit Objectives 4 1.2 Security Audit Issues 5 1.3 Scope 7 2 Evaluation of Controls 8 2.1 Access Control 8 2.1. 1 Physical access control 8 2.1. 2 Logical access control 8 2.1. 3 Access Monitoring 9 2.1. 4 Investigation of suspicious access 10 2.2 Application Software Development and Change Control 10 2.3 System Software Control 10 2.3.

1 Limiting access to system software 11 2.3. 2 Identification and control of access paths 11 2.3. 3 Review of system software installations 12 2.4 Additional Computer Security 12 2.5 Service Continuity 13 2.5. 1 Data and Backup procedures 13 2.5.

2 Environmental controls 14 2.5. 3 Effective software and hardware maintenance 14 2.5. 4 Contingency plan 14 2.6 Anti-Virus Controls 14 2.7 Application Control 15 2.7. 1 Application updates 15 2.7. 2 Configuration of applications 15 PART II! V CONCLUSION AND RECOMMENDATIONS 1 Conclusion 17 2 Recommendations 17 BIBLIOGRAPHY!

K! K... ! K! K! K! K!

K! K! K! K!

K! K! K! K! K! K!

K! K! K! K!

K! K! K! K! K! K!

K! K! K! K! K 19 EXECUTIVE SUMMARY As part of the subject! SSe Commerce Security!" at the Department of Information Systems of the Uni-versity of Melbourne, an information security audit of the department's postgraduate support IT in-fra structure was conducted in semester 1, 2003.

Preparing the audit, detailed information about the audit goals and issues involved had to be retrieved from a variety of sources. These are presented in! SSI. 1 Audit Characteristics!" . The audit objectives relevant for this assignment are to evaluate the ef-fictiveness and the compliance of existing controls and to give recommendations for improvement to the management. Therefore, the DIS security policy served as the basis for the audit.

The controls examined involved physical and logical access controls, system software and applica-tion controls, computer security controls, anti-virus mechanisms and service continuity. The results of the analysis are presented in!" I. 2 Evaluation of Controls!" . As the audit had to be conducted with limited resources, several assumptions had to be made and certain controls could not be audited completely. Nevertheless, the evaluation revealed the DIS security level to be high as it makes effective use of a variety of security features with high expertise. There is, however, room for improvement as several major weaknesses were detected. These weaknesses involve mainly procedures that need to be en-forced stronger as well as human behaviour that needs to be changed by training or awareness pro-grams.

PART I! V REPORT DETAILS 1 Audit Characteristics 1.1 Security Audit Objectives Research material about information security audits (in the following just! SS audits!" ) was derived from the following types of sources: "X Computer and information security organizations (CERI AS, SANS) "X Information security auditing organizations (ISACA) "X Internal auditing and accounting organizations (IIA, GAO) "X Knowledge bases regarding IT, information systems, information security "X Governments. The security audit objectives will be explained in the following: Initially there is risk. Concluding the risk assessment, the organization sets down standards as part of their security policy to address the risks.

The existing controls are the result of implementing the standards. Now, the maximum scope of an audit includes all three elements: First, it examines if the last risk assessment is up-to-date and how risks have changed. Then, it evaluates if the standards are still adequate to address the present or changed risks (review of policy). This is why KAPP (2000, p. 1) characterize an audit as!

SS policy-based!" which is confirmed by GAO (2001 a). Going further, it ex-amines if the existing controls still fulfil the present or changed standards and requirements. Thus, the audit's goals are: "X To re-assess risks which provides! Scan idea of the potential damage!" (KAPP 2000, p. 1) "X To give recommendations for establishing / improving policies, standards and procedures "X To evaluate the compliance of present controls and their effectiveness "X To give recommendations on how to improve the existing controls. In contrast, the minimum scope of an audit assumes that the risks have not changed and the stan-dards are still adequate to control the risks. Thus, the audit will not re-evaluate the policy and stan-dards.

It will focus the evaluation of the current implementation of controls and if they comply with the standards. The goals of this audit are solely the last two points mentioned above. The type of audit conducted in this paper is close to the minimum audit, since the first assignment already covered risk assessment and policy evaluation in detail. The relevant goals for this paper are the actual evaluation of controls and to give recommendations. However, at some points it cannot be avoided to also evaluate the existing standards. Possible target groups of an audit can be management, legal bodies, other auditors or the public.

An information security audit can either be carried out as a single audit or as part of another audit (i.e. financial audit). For this report, we conducted a single information security audit directed at the management. The sources mentioned above have been experienced to publish two different types of audit re-sources: Evaluation manuals explain in detail how the different types of controls have to be exam-ined, i.e. the Federal Information System Controls Audit Manual (FISCAM) by the U.S. General Accounting Office. Audit guides, in contrast, explain the whole audit process from a broader per-spec tive.

In these audit guides, different sources emphasize different goals. Governmental and public institutions usually stress the goal of compliance evaluation and effi-ciency judgement in their audit guides, as i.e. the Treasury Board of Canada (TBoC 2002) and the University of Illinois (2001). This is because public authorities rely heavily on formal coordination by written rules. Thus, for them the most interesting aspect of an audit is to find out if these rules are followed correctly. In contrast, IS research institutions focus the goal of giving recommendations to management. They explain the whole audit process including how to collect necessary data.

Particularly, they do not stress the goal of risk assessment as this has become a separate discipline in information security. Examples are The Institute of Internal Auditors (OLIPHANT 1998/99) and ITP Journals (KAPP 2000). 1.2 Security Audit Issues The audit conducted for the Department of Information Systems covered the following issues: "X Access Control "X Application Software Development and Change Control "X System Software Control "X Additional Computer Security "X Anti-Virus Control "X Service Continuity "X Application Control The issues marked with! SS !" follow the FISCAM (GAO 2001 a).

The FISCAM category! egrega-tion of duties!" was not covered though, as it would have required examining the department's or-ganizational structure in too much detail as impossible within the time restrictions. The FISCAM category! SSEntitywide Security Program Planning and Management!" basically refers to policy re-view which was already covered in the first assignment and was thus left out. The FISCAM suggests the division of controls in general controls and application controls. The first six categories mentioned above refer to general controls. As part of application controls, MS Inter-net Explorer and MS Office (in particular MS Outlook) were the relevant applications for this audit, as these are the most targeted applications by viruses.

They are also the most used applications by DIS students. The audit assignment demands to identify the top five issues of Windows Security. These have been identified with the help of SANS (2003), MICROSOFT (2002) and OLIPHANT (1998/99): "X Policy and account setup "X File system access control "X Network configuration vulnerabilities (NetBIOS shares, null sessions) "X MS Internet Explorer & Outlook security "X System services Policy and account configuration is where all regulations for password authentication originate. Password authentication is the basis of windows security. It is examined in the section!

SS 2.1 Access control!" . Unfortunately, an in-depth analysis of the policy and account configuration at the DIS re-quires administrative privileges and could not be done in this audit. Files are the elementary pieces of data that all applications, the operating system and user data itself are built of. Thus file system access control is discussed in the section! SS 2.3 System Software Con-trol!" . Network vulnerabilities allow hackers and malicious code access to system files and user data.

They are also covered in the same section. As mentioned before, Internet Explorer and Out-look are the most exploited software by viruses and are examined in! SS 2.7 Application Control!" . Most sources mention Windows services as an important backdoor for attackers that needs to be taken care of, they are discussed as part of the system software. 1.3 Scope The! SS postgraduate support IT infrastructure!" (see assignment) includes all hardware installed in the DIS postgraduate working area on second floor of the ICT building plus all software stored on PC hard drives in that area.

It includes the DIS servers that store the student data plus the technical area on sixth floor of the ICT building. Student data is seen to be stored only on the servers. Relevant user groups are technical staff and students. The infrastructure also includes all support processes (i.e. helpdesk activities). Basis of the audit is the DIS security policy available under: web. The PCs audited are PC number 6 in lab 2.30 and PC number 1 in room 2.27.

To log on the machines, the auditor would use only his postgraduate student user account. Audit actions that endanger system or human security were not performed. Also audit actions requiring documentation of tech staff procedures or previous security incidents were not performed, assumptions were made. 2 Evaluation of Controls 2.1 Access Control Standards about access control are set down in the DIS security policy. Their effectiveness as well as compliance of users and technology are verified here. 2.1. 1 Physical access control The policy states physical access control to the postgraduate area to be based on access card and an alarm system.

The access card is needed for entering the building and the postgraduate area after-hours. The technology has proven to be reliable and working as the auditor has entered these areas using his access card after-hours nearly daily during this semester. On 25/05 at 10 pm, an attempt to enter the building and the postgraduate area without using the access card was unsuccessful. Nevertheless, regular observation of students has proven that user compliance with the DIS security policy is low, as authorized students commonly let strangers enter the building after-hours without access card. This heavily reduces the effectiveness of the control. Giving out the access card is based on student ID and is done face-to-face by an administration staff member.

The administrator verifies the student ID and enrolment record in the DIS database cor-rectly as observed on 12/04. Thus, the procedure granting the access privileges is secure. All computers in the postgraduate labs are protected by an alarm cable system and padlocks. As the auditor had no access to records about theft incidents, this feature has to be assumed to be effective. Postgraduate labs are protected by door alarm. This feature cannot be audited without triggering the alarm and is assumed to be secure.

Server rooms are protected physically by door alarm and access card which exclusively allows in technical staff. Students can only enter if tech staff lets them in after ringing the bell. An auditor's attempt to enter the tech rooms on 25/05 at 5: 45 pm proved these security features to be effective. The tech staff member opening the door also followed his duties to well supervise the visiting audi-tor while moving through the tech rooms. 2.1. 2 Logical access control Logical access control is done via Windows 2000 password-based features. First, lab PCs are protected by password authentication.

An attempt to log on both audited PCs on 31/05 at 5 pm with guessed passwords failed. However, users leaving workstations unattended and unlocked result in low effectiveness of access control as observed daily by the auditor during this semester. Countermeasures against this behav-i our are lab patrols. An unlocked and unattended computer in use will be logged off during a lab patrol and the account suspended. These procedures are carried out reliably by helpdesk staff during business hours: On 13/04 the auditor's account was suspended and required seeing tech staff for re-enabling. After-hours though, helpdesk staff is not present, the procedures are not carried out.

Stu-dents leave their machines unlocked regularly. Second, students! | data files are protected. The attempt to access another student's data folder in the network directory! SS disrepute!" using both PCs on 01/06 at 12: 30 am failed. The auditor's own home drive was accessible. There is a password management system enforcing regular change of passwords and a syntax hard to guess.

User compliance with the password management standards is high as they are imple-mented in the operating system and cannot be overridden by users. An auditor's attempt on 31/05 at 5: 30 pm to change his password a way that it does not meet the standards was rejected by the sys-tem. According to the DIS security policy, a wrong password entered five times will result in dis-a bling the account and will require helpdesk attention. This procedure was carried out correctly on 25/05 at 1 pm after the auditor entered a wrong password five times. However, user compliance regarding responsible treatment of passwords is low: Users share pass-words regularly or write them down. Hence, effectiveness of logical access control is strongly im-paired.

Risk is high: An intruder using a student's password could hardly be detected and causing damage would be much easier with students! | access privileges. Next, it has to be examined how access privileges are granted in the first place. A student's account is created automatically if a student is enrolled in one or more IS subjects. It is activated after sign-ing the lab declaration form in person in front of helpdesk staff who additionally checks student ID. This procedure is carried out reliably by helpdesk staff as perceived by the auditor during orient a-tion of this semester. 2.1. 3 Access Monitoring Physical access: Building entrance, postgraduate area corridor and labs are under video surveil-lance.

The DIS security policy does not state if and how recordings are actually reviewed by staff members on a periodical basis. This is appropriate as the policy must not give students more infor-mation on how they are monitored, this would lower effectiveness. But it also means, that the moni-to ring procedures cannot be further audited here. Logical Access: All log ons and log offs are recorded. This is confirmed by a conversation between the auditor and a tech staff member regarding a lab violation on 01/05 (the tech staff member was not approached because of this assignment but because of personal issues). Thus, the DIS security policy has been implemented correctly. 2.1.

4 Investigation of suspicious access The DIS security policy assigns the responsibility for this task to technical service. To examine compliance, security would have to be violated on purpose which cannot be done within this audit. 2.2 Application Software Development and Change Control As part of this topic, the FISCAM mentions proper authorization of processing features and pro-gram modifications as critical element. Section 7 of the DIS security policy addresses this element by assigning responsibility for authorizing and installing software on DIS resources to academic staff and network administrators. The audited PCs are not compliant with this standard. On 31/05 at 2 am, the auditor could install ICQ lite without any problems on both PCs and uninstalled it again.

The feature! SS Add / Remove Pro-grams!" of the Windows Control Panel allows every program to be installed and uninstalled. It has been observed by the auditor several times during this semester that postgraduate students work with their own software which is not being periodically checked and removed by staff although it is demanded by DIS security policy. During this semester, the auditor has not observed any!

SS periodic scans!" for software. 2.3 System Software Control The system software is the Windows 2000 operating systems and all hardware / network related soft-ware. The FISCAM recommends certain critical elements to be examined to evaluate the system software controls. The following critical elements were audited on 01/06 between 2-5 pm on both PCs. 2.3.

1 Limiting access to system software Ways to access the system software consist of provided operating system tools (Control Panel, Reg-is try Editor) and direct access to the file system. The functionality of the Windows Control Panel was successfully restricted on both PCs, in particu-lar of the sections Administrative Tools, Network and Dial-Up Connections, Users and Passwords, and System Device Manager. Within the section to Add / Remove Programs, the functionality of adding / removing Windows components was blocked. Furthermore, the Windows Registry Editor could not be run by the auditor on any machine. To secure the file system, Windows 2000 offers sophisticated logical access control based on the user's authentication during log on.

MICROSOFT (2002, p. 90) gives recommendations on how to use this feature and which files and directories to protect. It was examined how far the configuration of the file access control on both PCs meets these recommendations. The critical files and directories can be grouped as follows: "X The WINNT directory and Windows system directories "X The Documents and Settings directory "X Initialization files in the root directory (i.e. config. sys, auto exec. bat) "X The root directory of the system drive It was found that the first two groups were protected as recommended, access for non-administrators was mostly restricted to listing files, or access was completely denied. However, ac-cess to initialization files in the root revealed to be almost not regulated. A student can even change security settings for these files. There is no access control configured for the system drive (C: ) and its root directory.

Settings allow full access to the! SS Everyone!" account. Students can change security settings. This configuration does not enforce the DIS policy forbidding students to leave / edit files on local disks. Thus, users commonly violate this policy and store own files on local disks. These results are identical for both PCs. 2.3.

2 Identification and control of access paths Next to the common paths to access the system software mentioned in the previous sections, there are several backdoors known to exist in Windows systems. Stanford University (2002) recommends disabling the guest account. An attempt to log on as! SS guest!" on both computers failed, the account is disabled.

SANS (2003) mentions networking shares based on NetBIOS as one of the most exploited vuln er-abilities. The Gibson Research Corporation offers an online service to check if NetBIOS is enabled on a particular machine (web). On both machines, NetBIOS was re-ported to be inactive. Furthermore, so-called null sessions (or anonymous log-ons) are mentioned in the SANS Top Twenty Most Critical Internet Vulnerabilities List (SANS 2003). These are used by the SYSTEM account to communicate but can be exploited by attackers. The existence of the vulnerability can be checked using the!

SS net use!" command with certain parameters. This command was used on PC #13 in lab 2.30 to open a null session to both audited PCs. This worked for PC #6 in lab 2.30 which in-dictated vulnerability, and failed for PC #1 in lab 2.27. SANS (2003) recommends to set a specific registry key to reduce the access privileges for the anonymous account. However, the auditor could not access the registry editor to verify the current key settings.

Next, system services are an important issue mentioned by MICROSOFT (2002), MICROSOFT (2003), and STANFORD UNIVERSITY (2003). Using the Windows System Information Utility, all services running on both PCs were listed and compared to the recommended services by MICROSOFT (2003) for running on secure machines. A variety of services was found to be running which are not rec-omm ended. These include: Application Manager, Clip Book, Machine Debug Manager, Netmeeting Remote Desktop, Distributed Transaction Coordinator, Windows Installer, Network DDE, Remote Access services, Remote Registry Service and Telnet. Some of these are even explicitly recom-mended to be disabled by STANFORD UNIVERSITY (2003), i.e. Remote Registry Service.

An analysis of every service though would require advanced Windows 2000 technical know-how and exceeds the scope of the audit. It is recommended that technical staff reviews the running services. 2.3. 3 Review of system software installations This criterion basically refers to keep system software up-to-date. Windows 2000 was found to be installed with Service Pack 3 on both PCs which is the latest update published by Microsoft.

2.4 Additional Computer Security Microsoft's Windows 2000 Security Configuration Guide (MICROSOFT 2002) mentions several ba-sic measures to secure a computer. Without these, many of the security features examined in the previous sections could be easily overridden. First feature is a power-on hardware password set up in the BIOS. None of the audited PCs ask for a password to boot. This feature however, would highly lower usability as students cannot be ex-pected to remember different power-on passwords for many PCs. In turn, a single power-on pass-word for all PCs would provide no security as an intruder could easily find it out by asking.

Second, accessing the BIOS setup should be password protected. None of the audited PCs asked for such a password, the auditor could edit and save BIOS settings on 01/06 at 2 pm on both machines. This protection is highly recommendable as students can cause damage by changing BIOS settings, or intruders can change boot sequence. Third, disk and CD drives installed in all PCs cause high risk of introducing malicious code. No drives are secured by locks. Furthermore, a secure PC must not boot from any other device than hard disk.

Booting from a user's disks or CD is enabled by BIOS settings on both audited PCs and offers chances for intruders to override operating systems security. Both audited PCs had functional power and reset switches which allow the user to reboot the PC and eventually override security mechanisms. In addition, plugs and connections could be protected. The audited PCs do not have any protection of plugs (serial, parallel, USB, network etc. ). Devices can be freely connected and disconnected.

There is no protection of network plugs in any labs. A! SS secure pipe with no danger of unauthorized rewiring!" (SOBOL AND LAMASTER 2002, p. 10) is not present. Finally, the hard disk configuration is relevant: MICROSOFT (2003) suggests all partitions to be NTFS and no second operating system to be installed. Both audited PCs meet these requirements as they have only one partition which is NTFS formatted. 2.5 Service Continuity 2.5.

1 Data and Backup procedures The DIS policy states that backups are made for the case of a server failure. It also includes periodic tests to ensure that methods of data storage and retrieval are appropriate. It thus addresses the two most critical elements of backup plans: storage site and testing. It would exceed the time limit of this assignment to verify compliance of technical staff actions with this pol-icy and actually perform tests of backup media. 2.5.

2 Environmental controls Smoke detectors and sprinklers are present in the whole postgraduate working area. Procedures for the case of fire are in place as required by the DIS policy. The procedures can be read on the DIS web site and printouts are attached in lifts and corridors. Verifying the reliability of detectors and sprinklers would exceed the time limit of this assignment. They are assumed to work properly. Since lab PCs just contain installed software products and no student data, water sprinklers do not harm information assets there.

Thus, sprinklers are appropriate for labs. The auditor did not have sufficient access to the server rooms to check their fire controls though. A critical point would be the presence of carbon dioxide fire extinguishers as water sprinklers would damage the server hardware and thus the student data stored on them. 2.5. 3 Effective software and hardware maintenance Helpdesk and tech services are effective and accessible.

Faulty computers can be reported to the e-mail address. The auditor's damaged Outlook profile (a routine problem) could be successfully solved by helpdesk staff on 26/05 within 15 minutes. Among 34 PCs located in labs 2.30 and 2.29 on 01/06 at 2 pm, only one was marked to be! S Sout of service!" . Maintenance of server hardware seems effective as the auditor has not yet experienced downtime's during this semester. 2.5. 4 Contingency plan According to the DIS security policy, contingency plans have been established.

Due to time limits, it could not be audited how well these are documented, kept up to date and whether staff is trained. It should be reviewed by staff. 2.6 Anti-Virus Controls Anti-virus software is installed on both PCs. The user can either run the program from the Start menu or from a drop down menu in the Windows Explorer.

It is also integrated in the MS Outlook pull-down menu. Therefore, access to the software can be evaluated convenient for the user and in-creases likelihood that the software is actually used. Furthermore, the background scanner is permanently running and provides system scan, e-mail scan, download scan and internet filter. It cannot be disabled by the user. In addition, the user can-not change configuration. (This is also why the auditor could not examine configuration settings.) The virus data file is dated 28/05/2003, which is the latest available for that particular software.

However, the McAfee Scan Engine version 4.5. 1 is dated 2001. The current version of the McAfee Scan Engine is 7.0. Thus, the anti-virus software is not fully compliant with DIS security policy that demands a! Secur-rent!" software. The policy also demands users to scan files downloaded from the internet which is usually not done by users as observed by the auditor during this semester.

2.7 Application Control The applications examined were Microsoft Office (in particular Microsoft Outlook) and the Micro-soft Internet Explorer. They were audited on 02/06 at 11 am. The results are identical on both PCs. 2.7. 1 Application updates Updating application software is the most effective way to close known backdoors due to pro-g ramming errors and was therefore audited.

Microsoft's service for checking Office Product Up-dates (web) was used to determine the update status of MS Office on both PCs. It revealed that no available update issued after October 16th, 2002 was installed on any machine. This includes MS Office Service Pack 2 and an MS Out-look security patch. MS Internet Explorer 6 was installed with Service Pack 1 on both PCs and was therefore up-to-date. 2.7. 2 Configuration of applications The issues covered in this section were inspired by Microsoft's Office XP Security White Paper (MICROSOFT 2001) and GRANNEMANN (2002). Results on both PCs were identical.

"X Macro Security A large number of viruses are coded as MS Word macro and distributed as part of documents. MS Word! yens macro security settings were set to! SSHigh!" on both PCs which is appropriate. An attempt to run a macro from an untrusted source failed, the feature was effective.

"X ActiveX and ActiveScripting Viruses and worms are often coded or spread using these technologies. For the Internet Explorer, the security settings regarding the zone! SSInternet!" are the most relevant since most pages accessed by students fall within this zone. Looking at the internet options, ActiveX security is evaluated high as all ActiveX elements are required to be either marked safe or signed to run. All other ActiveX elements are disabled. ActiveScripting is turned on for the zone!

SSInternet!" which is a security hole. For MS Outlook, the zone! SSRestricted sites!" is relevant. The security level for this zone is! SSHigh!" by default which provides maximum security level.

"X Security Zones The Internet Explorer was not using the security zone feature. The category! SS Trusted Sites!" and! SSRestricted Sites!" were empty.

Thus, all web browsing would be done in the zone! SSInternet!" . MS Outlook used the zone feature correctly as! SSRestricted Sites!" is the default zone for MS Out-look.

"X MS Outlook Attachment Security This feature was turned on in Microsoft Outlook and worked correctly. Access to an executable file attachment received on 02/06 at 7 pm was blocked. PART II! V CONCLUSION AND RECOMMENDATIONS 1 Conclusion Concluding the detailed evaluation, we summarize it to articulate the overall security level. The controls can be judged from two sides: From the technological side and the user / staff behaviour perspective.

From the technological side, the first stage of security is the use of the very basic technological fea-tures (i.e. file access control and anti-virus software). A more advanced stage of security is reached if these features are configured with high expertise and also less obvious security holes are man-aged. Almost all control categories examined above use the basic technological features and most of them even show advanced configuration (i.e. disabling NetBIOS or configuring the virus scanner so it cannot be disabled by students). Just the control category! SS Additional Computer Security!" does not even use the very basic security mechanisms (i.e. locks for plugs or a BIOS password). Positive to remark is that the results on both PCs were identical which indicates that procedures are carried out consistently.

From the user / staff behaviour side, we find several severe non-compliance. These regard students! | treatment of passwords and insecure files, as well as staff not sufficiently monitoring students tam-peeing with PCs (i.e. installing software). Thus, the high level of security that is established by well-deployed technical controls is lowered heavily by incompliant behaviour. 2 Recommendations The following recommendations are given for the control categories.

Most of them regard behav-io ural aspects and can be implemented at low costs. "X To enhance physical security: Students should be made aware of responsible treatment of their access card privileges via educa-tion or awareness programs. Incompliant behaviour at building entrances must be penalised to enforce physical security. This could be done as follows: Periodically, random video recordings of the entrance will be reviewed. Students who are seen to let in unauthorized persons will be identified, and their access privileges suspended. "X To enhance password security: Students should be educated in responsible treatment of passwords.

Penalties and lab patrols to de-tech irresponsible use (i.e. leaving PCs unlocked and unattended) should be continued as before to enforce compliance. "X To enhance system software security: File access for students should be restricted stronger (i.e. for root drives) which would also support the DIS policy of not allowing students to install software. The frequency of checking PCs whether they have been manipulated by students (i.e. by software installation) has to be increased. Certain network vulnerabilities have to be reviewed in more detail: These are running services and null-sessions.

The adequate registry key (see SANS 2003) has to be set to protect against null ses-sions. "X To enhance additional computer security: As it is important for students to use own disks for backups and CDs for project files, disk drive and CD should not be restricted in spite of security concerns. However, the BIOS setup has to be pro-tested by password and the boot sequence limited to the hard disk. Ideally, reset and power switches should be disabled or locked.

Due to high costs of adapting the equipment, this feature is valid for new acquisitions of PCs. "X To enhance service continuity: Technical staff has to review if their backup procedures involve testing and a safe storage site as this could not be done by the auditor. Also, contingency plans should be reviewed. Important crite-ria are their adequacy and whether they are kept up to date and communicated well enough. Furthermore, the auditor could not examine the fire controls. Carbon dioxide fire extinguishers should be provided for tech rooms and server rooms.

"X To enhance anti-virus measures: The scan engine should be updated more frequently, and users have to be better educated in the re-spon sible use of insecure files. "X To enhance application security: The latest updates for Microsoft Office should be implemented. The settings for MS Outlook pro-vide high security. Internet Explorer reveals medium security level. Thus, administrators should provide a list or criteria for! SSRestricted Sites!" which are known to contain malicious code.

Bibliography

Grannemann, S., 2002.
Securing Outlook, Part One: Initial Configuration [online]. Cupertino (CA, USA): Symantec Corporate Offices. Available from: web [24/05/2003].
Kapp, J., 2000.
How To Conduct A Security Audit [online]. Unknown place: ITP-Journals. Avail-able from web [01/06/2003].
Microsoft Corporation, 2002.
Windows 2000 Security Configuration Guide Version 1.
0 [online]. Redmond (WA, USA): Microsoft Corporation, Corporate Headquarters. Available from: web issues / W 2 kCCSCG / default. asp [01/06/2003].
Microsoft Corporation, 2003.
Windows 2000 Security Hardening Guide Version 1.
2 [online]. Microsoft Corporation, 2001.
Microsoft Office XP Security White Paper [online]. Unknown place of publication. Oliphant, A., 1998/1999.
An Introduction to Computer Auditing Part 1 - 4 [online]. Altamonte Springs (Florida, USA): The Institute of Internal Auditors. Available from: web [25/05/2003].
SANS Institute, 2003.
The Twenty Most Critical Internet Security Vulnerabilities [online]. Bethesda (MD, USA): SANS Institute. Available from: web [25/06/2003].
Sobol, M. ; Hardie, C. ; Lamaster, E., 2002.
The Security Audit. An Introduction and Practical Guide [online]. Carlisle (PA, USA): PestPatrol, Inc. Available from: web PestPatrolAuditorsGuide. pdf [25/05/2003].
Stanford University Information Technology Systems and Services (ITSS), 2003.
Best Practices for Windows 2000 Professional [online].
Stanford University, USA. Treasury Board of Canada (TBoC), 2002.
Information Technology Security! V Audit Guide [online]. Ottawa, Canada. Available from: web [27/05/2003].
University of Illinois, 2001.
Audit Manual [online]. Springfield (USA): Office of University Audits. Available from: web [01/06/2003].
U.S. General Accounting Office (GAO), 2001.
Federal Information System Controls Audit Manual [online]. Washington D.C. Available from: web [28/05/2003].
U.S. General Accounting Office (GAO), 2001 a.
Federal Information Systems Controls Audit Man-ual (FISCAM) [online]. Washington D.C. Available from: web [28/05/2003].
U.S. General Accounting Office (GAO), 2001 b.
Management Planning Guide for Information Sys-tems Security Auditing [online]. Washington D.C. Available from: web [28/05/2003].
Oliphant, A., 1998/1999.