UNIX/LINUX Operating System Security Audit/Assurance Program

ISACA®
With more than 86,000 constituents in more than 160 countries, ISACA (www.isaca.org) is a recognized worldwide
leader in IT governance, control, security and assurance. Founded in 1969, ISACA sponsors international
conferences, publishes the ISACA Journal®, and develops international information systems auditing and control
standards. It also administers the globally respected Certified Information Systems Auditor™ (CISA ®) designation,
earned by more than 60,000 professionals since 1978; the Certified Information Security Manager ® (CISM®)
designation, earned by more than 10,000 professionals since 2002; and the new Certified in the Governance of
Enterprise IT™ (CGEIT™) designation.

Disclaimer
ISACA has designed and created UNIX/LINUX Operating System Security Audit/Assurance Program (the “Work”),
primarily as an informational resource for audit and assurance professionals. ISACA makes no claim that use of any
of the Work will assure a successful outcome. The Work should not be considered inclusive of all proper
information, procedures and tests or exclusive of other information, procedures and tests that are reasonably directed
to obtaining the same results. In determining the propriety of any specific information, procedure or test,
audit/assurance professionals should apply their own professional judgment to the specific circumstances presented
by the particular systems or IT environment.

Reservation of Rights
© 2009 ISACA. All rights reserved. No part of this publication may be used, copied, reproduced, modified,
distributed, displayed, stored in a retrieval system or transmitted in any form by any means (electronic, mechanical,
photocopying, recording or otherwise) without the prior written authorization of ISACA. Reproduction and use of
all or portions of this publication are permitted solely for academic, internal and noncommercial use, and
consulting/advisory engagements, and must include full attribution of the material’s source. No other right or
permission is granted with respect to this work.

ISACA
3701 Algonquin Road, Suite 1010
Rolling Meadows, IL 60008 USA
Phone: +1.847.253.1545
Fax: +1.847.253.1443
E-mail: [email protected]
Web site: www.isaca.org

ISBN 978-1-60420-083-6
UNIX/LINUX Operating System Security Audit/Assurance Program
Printed in the United States of America

© 2009 ISACA. All rights reserved. Page 2

UNIX/LINUX Operating System Security Audit/Assurance Program

ISACA wishes to recognize:

Author
Norm Kelson, CISA, CGEIT, CPA, The Kelson Group, USA

Expert Reviewers
Claudio Cilli, PhD., CISA, CISM, CGEIT, University of Marche, Italy
Jimmy Heschl, CISA, CISM, CGEIT, KPMG, Austria
Shirish Ketkar, BDO Haribhakti Consulting Private Ltd., India
Sanjay Vaid, CISA, Fujitsu Siemens Computers, Belgium

ISACA Board of Directors

Lynn Lawton, CISA, FBCS, FCA, FIIA, KPMG LLP, UK, International President
George Ataya, CISA, CISM, CGEIT, CISSP, ICT Control SA, Belgium, Vice President
Howard Nicholson, CISA, CGEIT, City of Salisbury, Australia, Vice President
Jose Angel Pena Ibarra, CGEIT, Consultoria en Comunicaciones e Info. SA & CV, Mexico, Vice President
Robert E. Stroud, CA Inc., USA, Vice President
Kenneth L. Vander Wal, CISA, CPA, Ernst & Young LLP (retired), USA, Vice President
Frank Yam, CISA, CIA, CCP, CFE, CFSA, FFA, FHKCS, FHKIoD, Focus Strategic Group Inc., Hong Kong, Vice
President
Marios Damianides, CISA, CISM, CA, CPA, Ernst & Young, USA, Past International President
Everett C. Johnson Jr., CPA, Deloitte & Touche LLP (retired), USA, Past International President
Gregory T. Grocholski, CISA, The Dow Chemical Company, USA, Director
Tony Hayes, Queensland Government, Australia, Director
Jo Stewart-Rattray, CISA, CISM, CSEPS, RSM Bird Cameron, Australia, Director

Assurance Committee
Gregory T. Grocholski, CISA, The Dow Chemical Company, USA, Chair
Pippa G. Andrews, CISA, ACA, CIA, Amcor, Australia
Richard Brisebois, CISA, CGA, Office of the Auditor General of Canada, Canada
Sergio Fleginsky, CISA, ICI, Uruguay
Robert Johnson, CISA, CISM, CISSP, Executive Consultant, USA
Anthony P. Noble, CISA, CCP, Viacom Inc., USA
Robert G. Parker, CISA, CA, CMC, FCA, Deloittte & Touche LLP (retired), Canada
Erik Pols, CISA, CISM, Shell International - ITCI, Netherlands
Vatsaraman Venkatakrishnan, CISA, CISM, CGEIT, ACA, Emirates Airlines, UAE

© 2009 ISACA. All rights reserved. Page 3

UNIX/LINUX Operating System Security Audit/Assurance Program

Table of Contents
I. Introduction.......................................................................................................................................4
II. Using This Document........................................................................................................................5
III. Controls Maturity Analysis................................................................................................................8
IV. Assurance and Control Framework....................................................................................................9
V. Executive Summary of Audit/Assurance Focus...............................................................................10
VI. Audit/Assurance Program................................................................................................................13
1. Planning and Scoping the Audit...................................................................................................13
2. Preparatory Steps.........................................................................................................................15
3. Access and Authorization............................................................................................................17
4. Network.......................................................................................................................................28
5. Monitoring and Auditing the System...........................................................................................36
6. Operating System and Application Patches and Configuration Change Management.................40
7. System Backup and Recovery......................................................................................................49
VII. Maturity Assessment.......................................................................................................................52
VIII. Assessment Maturity vs. Target Maturity UNIX/LINUX Only.......................................................56

I. Introduction

Overview
ISACA has developed the IT Assurance FrameworkTM (ITAFTM) as a comprehensive and good-practice-
setting model. ITAF provides standards that are designed to be mandatory, and are the guiding principles
under which the IT audit and assurance profession operates. The guidelines provide information and
direction for the practice of IT audit and assurance. The tools and techniques provide methodologies,
tools and templates to provide direction in the application of IT audit and assurance processes.

Purpose
The audit/assurance program is a tool and template to be used as a roadmap for the completion of a
specific assurance process. The ISACA Assurance Committee has commissioned audit/assurance
programs to be developed for use by IT audit and assurance practitioners. This audit/assurance program is
intended to be utilized by IT audit and assurance professionals with the requisite knowledge of the subject
matter under review, as described in ITAF, section 2200—General Standards. The audit/assurance
programs are part of ITAF, section 4000—IT Assurance Tools and Techniques.

Control Framework
The audit/assurance programs have been developed in alignment with the IT Governance Institute ®
(ITGITM) framework Control Objectives for Information and related Technology (COBIT®)—specifically
COBIT 4.1— using generally applicable and accepted good practices. They reflect ITAF, sections 3400—
IT Management Processes, 3600-IT Audit and Assurance Processes, and 3800—IT Audit and Assurance
Management.

Many organizations have embraced several frameworks at an enterprise level, including the Committee of
Sponsoring Organizations of the Treadway Commission (COSO) Internal Control Framework. The
importance of the control framework has been enhanced due to regulatory requirements by the US
Securities and Exchange Commission (SEC) as directed by the US Sarbanes-Oxley Act of 2002 and
similar legislation in other countries. They seek to integrate control framework elements used by the
general audit/assurance team into the IT audit and assurance framework. Since COSO is widely used, it
has been selected for inclusion in this audit/assurance program. The reviewer may delete or rename these

© 2009 ISACA. All rights reserved. Page 4

UNIX/LINUX Operating System Security Audit/Assurance Program
columns to align with the enterprise’s control framework.

IT Governance, Risk and Control

IT governance, risk and control are critical in the performance of any assurance management process.
Governance of the process under review will be evaluated as part of the policies and management
oversight controls. Risk plays an important role in evaluating what to audit and how management
approaches and manages risk. Both issues will be evaluated as steps in the audit/assurance program.
Controls are the primary evaluation point in the process. The audit/assurance program will identify the
control objectives with steps to determine control design and effectiveness.

Responsibilities of IT Audit and Assurance Professionals

IT audit and assurance professionals are expected to customize this document to the environment in
which they are performing an assurance process. This document is to be used as a review tool and starting
point. It may be modified by the IT audit and assurance professional; it is not intended to be a checklist or
questionnaire. It is assumed that the IT audit and assurance professional holds the Certified Information
Systems Auditor (CISA) designation, or has the necessary subject matter expertise required to conduct the
work and is supervised by a professional with the CISA designation and necessary subject matter
expertise to adequately review the work performed.

II. Using This Document

This audit/assurance program was developed to assist the audit and assurance professional in designing
and executing a review. Details regarding the format and use of the document follow.

Work Program Steps

The first column of the program describes the steps to be performed. The numbering scheme used
provides built-in work paper numbering for ease of cross-reference to the specific work paper for that
section. The physical document was designed in Microsoft ® Word. The IT audit and assurance
professional is encouraged to make modifications to this document to reflect the specific environment
under review.

Step 1. is part of the fact gathering and pre-fieldwork preparation. Because the pre-fieldwork is essential
to a successful and professional review, the steps have been itemized in this plan. The first-level steps,
e.g., 1.1, are in bold type and provide the reviewer with a scope or high-level explanation of the purpose
for the substeps.

Beginning in step 2, the steps associated with the work program are itemized. To simplify the use of the
program, the audit/assurance program describes the audit/assurance objective—the reason for performing
the steps in the topic area. The specific controls follow and are shown in blue type. Each review step is
listed below the control. These steps may include assessing the control design by walking through a
process, interviewing, observing or otherwise verifying the process and the controls that address that
process. In many cases, once the control design has been verified, specific tests need to be performed to
provide assurance that the process associated with the control is being followed. Test objectives are
shown in green type. The specific test process follows the test objective.

The maturity assessment, which is described in more detail later in this document, makes up the last
section of the program.

The audit/assurance plan wrap-up—those processes associated with the completion and review of work
papers, preparation of issues and recommendations, report writing and report clearing—has been

© 2009 ISACA. All rights reserved. Page 5

UNIX/LINUX Operating System Security Audit/Assurance Program
excluded from this document, since it is standard for the audit/assurance function and should be identified
elsewhere in the enterprise’s standards.

COBIT Cross-reference
The COBIT cross-reference provides the audit and assurance professional with the ability to refer to the
specific COBIT control objective that supports the audit/assurance step. The C OBIT control objective
should be identified for each audit/assurance step in the section. Multiple cross-references are not
uncommon. Processes at lower levels in the work program are too granular to be cross-referenced to
COBIT. The audit/assurance program is organized in a manner to facilitate an evaluation through a
structure parallel to the development process. COBIT provides in-depth control objectives and suggested
control practices at each level. As the professional reviews each control, he/she should refer to C OBIT 4.1
or the IT Assurance Guide: Using COBIT for good-practice control guidance.

COSO Components
As noted in the introduction, COSO and similar frameworks have become increasingly popular among
audit and assurance professionals. This ties the assurance work to the enterprise’s control framework.
While the IT audit/assurance function has COBIT as a framework, operational audit and assurance
professionals use the framework established by the enterprise. Since COSO is the most prevalent internal
control framework, it has been included in this document and is a bridge to align IT audit/assurance with
the rest of the audit/assurance function. Many audit/assurance organizations include the COSO control
components within their report and summarize assurance activities to the audit committee of the board of
directors.

For each control, the audit and assurance professional should indicate the COSO component(s) addressed.
It is possible but generally not necessary to extend this analysis to the specific audit step level.

The original COSO internal control framework contained five components. In 2004, COSO was revised
as the Enterprise Risk Management (ERM) Intergrated Framework and extended to eight components.
The primary difference between the two frameworks is the additional focus on ERM and integration into
the business decision model. ERM is in the process of being adopted by large enterprises. The two
frameworks are compared in figure 1.

Figure 1—Comparison of COSO Internal Control and ERM Integrated Frameworks

Internal Control Framework ERM Integrated Framework
Control Environment: The control environment sets the tone of an Internal Environment: The internal environment encompasses the
organization, influencing the control consciousness of its people. It is tone of an organization, and sets the basis for how risk is viewed and
the foundation for all other components of internal control, providing addressed by an enterprise’s people, including risk management
discipline and structure. Control environment factors include the philosophy and risk appetite, integrity and ethical values, and the
integrity, ethical values, management’s operating style, delegation of environment in which they operate.
authority systems, as well as the processes for managing and
developing people in the organization.

Objective Setting: Objectives must exist before management can

identify potential events affecting their achievement. Enterprise risk
management ensures that management has in place a process to set
objectives and that the chosen objectives support and align with the
enterprise’s mission and are consistent with its risk appetite.
Event Identification: Internal and external events affecting
achievement of an enterprise’s objectives must be identified,
distinguishing between risks and opportunities. Opportunities are
channeled back to management’s strategy or objective-setting
processes.

© 2009 ISACA. All rights reserved. Page 6

UNIX/LINUX Operating System Security Audit/Assurance Program
Figure 1—Comparison of COSO Internal Control and ERM Integrated Frameworks
Internal Control Framework ERM Integrated Framework
Risk Assessment: Every enterprise faces a variety of risks from Risk Assessment: Risks are analyzed, considering the likelihood and
external and internal sources that must be assessed. A precondition to impact, as a basis for determining how they could be managed. Risk
risk assessment is establishment of objectives, and thus risk areas are assessed on an inherent and residual basis.
assessment is the identification and analysis of relevant risks to
achievement of assigned objectives. Risk assessment is a prerequisite
for determining how the risks should be managed.
Risk Response: Management selects risk responses – avoiding,
accepting, reducing, or sharing risk – developing a set of actions to
align risks with the enterprise’s risk tolerances and risk appetite.
Control Activities: Control activities are the policies and procedures Control Activities: Policies and procedures are established and
that help ensure management directives are carried out. They help implemented to help ensure the risk responses are effectively carried
ensure that necessary actions are taken to address risks to achievement out.
of the enterprise's objectives. Control activities occur throughout the
organization, at all levels and in all functions. They include a range of
activities as diverse as approvals, authorizations, verifications,
reconciliations, reviews of operating performance, security of assets
and segregation of duties.
Information and Communication: Information systems play a key Information and Communication: Relevant information is
role in internal control systems as they produce reports, including identified, captured, and communicated in a form and timeframe that
operational, financial and compliance-related information that make it enable people to carry out their responsibilities. Effective
possible to run and control the business. In a broader sense, effective communication also occurs in a broader sense, flowing down, across,
communication must ensure information flows down, across and up and up the enterprise.
the organization. Effective communication should also be ensured with
external parties, such as customers, suppliers, regulators and
shareholders.
Monitoring: Internal control systems need to be monitored—a Monitoring: The entirety of enterprise risk management is monitored
process that assesses the quality of the system’s performance over and modifications made as necessary. Monitoring is accomplished
time. This is accomplished through ongoing monitoring activities or through ongoing management activities, separate evaluations, or both.
separate evaluations. Internal control deficiencies detected through
these monitoring activities should be reported upstream and corrective
actions should be taken to ensure continuous improvement of the
system.
Information for figure 1 was obtained from the COSO web site www.coso.org/aboutus.htm.

The original COSO internal control framework addresses the needs of the IT audit and assurance
professional: control environment, risk assessment, control activities, information and communication,
and monitoring. As such, ISACA has elected to utilize the five-component model for these
audit/assurance programs. As more enterprises implement the ERM model, the additional three columns
can be added, if relevant. When completing the COSO component columns, consider the definitions of
the components as described in figure 1.

Reference/Hyperlink
Good practices require the audit and assurance professional to create a work paper for each line item,
which describes the work performed, issues identified, and conclusions. The reference/hyperlink is to be
used to cross-reference the audit/assurance step to the work paper that supports it. The numbering system
of this document provides a ready numbering scheme for the work papers. If desired, a link to the work
paper can be pasted into this column.

Issue Cross-reference
This column can be used to flag a finding/issue that the IT audit and assurance professional wants to
further investigate or establish as a potential finding. The potential findings should be documented in a
work paper that indicates the disposition of the findings (formally reported, reported as a memo or verbal
finding, or waived).

Comments
The comments column can be used to indicate the waiving of a step or other notations. It is not to be used
in place of a work paper describing the work performed.

© 2009 ISACA. All rights reserved. Page 7

UNIX/LINUX Operating System Security Audit/Assurance Program

III. Controls Maturity Analysis

One of the consistent requests of stakeholders who have undergone IT audit/assurance reviews is a desire
to understand how their performance compares to good practices. Audit and assurance professionals must
provide an objective basis for the review conclusions. Maturity modeling for management and control
over IT processes is based on a method of evaluating the organization, so it can be rated from a maturity
level of nonexistent (0) to optimized (5). This approach is derived from the maturity model that the
Software Engineering Institute (SEI) of Carnegie Mellon University defined for the maturity of software
development.

The IT Assurance Guide Using COBIT, Appendix VII—Maturity Model for Internal Control, in figure 2,
provides a generic maturity model showing the status of the internal control environment and the
establishment of internal controls in an enterprise. It shows how the management of internal control, and
an awareness of the need to establish better internal controls, typically develops from an ad hoc to an
optimized level. The model provides a high-level guide to help COBIT users appreciate what is required
for effective internal controls in IT and to help position their enterprise on the maturity scale.

Figure 2—Maturity Model for Internal Control

Maturity Level Status of the Internal Control Environment Establishment of Internal Controls
0 Non-existent There is no recognition of the need for internal control. There is no intent to assess the need for internal control.
Control is not part of the organization’s culture or mission. Incidents are dealt with as they arise.
There is a high risk of control deficiencies and incidents.
1 Initial/ad hoc There is some recognition of the need for internal control. There is no awareness of the need for assessment of what is
The approach to risk and control requirements is ad hoc and needed in terms of IT controls. When performed, it is only on
disorganized, without communication or monitoring. an ad hoc basis, at a high level and in reaction to significant
Deficiencies are not identified. Employees are not aware of incidents. Assessment addresses only the actual incident.
their responsibilities.
2 Repeatable but Controls are in place but are not documented. Their operation Assessment of control needs occurs only when needed for
Intuitive is dependent on the knowledge and motivation of individuals. selected IT processes to determine the current level of control
Effectiveness is not adequately evaluated. Many control maturity, the target level that should be reached and the gaps
weaknesses exist and are not adequately addressed; the that exist. An informal workshop approach, involving IT
impact can be severe. Management actions to resolve control managers and the team involved in the process, is used to
issues are not prioritized or consistent. Employees may not define an adequate approach to controls for the process and to
be aware of their responsibilities. motivate an agreed-upon action plan.
3 Defined Controls are in place and adequately documented. Operating Critical IT processes are identified based on value and risk
effectiveness is evaluated on a periodic basis and there is an drivers. A detailed analysis is performed to identify control
average number of issues. However, the evaluation process is requirements and the root cause of gaps and to develop
not documented. While management is able to deal improvement opportunities. In addition to facilitated
predictably with most control issues, some control workshops, tools are used and interviews are performed to
weaknesses persist and impacts could still be severe. support the analysis and ensure that an IT process owner owns
Employees are aware of their responsibilities for control. and drives the assessment and improvement process.
4 Managed and There is an effective internal control and risk management IT process criticality is regularly defined with full support and
Measurable environment. A formal, documented evaluation of controls agreement from the relevant business process owners.
occurs frequently. Many controls are automated and regularly Assessment of control requirements is based on policy and the
reviewed. Management is likely to detect most control issues, actual maturity of these processes, following a thorough and
but not all issues are routinely identified. There is consistent measured analysis involving key stakeholders. Accountability
follow-up to address identified control weaknesses. A for these assessments is clear and enforced. Improvement
limited, tactical use of technology is applied to automate strategies are supported by business cases. Performance in
controls. achieving the desired outcomes is consistently monitored.
External control reviews are organized occasionally.
5 Optimized An enterprisewide risk and control program provides Business changes consider the criticality of IT processes and
continuous and effective control and risk issues resolution. cover any need to reassess process control capability. IT
Internal control and risk management are integrated with process owners regularly perform self-assessments to confirm
enterprise practices, supported with automated real-time that controls are at the right level of maturity to meet business
monitoring with full accountability for control monitoring, needs and they consider maturity attributes to find ways to
risk management and compliance enforcement. Control make controls more efficient and effective. The organization
evaluation is continuous, based on self-assessments and gap benchmarks to external best practices and seeks external advice
and root cause analyses. Employees are proactively involved on internal control effectiveness. For critical processes,
in control improvements. independent reviews take place to provide assurance that the
controls are at the desired level of maturity and working as
planned.
The maturity model evaluation is one of the final steps in the evaluation process. The IT audit and

© 2009 ISACA. All rights reserved. Page 8

UNIX/LINUX Operating System Security Audit/Assurance Program
assurance professional can address the key controls within the scope of the work program and formulate
an objective assessment of the maturity level of the control practices. The maturity assessment can be a
part of the audit/assurance report and can be used as a metric from year to year to document progression
in the enhancement of controls. However, it must be noted that the perception as to the maturity level may
vary between the process/IT asset owner and the auditor. Therefore, an auditor should obtain the
concerned stakeholder’s concurrence before submitting the final report to the management.

At the conclusion of the review, once all findings and recommendations are completed, the professional
assesses the current state of the COBIT control framework and assigns it a maturity level using the six-
level scale. Some practitioners utilize decimals (x.25, x.5, x.75) to indicate gradations in the maturity
model. As a further reference, COBIT provides a definition of the maturity designations by control
objective. While this approach is not mandatory, the process is provided as a separate section at the end of
the audit/assurance program for those enterprises that wish to implement it. It is suggested that a maturity
assessment be made at the COBIT control level. To provide further value to the client/customer, the
professional can also obtain maturity targets from the client/customer. The sections can be summarized
using the graphic presentation (section VIII) describing the achievement or gaps between the actual and
targeted maturity levels. If this is used, it should be noted that this assessment addresses UNIX/LINUX
only, as there are generally other operating systems in the enterprise.

IV. Assurance and Control Framework

ISACA IT Assurance Framework and Standards

ITAF section 3630.14—Operating Systems (OSs) Management and Controls—is relevant to
UNIX/LINUX security.

ISACA has long recognized the specialized nature of IT assurance and strives to advance globally
applicable standards. Guidelines and procedures provide detailed guidance on how to follow those
standards. IS Auditing Standard S15 IT Controls, and IS Auditing Guideline G38 Access Controls are
relevant to this audit/assurance program.

ISACA Controls Framework

COBIT is an IT governance framework and supporting tool set that allows managers to bridge the gap
among control requirements, technical issues and business risks. C OBIT enables clear policy development
and good practice for IT control throughout enterprises.

Utilizing COBIT as the control framework on which IT audit/assurance activities are based aligns IT
audit/assurance with good practices as developed by the enterprise.

The COBIT IT process DS9 Manage the configuration from the Deliver and Support (DS) domain,
addresses good practices for ensuring the integrity of hardware and software configurations. This requires
the establishment and maintenance of an accurate and complete configuration repository. DS5.3 Identity
management and DS5.4 User account management address user identity, and the IT process AI6 Manage
changes from the Acquire and Implement (AI) domain specifically addresses change management.
Relevant COBIT control objectives are:
 AI6.1 Change standards and procedures—Set up formal change management procedures to handle in
a standardized manner all requests (including maintenance and patches) for changes to applications,
procedures, processes, system and service parameters, and the underlying platforms.
 AI6.2 Impact assessment, prioritization and authorization—Assess all requests for change in a
structured way to determine the impact on the operational system and its functionality. Ensure that
changes are categorized, prioritized, and authorized.
 AI6.4 Change status tracking and reporting—Establish a tracking and reporting system to document

© 2009 ISACA. All rights reserved. Page 9

UNIX/LINUX Operating System Security Audit/Assurance Program
rejected changes, communicate the status of approved and in-process changes, and complete changes.
Make certain that approved changes are implemented as planned.
 DS5.3 Identity management1—Ensure that all users (internal, external and temporary) and their
activity on IT systems (business application, IT environment, system operations, development and
maintenance) are uniquely identifiable. Enable user identities via authentication mechanisms. Confirm
that user access rights to systems and data are in line with defined and documented business needs and
that job requirements are attached to user identities. Ensure that user access rights are requested by
user management, approved by system owners and implemented by the security-responsible person.
Maintain user identities and access rights in a central repository. Deploy cost-effective technical and
procedural measures, and keep them current to establish user identification, implement authentication
and enforce access rights.
 DS5.4 User account management2—Address requesting, establishing, issuing, suspending, modifying
and closing user accounts and related user privileges with a set of user account management
procedures. Include an approval procedure outlining the data or system owner granting the access
privileges. These procedures should apply for all users, including administrators (privileged users)
and internal and external users, for normal and emergency cases. Rights and obligations relative to
access to enterprise systems and information should be contractually arranged for all types of users.
Perform regular management review of all accounts and related privileges.
 DS9.1 Configuration repository and baseline—Establish a supporting tool and a central repository to
contain all relevant information on configuration items. Monitor and record all assets and changes to
assets. Maintain a baseline of configuration items for every system and service as a checkpoint to
which to return after changes.
 DS9.2 Identification and maintenance of configuration items—Establish configuration procedures to
support management and logging of all changes to the configuration repository. Integrate these
procedures with change management, incident management and problem management procedures.
 DS9.3 Configuration integrity review—Periodically review the configuration data to verify and
confirm the integrity of the current and historical configuration. Periodically review installed software
against the policy for software usage to identify personal or unlicensed software or any software
instances in excess of current license agreements. Report, act on and correct errors and deviations.

Refer to the IT Governance Institute’s COBIT Control Practices: Guidance to Achieve Control Objectives
for Successful IT Governance, 2nd Edition, published in 2007, for the related control practice value and
risk drivers.

V. Executive Summary of Audit/Assurance Focus

UNIX/LINUX Operating System Security

The review of the operating system ensures management that the computer platform that supports the
various applications is secure. If the foundation (operating systems) is not secure, the applications can be
compromised (see risk in the next section).

UNIX is one of the longest enduring operating systems in existence. Developed in 1969 by Bell Labs of
AT&T, the operating system has evolved as the equipment on which UNIX runs has matured. Initially
developed for internal AT&T and academic use, the commercial hardware vendors developed customized
versions for their specific hardware. Its selling point has been portability among hardware. Previously,
hardware vendors developed proprietary operating systems that only operated on their brand of
equipment. UNIX was the first operating system that would operate on multiple hardware platforms. The
vendors wanted to keep their maintenance fees and so developed proprietary versions, which added
1
Scope limitation—Identity management as it relates to superusers having access to the operating system
2
Scope limitation—User account management as it relates to users accessing system functions

© 2009 ISACA. All rights reserved. Page 10

UNIX/LINUX Operating System Security Audit/Assurance Program
administrative, security, performance, vendor hardware/software specific functionality. The major UNIX
implementations are Sun Microsystems’ Solaris, IBM’s AIX, and Hewlett-Packard’s HP-UX. The
primary advantage of purchasing the operating system from the vendor is the support. However, the
negatives are the initial purchase and annual maintenance fee to the vendor for its specific UNIX version,
the reliance placed on the vendor for support, the inability to customize the vendor’s version and the
knowledge that the software is proprietary.

LINUX is a recent derivative of UNIX. Its primary difference is that it is open source, meaning that the
computing community has the opportunity to add to the LINUX functionality. Linus Torvalds, the
originator of LINUX, maintains direct development of the kernel (essential processing control,
networking, and peripheral and file system access). The Free Software Foundation supports the GNU’s
Not Linux (GNU) components, ranging from graphic user interface to user applications libraries and
utilities. The LINUX source code is free. Distributors have obtained the free source and added
functionality to ease implementation (installation and configuration packages to eliminate the need to
compile the source code as well as enhance system security.

Recognizing the interest in the more cost-effective LINUX, vendors have distributed secure, tested
LINUX implementations. The major hardware vendors (Dell, IBM, HP, and Sun Microsystems) and two
large software vendors (Red Hat and Novell) provide LINUX implementations that are subject to rigorous
software change management and control. The hardware and software companies (with the addition of
Oracle) provide fee-based support. The cost component of LINUX has increased its popularity over
UNIX.

In the enterprise, UNIX and LINUX are the underlying computing platform for application servers that
execute essential business applications (both centralized and distributed), database servers that manage
the massive database used to store business data, web servers that provide the public face of the business
on the Internet, and process transactions. Recognizing the development strategies of both UNIX and
LINUX, it is essential that the source of the UNIX/LINUX operating system distribution be known, and
care must be taken to ensure only authorized and tested functions, processes and configurations are
allowed to enter the production environment.

Business Impact and Risk

UNIX/LINUX is widely used in the enterprise operating environment. The failure for UNIX/LINUX to
be properly configured could result in the inability for the business to execute its critical processes. The
collective development of LINUX adds additional risk. Unless the distribution is controlled and managed,
dangerous processes could be introduced into the operating system as a result of the open nature of the
operating system and its essential processes.

UNIX/LINUX risks resulting from ineffective or incorrect operating system configurations could permit
the operating system to become compromised resulting in:
 Disclosure of privileged information
 Loss of physical assets
 Loss of intellectual property
 Loss of competitive advantage
 Loss of customer confidence
 Violation of regulatory requirements
 Disruption of the computer infrastructure resulting in the inability to perform critical business
functions
 Infection of computer systems with viruses and the like to disrupt processing and require costly
disinfection
 Use of the computer systems as a launching pad for malicious activity against other entities (and the

© 2009 ISACA. All rights reserved. Page 11

UNIX/LINUX Operating System Security Audit/Assurance Program
potential to be held liable for their damages)

Objective and Scope

Objective—The objective of the UNIX/LINUX audit/assurance review is to provide management with an
independent assessment relating to the effectiveness of configuration and security of the UNIX/LINUX
operations systems with the enterprise’s computing environment.

Scope—The review will focus on configuration of the relevant UNIX/LINUX servers within the
organization. The selection of the applications/functions and specific servers will be based upon the risks
introduced to the organization by these systems.

UNIX/LINUX systems are subject to identity management, the process of identifying and authenticating
users and superusers. Since this process is also addressed in the Identity Management Audit/Assurance
Program, this review is limited to superuser access (access to the operating system’s configuration and
security mechanisms) and general user controls (excluding users from access to operating system
resources). Refer to the Identity Management Audit/Assurance Program for controls relating to user
identity.

{The remainder of this paragraph needs to be customized to describe which servers and applications
within the enterprise will be reviewed.}

Minimum Audit Skills

This review is considered highly technical. The IT audit and assurance professional must have an
understanding of the good practice UNIX and LINUX processes and requirements, and be highly
conversant in UNIX/LINUX tools, exposures, and functionality. It should not be assumed that an audit
and assurance professional holding the CISA designation has the requisite skills to perform this review.

© 2009 ISACA. All rights reserved. Page 12

 UNIX/LINUX Operating System Security Audit/Assurance Program

VI. Audit/Assurance Program

COSO

Control Environment
COBIT Reference Issue

Risk Assessment
Hyper-link Cross- Comments

Control Activities
Audit/Assurance Program Step Cross-

Information and
Communication
reference reference

Monitoring
1. PLANNING AND SCOPING THE AUDIT
1.1 Define audit/assurance objectives. ME2.1
The audit/assurance objectives are high level and describe the overall audit goals.
1.1.1 Review the audit/assurance objectives in the introduction to this audit/assurance
program.
1.1.2 Modify the audit/assurance objectives to align with the audit/assurance universe,
annual plan and charter.
1.2 Define boundaries of review.
The review must have a defined scope. The reviewer must understand the operating ME2.1
environment and prepare a proposed scope, subject to a later risk assessment.
1.2.1 Obtain and review the UNIX/LINUX operating system security and management
policies.
1.2.2 Obtain a list of UNIX/LINUX servers, their locations, the applications they
process or support, the UNIX/LINUX distribution (vendor), and the version
number.
1.2.3 Establish initial boundaries of the audit/assurance review.
1.2.4 Identify limitations and/or constraints limiting the audit of specific systems.
1.3 Define assurance.
The review requires two sources of standards. The corporate standards as defined in policy
and procedure documentation establish the corporate expectations. At minimum, corporate ME2.1
standards should be implemented. The second source, a good practice reference, establishes
industry standards. Gaps between the two should be proposed for enhancements.
1.3.1 Obtain and review good practice UNIX/LINUX security and configuration
standards.
1.3.2 Obtain corporate UNIX/LINUX configuration standards.
© 2009 ISACA. All rights reserved. Page 13
 UNIX/LINUX Operating System Security Audit/Assurance Program
COSO

Control Environment
COBIT Reference Issue

Risk Assessment
Hyper-link Cross- Comments

Control Activities
Audit/Assurance Program Step Cross-

Information and
Communication
reference reference

Monitoring
1.3.3 Determine if there are gaps in the corporate policy.
1.4 Identify and document risks.
The risk assessment is necessary to evaluate where audit resources should be focused. In most ME2.1
enterprises, audit resources are not available for all processes. The risk-based approach
ensures utilization of audit resources in the most effective manner.
1.4.1 Using the list of servers identified previously, determine the risk category for
each server and establish a prioritized list of servers to be assessed.
1.4.2 Review previous audits of UNIX/LINUX and other assessments.
1.4.3 Determine if issues identified previously have been remediated.
1.4.4 Evaluate the overall risk factor for performing the review.
1.4.5 Based on the risk assessment, identify changes to the scope.
1.4.6 Discuss the risks with IT, business, and operational audit management, and
adjust the risk assessment.
1.4.7 Based on the risk assessment, revise the scope.
1.5 Define the change process.
The initial audit approach is based upon the reviewer’s understanding of the operating ME2.7
environment and associated risks. As further research and analysis is performed, changes to
the scope and approach will result.
1.5.1 Identify the senior IT assurance resource responsible for the review.
1.5.2 Establish the process for suggesting and implementing changes to the
audit/assurance program, and authorizations required.
1.6 Define assignment success.
The success factors need to be identified. Communication among the IT audit/assurance team, ME2.1
other assurance teams and the enterprise is essential.

© 2009 ISACA. All rights reserved. Page 14

 UNIX/LINUX Operating System Security Audit/Assurance Program
COSO

Control Environment
COBIT Reference Issue

Risk Assessment
Hyper-link Cross- Comments

Control Activities
Audit/Assurance Program Step Cross-

Information and
Communication
reference reference

Monitoring
1.6.1 Identify the drivers for a successful review. (This should exist in the assurance
function’s standards and procedures document.)
1.6.2 Communicate success attributes to the process owner or stakeholder and obtain
agreement.
1.7 Define audit/assurance resources required. ME2.1
The resources required are defined in the introduction to this audit/assurance program.
1.7.1 Determine audit/assurance skills necessary for review.
1.7.2 Determine estimated total resources (hours) and timeframe (start and end dates)
required for review.
1.8 Define deliverables.
The deliverable is not limited to the final report. Communication between the audit/assurance ME2.1
teams and the process owner is essential to assignment success.
1.8.1 Determine the interim deliverables, including initial findings, status reports, draft
reports, due dates for response and the final report.
1.9 Communications ME2.1
The audit/assurance process is clearly communicated to the customer/client.
1.9.1 Conduct an opening conference to discuss the review objectives with the
executive responsible for operating systems and infrastructure.
2. PREPARATORY STEPS
2.1 Obtain and review the current organization chart for the operating systems
configuration and security functions.

2.1.1 Identify the key staff and stakeholders.

2.2 Select the servers to be included in the review.

© 2009 ISACA. All rights reserved. Page 15

 UNIX/LINUX Operating System Security Audit/Assurance Program
COSO

Control Environment
COBIT Reference Issue

Risk Assessment
Hyper-link Cross- Comments

Control Activities
Audit/Assurance Program Step Cross-

Information and
Communication
reference reference

Monitoring
2.2.1 Based upon the prioritized list of servers developed previously, identify the
servers to be included in the review. Be sure that there is a representative
sample of high risk servers. A group of servers may have similar functions and
can be aggregated into a group.
2.2.2 Determine if there is a corporate standard server configuration and related
settings for each type of server.
2.3 Obtain documentation for the servers to be reviewed.
2.3.1 Obtain the following file listings using UNIX/LINUX utilities or reporting
software3:
 Inittab
 Group
 Passrd
 Shadow
 Uucp
 Uucp/systems devices
 Uucp/devices
 Uucp/systems
 Uucp/permissions
 Cron.allow and cron.deny
 At.deny
 Ftpusers
 Inetd.conf
 Hosts.lpd
 Hosts.equiv
 At.allow and at.deny
 Crontab
 /etc/system on some UNIX flavors
 /etc/shells

3
Consult UNIX/LINUX documentation for specific commands and locations.
© 2009 ISACA. All rights reserved. Page 16
 UNIX/LINUX Operating System Security Audit/Assurance Program
COSO

Control Environment
COBIT Reference Issue

Risk Assessment
Hyper-link Cross- Comments

Control Activities
Audit/Assurance Program Step Cross-

Information and
Communication
reference reference

Monitoring
 Services
 /etc/josts
2.3.2 Obtain the access permissions for the following directories:
 /etc
 /bin
 /dev
 /lib
 /usr
 /kernel
 /usr/spool/cron/cronbats
 /tmp
 /etc/ftpusers
 /etc/security
 /proc
2.4 Obtain an understanding of the operating environment and management issues.
2.4.1 Interview the senior operating systems management analyst (manager or
director) to obtain an understanding of policy and procedures as well as known
issues.
2.4.2 Interview the system administrator and/or network administrator job
role/function to obtain an understanding of physical communication
interfaces/network adapters/protocols (fixed or virtual IPs/protocols).
3. ACCESS AND AUTHORIZATION
3.1 Root
Audit/assurance objective: Root access should be limited to administrators requiring access;
access should be monitored and logged.
AI3.2
4. Limit access to root
DS5.3 X
Control: Direct root access is restricted to the console.
DS5.4

© 2009 ISACA. All rights reserved. Page 17

 UNIX/LINUX Operating System Security Audit/Assurance Program
COSO

Control Environment
COBIT Reference Issue

Risk Assessment
Hyper-link Cross- Comments

Control Activities
Audit/Assurance Program Step Cross-

Information and
Communication
reference reference

Monitoring
4.1.1.1 Determine if only one account is defined as root (uid=0) by issuing the DS5.5
command Awk –F”:” /etc/passwd ‘$3 = = 0 {print $0}’ | more.
4.1.1.2 If more than one account is defined with uid=0, determine the account
owner, the reason for this access right, and verify written authorization
for this access by the information security officer.
4.1.1.3 Determine if the root password is complex and its use restricted.
4.1.1.4 Determine the process for monitoring use of the root password.
4.1.1.5 Determine if the password is changed, how often and what events
trigger a password change.4
4.1.1.6 Determine if root logons are disabled and privileged users log on using
a general user ID.
4.1.1.7 Determine if the SUDO (superuser do) facility is installed to limit the
command set for specific users, and log SUDO activities.
4.1.1.8 Determine if LDAP or Pluggable Authentication Module (PAM) is
being used. Verify the authentication process is used throughout the
enterprise.
4.1.1.9 If LDAP/PAM is being used, verify the fail-over mechanism of the
authentication request.
4.1.1.10 Verify that the authentication applications use the PAM mechanism. If
not in use, suggest the implementation of a single authentication
mechanism.

AI3.2 X
5. Limit resources available at the root directory
Control: Files accessible through the root directory are limited to those resources
4
Checking the last date of password change by any user, including the root user, is a little tricky on UNIX. The /etc/shadow file has several fields—the 5 th field will indicate a number, which is the
number of days elapsed after 01-Jan-1970 on which the user has changed the password. In some versions of UNIX this may be the seconds elapsed after 00.00 hours on 01-Jan-1970.
© 2009 ISACA. All rights reserved. Page 18
 UNIX/LINUX Operating System Security Audit/Assurance Program
COSO

Control Environment
COBIT Reference Issue

Risk Assessment
Hyper-link Cross- Comments

Control Activities
Audit/Assurance Program Step Cross-

Information and
Communication
reference reference

Monitoring
needed to log into the system.
5.1.1.1 Root’s logon files (e.g., the .profile, .cshrc, .kshrc) should not run any
other files not owned by root or which are group or world writable.
Any exceptions should be documented by the system administer and
forwarded to the security administrator.
5.1.1.2 Verify that the local directory “.” should not be in root’s search path
and the root’s PATH does not contain “.” and extraneous colons “:”
are removed.
6. Built-in IDs AI3.2
Control: Built-in IDs are renamed and/or are assigned new passwords and the DS5.4
built-in IDs are assigned to an individual for accountability.
6.1.1.1 Verify that all IDs built in by the manufacturer of hardware and 6.1.1.8 6.1.1.9 6.1.1.10
software are renamed or assigned new password and/or assigned to a
person with a sole responsibility. Examples are: oadmin, root, admin, 6.1.1.2
6.1.1.3
6.1.1.4
6.1.1.5
6.1.1.6
6.1.1.7
sysadmin, shutdown, poweroff, guest, demo, gast, Informix, oracle,
ingres, sam_exec and sap.

6.2 Superusers
Audit/assurance objective: Superuser accounts should be limited to those accounts required
by the system; administrator access should be through the SUDO or SU command or similar
processes.
7. System users AI3.2
X
Control: Systems users are limited to those required by the operating system. DS5.3

7.1.1.1 Verify that each user on the system has an associated password using the
commands pwck and grpck. (These two commands are available on
most of the UNIX systems and will give a report on the inconsistencies
in /etc/password and /etc/group files as under Validation of the number
of fields, logon name, user ID, group ID, and if the logon directory and
the program-to-use-as-shell exists.)

© 2009 ISACA. All rights reserved. Page 19

 UNIX/LINUX Operating System Security Audit/Assurance Program
COSO

Control Environment
COBIT Reference Issue

Risk Assessment
Hyper-link Cross- Comments

Control Activities
Audit/Assurance Program Step Cross-

Information and
Communication
reference reference

Monitoring
7.1.1.2 Verify if the current directory (“.”) exists anywhere in the root search
path.
7.1.1.3 Verify that all “su” attempts are logged in the “sulog” or other relevant
file.
7.1.1.4 Verify that a home directory has been established for root, and root is
restricted to that home directory
8. Vulnerable commands AI3.2 X
Control: Vulnerable commands are appropriately administered and monitored.
8.1.1.1 Verify that certain vulnerable commands (i.e., SU, SUDO, /bin/vi,
/bin/sh) are granted by the administrator (root) to other users.
8.1.1.2 Determine if their level of access (full or partial) is necessary for their
job function.
8.1.1.3 Determine if their use is monitored, by whom and the review process.
8.1.1.4 Determine if their access rights are reviewed regularly (at least each
quarter).
8.2 PS (Process Status Command) AI3.2
Control: The PS command is restricted to root users.
8.2.1 Verify that the PS command is restricted to root users and assigned through 8.2.8 8.2.9
8.2.2 8.2.68.2.7
group permissions.
AI3.2
8.3 Script Usage
DS13.1
Control: Script processing on servers is minimized or prohibited.
DS13.2
8.3.1 Verify that script processing is either prohibited or limited. 8.3.8 8.3.9
8.3.28.3.38.3.48.3.58.3.68.3.7

© 2009 ISACA. All rights reserved. Page 20

 UNIX/LINUX Operating System Security Audit/Assurance Program
COSO

Control Environment
COBIT Reference Issue

Risk Assessment
Hyper-link Cross- Comments

Control Activities
Audit/Assurance Program Step Cross-

Information and
Communication
reference reference

Monitoring
3.4.2 Verify that scripts require appropriate documented approvals, including 8.3.16 8.3.17
8.3.10
8.3.11
8.3.12
8.3.13
8.3.14
8.3.15
justification, prior to implementation.
8.4 General user
Audit/assurance objective: General user accounts should be assigned to individual users, the
user ID (including number) should be unique, password composition should be in compliance DS5.3
with organization password complexity standards and unnecessary user IDs with special
functions should be disabled.
9. Unnecessary system accounts are disabled AI3.2 X
Control: Unnecessary system user IDs are disabled.
9.1.1.1 Verify that sys, uucp, nuucp and guest are disabled.
9.1.1.2 Verify that the following accounts are disabled unless there is a
demonstrated need to enable: servdir, sync, shutdown, halt, mail,
news, operator, games, gopher, mysql, ftp, anonymous.
9.1.1.3 Verify that systems accounts may not use FTP: root, smtp, daemon,
bin, sys, adm, uucp, nuucp, listen, lp, lpd, guest, nobody, noaccess.
9.1.1.4 Verify that disabled accounts have a null shell (/dev/null or /bin/false)
assigned and an invalid password in the /etc/shadow file.
10. Unique user IDs and password complexity DS5.3 X
Control: Each user logon is unique and password complexity policy is followed.
10.1.1.1 Verify that passwd complexity controls available in the vendor’s
UNIX /LINUX implementation are enabled.
10.1.1.1.1 For AIX, determine if the AIX password configuration is
set to provide maximum complexity.
10.1.1.1.2 For Solaris, determine that the parameters in the
/etc/default/passwd file are set for maximum password

© 2009 ISACA. All rights reserved. Page 21

 UNIX/LINUX Operating System Security Audit/Assurance Program
COSO

Control Environment
COBIT Reference Issue

Risk Assessment
Hyper-link Cross- Comments

Control Activities
Audit/Assurance Program Step Cross-

Information and
Communication
reference reference

Monitoring
complexity.
10.1.1.1.3 For LINUX, determine if the global settings are set to
maximum password complexity and determine if additional
password complexity add-ins are used to enhance security.
10.1.1.2 Review the /etc/passwd file to ensure that all users have a unique ID.
The following commands can be used to identify the user:
 Names that are not unique use cat /etc/passwd | awk –F”:” ‘{print $1}’
| sort | uniq –c | sort –r | grep –v “^ 1”|more
 User IDs that are not unique use cat /etc/passwd | awk –F”:” ‘{print
$3}’ | sort | uniq –c | sort –r | grep –v “^ 1”|more
10.1.1.3 Obtain a utility for the version of UNIX running and determine that
the user IDs in the password and shadow password files match and the
password complexity is validated for adherence to policy.
11. Password attributes
Control: Password attributes (frequency of change, length of password, reuse of DS5.3
passwords) are established according to policy and according to the sensitivity of
information available to the user.5
11.1.1.8 11.1.1.9
11.1.1.1 Determine if password frequency change is in alignment with policy 11.1.1.2
11.1.1.3
11.1.1.4
11.1.1.5
11.1.1.6
11.1.1.7
and is based on the sensitivity of data for which the user is responsible.
11.1.1.16 11.1.1.17
3.5.3.2 Determine if password reuse (number of generations before being 11.1.1.10
11.1.1.11
11.1.1.12
11.1.1.13
11.1.1.14
11.1.1.15
usable) is in alignment with policy.
11.1.1.24 11.1.1.25
3.5.3.3 Verity that the quality of passwords is regularly evaluated using 11.1.1.18
11.1.1.19
11.1.1.20
11.1.1.21
11.1.1.22
11.1.1.23
appropriate tools.
11.2 Warning banner
Audit/assurance objective: A warning banner should be installed, warning the user of the DS5.3
purpose, the computer environment and adherence to policy.

5
This step may have been a part of the identity management review.
© 2009 ISACA. All rights reserved. Page 22
 UNIX/LINUX Operating System Security Audit/Assurance Program
COSO

Control Environment
COBIT Reference Issue

Risk Assessment
Hyper-link Cross- Comments

Control Activities
Audit/Assurance Program Step Cross-

Information and
Communication
reference reference

Monitoring
12. Warning banner X
A warning banner is installed that displays when anyone logs into the server.
12.1.1.1 Verify that the warning banner is set in /etc/motd and /etc/issue.
12.2 Group
Audit/assurance: Group identification should be to facilitate permission administration, but
not for logon or accountability purposes.
13. Group logon disabled AI3.2 X
Control: logon using group accountability is not permitted.
13.1.1.1 For each group in the /etc/group file review members of user groups to
ensure that access permitted to group members is authorized.
13.2 Boot Setup
Control: During the boot process, insecure commands cannot be executed by nonauthorized
persons.
13.2.1 Verify that a boot password is enabled in the BIOS or Open Boot Prompt 13.2.8 13.2.9
13.2.2
13.2.3
13.2.4 13.2.6
13.2.5 13.2.7
(OBP).
3.8.2 Verify that the password mechanism has been enabled in the LILO or GRUB 13.2.16 13.2.17
13.2.10
13.2.11
13.2.12 13.2.14
13.2.13 13.2.15
bootloader.
13.3 System directories
Audit/assurance objective: Critical system directories should be protected from unauthorized
access.
14. System directories permissions set for maximum security
Control: System directories are set to maximum security and users are not assigned AI3.2 X
to groups that have access to systems directories
14.1.1.1 Verify that all system directories or executables have maximum permissions
RWXR-XR-X; system control files and scripts RWXR--R--
14.1.1.2 Verify that the /etc/shadow file is set to –rw------ (600), and the

© 2009 ISACA. All rights reserved. Page 23

 UNIX/LINUX Operating System Security Audit/Assurance Program
COSO

Control Environment
COBIT Reference Issue

Risk Assessment
Hyper-link Cross- Comments

Control Activities
Audit/Assurance Program Step Cross-

Information and
Communication
reference reference

Monitoring
/etc/passwd file is set to –rw-r---r--- (644).
14.1.1.3 Verify that all files that are writeable by OTHER are set to no write
for group and world.
14.1.1.4 Verify that the permissions for the critical directories below have the
other (world) umask set to r-x (read/execute/no write). Critical
directories include but are not limited to the following:
Others Per- Typical
Directory mission Setting Owner Group
/bin r-x bin bin
/dev r-x root sys
/dev/dsk r-x root other
/dev/rdsk r-x root other
/etc r-x root sys
/etc/conf r-x root sys
/etc/default r-x root sys
/etc/init.d r-x root sys
/etc/log r-x root sys
/etc/perms r-x root sys
/lib r-x bin bin
/root r-x root bin
/shlib r-x root sys
14.1.1.5 Determine if there are other directories requiring additional security
and verify that they have an owner of the root and appropriate
permission settings.
14.1.1.6 Analyze the listing of all other directories containing operating system
files.
14.1.1.7 Identify the users and groups that are permitted to access the list of
operating system files.

© 2009 ISACA. All rights reserved. Page 24

 UNIX/LINUX Operating System Security Audit/Assurance Program
COSO

Control Environment
COBIT Reference Issue

Risk Assessment
Hyper-link Cross- Comments

Control Activities
Audit/Assurance Program Step Cross-

Information and
Communication
reference reference

Monitoring
14.1.1.8 Determine if this access is necessary.
14.1.1.9 Determine if there is a procedure for regularly analyzing use of these
files and monitoring access maintenance as job functions change.
15. Setuid and setgid
Control: Use of setuid and setgid are monitored; files assigned the higher privilege DS5.5 X
are monitored and reviewed.
15.1.1.1 Determine if the use of setuid and setgid requires approvals each time
the command is used.
15.1.1.2 Determine if a list of files having setuid and setgid applied exists.
15.1.1.3 Determine if the baseline includes a list of files with the permission bit
“s” set.
15.1.1.4 Determine if the regular baseline compares permissions tests for this DS5.5
feature.
15.1.1.5 Review programs with the setuid and/or setgid bit set. (Many of the
setuid and setgid programs are used only by root, or by the user or
group-ID to which they are set. They can have setuid and setgid
removed without diminishing the user’s abilities to get work done.)
15.1.1.6 Verify that permissions prevent modification by other (world).
15.2 User profiles and restricted shells
Audit/assurance objective: User profiles should be managed by administrators; users should
not be allowed to modify their profiles; standard shells should be assigned unless a special
shell is required; and the default permission for user-created files should be secure.
16. User profiles AI3.2
Control: Standard user profiles are assigned to individuals, which provide the X
DS5.3
necessary permissions to perform their job function.
16.1.1.1 Identify the standard user profiles in use and determine if the default

© 2009 ISACA. All rights reserved. Page 25

 UNIX/LINUX Operating System Security Audit/Assurance Program
COSO

Control Environment
COBIT Reference Issue

Risk Assessment
Hyper-link Cross- Comments

Control Activities
Audit/Assurance Program Step Cross-

Information and
Communication
reference reference

Monitoring
user profile is appropriate for most users.
16.1.1.2 Verify that users cannot modify their profile.
16.1.1.3 Verify that the permission for the profile files in the user’s folder is to
read/execute (-r-x).
16.1.1.4 Verify that the group is appropriate and that groups don’t have access
to the .profile.
16.1.1.5 Verify that the default umask when creating files in their directory is
set to 077 (-rwx------) user:rwx only) - review .profile file for s sample
of users (both regular and superusers).
17. Test objective: To verify that users can only create files in their own home
directory and designated group directories, and that these files are DS5.5
protected from other users’ access/.
17.1.1.1.1 Select a representative sample of users.
17.1.1.1.2 Verify that the .profile has a umask entry of 077
17.1.1.1.3 Verify that the contents of the home directories have an
effective permission of 077 (-rwx------).
18. Test objective: To verify the use of standard profiles, and identify users DS5.5
who can change their own profiles.
18.1.1.1.1 Select a sample of .profile from the user directories.
18.1.1.1.2 Identify profiles that are not restricted by umask.
18.1.1.1.3 For those profiles, examine the contents and determine if
the user has modified the profile.
AI3.2 X
19. Shells
DS5.4
Control: Users are assigned a standard shell unless their function requires
DS5.5
enhanced or restricted access functions. Use of nonstandard shells is controlled and

© 2009 ISACA. All rights reserved. Page 26

 UNIX/LINUX Operating System Security Audit/Assurance Program
COSO

Control Environment
COBIT Reference Issue

Risk Assessment
Hyper-link Cross- Comments

Control Activities
Audit/Assurance Program Step Cross-

Information and
Communication
reference reference

Monitoring
monitored.
19.1.1.1 Determine if nonstandard shells are used.
19.1.1.2 If they are used, determine how restrictive and enhanced shells are
assigned, managed and reviewed.
20. Test objective: To verify that nonstandard shells are managed and re- DS5.5
evaluated based on need.
20.1.1.1.1 Select a sample of users assigned nonstandard shells.
20.1.1.1.2 Determine the scope of their job function and compare to
the capabilities using the shell—identify mismatches.
20.2 User and group directory permissions
Audit/assurance objective: Users and groups should have access to directories required to
fulfill job function.
21. Groups
Control: Groups are assigned appropriate permissions, and users are assigned to DS5.4 X
groups based on job function.
21.1.1.1 Identify the groups in the /etc/group file.
21.1.1.2 Determine if the permissions within the group file are appropriate
based on the job function of the group.
21.1.1.3 Determine if the members of the group are appropriate based on the
scope of the group’s access and the job functions of the group.
22. Test objective: To verify that the group access rights are appropriate. DS5.5

22.1.1.1.1 Select a sample of groups from different business units and

management levels.
22.1.1.1.2 For those selected, review the directory permissions and
compare the identify group access requirements against
appropriate separation of duties (SOD) tables.
© 2009 ISACA. All rights reserved. Page 27
 UNIX/LINUX Operating System Security Audit/Assurance Program
COSO

Control Environment
COBIT Reference Issue

Risk Assessment
Hyper-link Cross- Comments

Control Activities
Audit/Assurance Program Step Cross-

Information and
Communication
reference reference

Monitoring
23. User permissions
Control: User permissions are initially set by group; additional permissions are DS5.4 X
based on job function.
23.1.1.1 Determine if individual users have appropriate permissions in excess
of the group assignment based on job function.
24. Test objective: To verify that the users’ access rights are appropriate. DS5.5

24.1.1.1.1 Select a sample of users from different business units and

management levels.
24.1.1.1.2 For those selected, review the directory permissions and
compare the identify user access requirements against
appropriate SOD tables.
24.1.1.2 Verify that all files and directories have owners.
25. NETWORK
25.1 Services
Audit/assurance objectives: Only services required for the operation of the operating system
should be enabled.
26. Network services permitted through routers AI3.2
Control: Only the external network services that are required to operate the X
DS5.10
specific server applications are permitted through the external or internal routers.
26.1.1.1 Verify that only those services that are required from outside the
domain are allowed through router filters. If it is not required, routing
should also be turned off on the UNIX system.
26.1.1.1.1 Solaris: This is controlled by /etc/init.d/inetinit. To turn off
routing on a Solaris 2.5 machine, touch /etc/notrouter.

26.1.1.1.2 AIX: To dynamically turn off routing, use no -o

© 2009 ISACA. All rights reserved. Page 28
 UNIX/LINUX Operating System Security Audit/Assurance Program
COSO

Control Environment
COBIT Reference Issue

Risk Assessment
Hyper-link Cross- Comments

Control Activities
Audit/Assurance Program Step Cross-

Information and
Communication
reference reference

Monitoring
ipforwarding=0. To turn it off at system boot add that line to
the /etc/rc.net file.
27. Services are enabled based on server functionality
Control: Services requirements are evaluated based on the function of the server; AI3.2 X
unnecessary services are disabled.
27.1.1.1 Determine if there are baseline configuration requirements for each
type of server (i.e., database, file, print, web).
28. Test Objective: To verify that the appropriate services are enabled on the DS5.5
servers.
28.1.1.1.1 Collect and/or prepare server inventory and classify server
(e.g., by server function/ service type) viz. application,
network, print server, file server, security/firewall, storage,
desktop, Desktop publishing (DTP), thin client, etc.
28.1.1.1.2 Using the implementation-specific commands (inetd.conf),
identify the services running and evaluate if they are
appropriate to the mission of the server. Consider the
following as potential candidates for disabling: rusersd,
rstatd, rwalld, shell (rsh), comsat, tftp, netstat, login (rlogin),
talk, finger, time, exec (rexec), uucp, sysstat, echo, name,
discard, daytime, chargen, sprayd and bootps.
28.1.1.1.3 Inspect the running services (command PS–EF) and
listening ports (commands netstat–a and rpcinfo) to verify
listening services.
28.1.1.1.4 Verify xwindows is not configured to remotely export X
sessions (TCP port 6000-6010)
28.1.1.1.5 Verify that access to XServer is restricted.
28.1.1.2 Determine if remote access is required for the servers under review.

© 2009 ISACA. All rights reserved. Page 29

 UNIX/LINUX Operating System Security Audit/Assurance Program
COSO

Control Environment
COBIT Reference Issue

Risk Assessment
Hyper-link Cross- Comments

Control Activities
Audit/Assurance Program Step Cross-

Information and
Communication
reference reference

Monitoring
28.1.1.3 If remote access is not required, or the preferred ssh keys are used,
verify that the .netrc files are deleted.
28.1.1.4 If remote access is required, and the .netrc file is present, verify that
the file allows only the owner (-400) to be permitted to read the file.
28.1.1.5 Determine if remote shell access is not required. If that is the case,
verify that rshd is commented out in the file /etc/inetd.conf or protect it
with a Transmission control protocol (TCP) Wrapper.
28.1.1.6 Verify that Single Network Management Protocol (SNMP) service is
disabled, whenever not required.
28.1.1.7 Verify that SNMP community string is hard to guess.
28.1.1.8 Verify that SNMP version 3 is installed.
28.1.1.9 Monitor all services started via the inetd or xinted Internet daemon. If
inetd is used, all services should be secured via the TCP Wrapper.
29. Access to network configuration files
Control: Access to network configuration files is limited to administrators, the host AI3.2 X
names are accurately identified and services are appropriately enabled.
29.1.1.1 Verify that access to /etc/hosts (host name), /etc/services (ports and
protocols) and /etc/inetd.conf (daemon to start network services) is
limited to the root directory.
29.1.1.2 Verify that each host exists and has the correct IP address.
29.1.1.3 Verify that network services in inetd.conf have been removed if not
needed; /etc/services is only a reference file.
29.1.1.4 Verify that network services in startup scripts have been removed if
they are not required.

© 2009 ISACA. All rights reserved. Page 30

 UNIX/LINUX Operating System Security Audit/Assurance Program
COSO

Control Environment
COBIT Reference Issue

Risk Assessment
Hyper-link Cross- Comments

Control Activities
Audit/Assurance Program Step Cross-

Information and
Communication
reference reference

Monitoring
29.1.2 System date and time 29.1.3
Control: System date and time stamp should be synchronized with a standard
date and time using the Network Time Protocol (NTP)
4.1.4.1 Verify that the servers are utilizing the system time and date 29.1.3.2 29.1.3.3 29.1.3.4
29.1.3.1
synchronization via NTP.
29.2 File Transfer Protocol (FTP) controls
Audit/assurance objectives: FTP should be disabled if not needed, and secured with
passwords and best-practice permissions if needed.
30. Disable FTP AI3.2
Control: FTP is disabled.
30.1.1.1 Determine if the servers require FTP according to their function.
30.1.1.2 Verify that the FTP daemon is disabled and ports 20-21 are disabled.
31. FTP configuration is secure AI3.2 X
Control: Good practice FTP configuration settings have been implemented.
31.1.1.1 Verify that ssh and scp are used for Telnet and FTP.
31.1.1.2 Verify that root users are not allowed to log into the system via the ssh
configuration.
31.1.1.3 Verify that .netrc has been removed. Passwords contained in the file
put other systems at risk.
31.1.1.4 If FTP is required, review /etc/ftpusers to ensure that users who will
not be permitted to use FTP have their user IDs in this file. Verify that
the root user ID is also in the file to prevent the root user from using
FTP.
31.1.1.5 Verify that there are no real users or passwords in ftp/etc/passwd.
31.1.1.6 Verify that FTP home is assigned its own file system and is isolated
from the rest of the system.
© 2009 ISACA. All rights reserved. Page 31
 UNIX/LINUX Operating System Security Audit/Assurance Program
COSO

Control Environment
COBIT Reference Issue

Risk Assessment
Hyper-link Cross- Comments

Control Activities
Audit/Assurance Program Step Cross-

Information and
Communication
reference reference

Monitoring
31.1.1.7 Verify that anonymous FTP has been disabled.
31.1.1.8 Verify that the shell for the FTP user in /etc/passwd entry is set to
/dev/null.
31.1.1.9 Verify the owner permissions for the following:
 ftp/root dr-xr-xr-x
 ftp/bin/root d--x--x—x
 ftp/bin/ls d--x--x—x
 ftp/etc/root d--x--x—x
 ftp/etc/passwd/root -r--r--r—
 ftp/etc/group/root -r--r--r—
 ftp/pub/root drwxrwxrwt
31.1.1.10 Determine if Trivial file transfer protocol (TFTP) is required.
31.1.1.11 If TFTP is not required, it should be disabled or secured in the in the
inetd.conf file.
31.1.1.12 Check inetd.conf file to verify that it runs with secure option (-s) to
force TFTP to restrict access to the restricted directory.
31.2 Sendmail
Audit/assurance objective: Sendmail should be controlled or disabled, based on the function
of the server.
32. Sendmail AI3.2
Control: Sendmail should be disabled if the system is not running as a mail server.
32.1.1.1 Verify that the sendmail daemon has been disabled or is not listening
for incoming mail connections (SMTP over TCP port 25) on systems
that are not configured/required as a mail server.
32.1.1.2 Determine if the more secure Smrsh sendmail alternative is in use and
properly configured.
32.2 Trusted hosts
© 2009 ISACA. All rights reserved. Page 32
 UNIX/LINUX Operating System Security Audit/Assurance Program
COSO

Control Environment
COBIT Reference Issue

Risk Assessment
Hyper-link Cross- Comments

Control Activities
Audit/Assurance Program Step Cross-

Information and
Communication
reference reference

Monitoring
Audit/assurance objective: The use of remote access by defining a trusted host, should be
avoided.
33. Trusted hosts are disabled AI3.2 X
Control: Trusted hosts facilities are disabled.
33.1.1.1 Verify that the file /etc/hosts.equiv has been removed from the system.
33.1.1.2 Verify that no .rhosts files are in the user home directories or
anywhere else on the server.
34. Trusted hosts are limited in their permissions AI3.2 X
Control: Trusted hosts are limited in their scope of resources.
34.1.1.1 Determine if trusted hosts are permitted in the information security
policy.
34.1.1.2 If trusted hosts are permitted, determine the justification and if other
techniques have been considered.
34.1.1.3 Determine if the information security officer has approved the use of
trusted hosts.
34.1.1.4 Determine if other control mechanisms (certificates, public key
infrastructure [PKI]) can be employed.
34.1.1.5 Verify that the /etc/hosts.equiv has the following:
 Only a small number of trusted hosts listed based on a
demonstrated need to use the resource.
 Only trust hosts within the local domain or under an
organization’s management are issued access.
 The trusted host is listed in the /etc/hosts file.
 The character ‘+’ is not listed by itself anywhere in the file since
this may allow any user access to the system.
 The characters ‘!’ or ‘#’ are not used since there is no comment
character for this file.
 The first character of the file is not ‘-’ (indicating a script).
© 2009 ISACA. All rights reserved. Page 33
 UNIX/LINUX Operating System Security Audit/Assurance Program
COSO

Control Environment
COBIT Reference Issue

Risk Assessment
Hyper-link Cross- Comments

Control Activities
Audit/Assurance Program Step Cross-

Information and
Communication
reference reference

Monitoring
 The permissions are set to 400.
(world:none;group:none:user:read/no write/no execute).
 The owner is set to root.
34.1.1.6 Verify that only users requiring access have an .rhost file in their home
directory. Verify each .rhost file for the following:
 The permissions are set to 600
(world:none;group:none:user:read/write/no execute).
 The first character of the file is not ‘-’ (indicating a script).
 The owner of the file is the account's owner.
 The file does not contain the symbol “+” on any line as this may
allow any user access to this account. Usage of netgroups
within .rhosts does not allow unintended access to this account.
The characters ‘!’ or ‘#’ are not used since there is no comment
character for this file.
34.2 File systems
Audit/assurance objective: Remote mounting of file systems should be minimized.
35. Remote file system mounting
Control: Remote file system mounting using the network file system (NFS)
X
should be disabled, if possible. Other file sharing mechanisms should be
employed.
35.1.1.1 Determine if remote file system mounting is used and the justification
for it.
35.2 If it is not used, verify that NFS is not enabled.
36. Using NFS AI3.2 X
Control: If NFS is utilized, good practice configurations are implemented.
36.1.1.1 Determine if the following best practices are implemented:
 The NFS server is not self-referenced in its own exports file.
 Exports files don't contain a “localhost” entry.
 Export file systems only to hosts that require them.
 Export lists do not exceed 256 characters; aliases should not exceed
© 2009 ISACA. All rights reserved. Page 34
 UNIX/LINUX Operating System Security Audit/Assurance Program
COSO

Control Environment
COBIT Reference Issue

Risk Assessment
Hyper-link Cross- Comments

Control Activities
Audit/Assurance Program Step Cross-

Information and
Communication
reference reference

Monitoring
256 characters after the aliases have been expanded.
36.1.1.2 Verify that only the file systems needed are exported.
36.1.1.3 Verify that export file systems are not unintentionally permitted to the
world. Use -access=host.domainname.com option or equivalent for
each file system exported.
36.1.1.4 Verify that file systems are set to read-only (-ro) whenever possible.
36.1.1.5 Verify that the permissions on the export file is 644 and the owner is
root.
36.1.1.6 Verify that the NFS client maps the file systems as nobody, unless
specifically required.
36.1.1.7 Verify that the file systems use the –nosuid option for mounting
folders, to prevent execution of setuid programs.
36.1.1.8 Verify that the file systems use the option anon=-1 to completely
disable the anonymous access.
36.2 Network interface card (NIC)
Audit/assurance objectives: The NIC should not operate in “promiscuous mode.”
37. NIC operating mode AI3.2 X
Control: The NIC operates in standard mode, not promiscuous mode.
37.1.1.1 Verify that the NIC does not operate in promiscuous mode.
37.1.1.2 Verify that unused physical and/or logical interfaces have been
disabled.
37.2 Bluetooth
Audit/assurance objective: Bluetooth should be configured securely to prevent unauthorized
access and use.
37.2.1 Bluetooth Configuration 37.2.8 37.2.9
37.2.2
37.2.3
37.2.4
37.2.5
37.2.6
37.2.7
Control: Bluetooth is configured for maximum security
© 2009 ISACA. All rights reserved. Page 35
 UNIX/LINUX Operating System Security Audit/Assurance Program
COSO

Control Environment
COBIT Reference Issue

Risk Assessment
Hyper-link Cross- Comments

Control Activities
Audit/Assurance Program Step Cross-

Information and
Communication
reference reference

Monitoring
4.8.1.1 Verify that Bluetooth device is not discoverable. 37.2.9.1
37.2.9.2
37.2.9.3
37.2.9.4
37.2.9.5
37.2.9.6 37.2.9.7 37.2.9.8 37.2.9.9
4.8.1.2 Verify that Bluetooth device is configured so that a remote device is not
able to identify the Bluetooth device class.
4.8.1.3 Verify that only required Bluetooth Information Exchange Services
(BIE) are enabled. All other services must be disabled.
4.8.1.4 Determine that Bluetooth Personal Area Networking (PAN) is not
allowed and all related services are disabled.
4.8.1.5 Verify that Bluetooth COM port services are used for serial
communication, modem connection and synchronization purposes.
4.8.1.6 Verify that file transfer over Bluetooth uses a secure password
mechanism, (whenever required) per agreed password policy.
4.8.1.7 Verify that the user is informed interactively by a dialogue, when
data/file is received over the Bluetooth interface.
4.8.1.8 Verify that automatic association of received file, e.g., v-card is
disabled.
38. MONITORING AND AUDITING THE SYSTEM
38.1 Audit Facilities
Audit/assurance objective: Audit logs should be produced to effectively record essential
activities, provide evidence of management review and actions based on incidents identified,
and retained to provide evidence for forensic reviews and investigations.
39. Sulog
Control: The sulog is maintained and reviewed for use of the su (sudo) command DS5.5 X
and cron events.

39.1.1.1 Determine if the systems administrator regularly maintains and

reviews the sulog for unauthorized su attempts. (The ability to use

© 2009 ISACA. All rights reserved. Page 36

 UNIX/LINUX Operating System Security Audit/Assurance Program
COSO

Control Environment
COBIT Reference Issue

Risk Assessment
Hyper-link Cross- Comments

Control Activities
Audit/Assurance Program Step Cross-

Information and
Communication
reference reference

Monitoring
superuser or the su command should be reserved for only the system
administrator(s). The sulog will show how many attempts have been
made to a superuser account. If the sulog is not maintained, there are
no other utilities available to track attempts to use superuser accounts.
The sulog can generally be viewed with the command more
/usr/adm/sulog. It can become quite large if not reviewed daily.)
40. Syslog AI3.2
Control: The syslog is configured to record significant activities, and is maintained DS5.5 X
and reviewed for failed logons and other system events. DS13.3

40.1.1.1 Identify which activities are configured for recording in the syslog file
and evaluate if the appropriate activities are monitored.
40.1.1.2 Determine if the systems administrator regularly maintains and
reviews the syslog for significant events.
AI3.2
41. Cron log
DS5.5 X
Control: The cron log is maintained and reviewed for cron activities.
DS13.3
41.1.1.1 Determine if the cron log is generated and reviewed for cron activities.
42. Log management DS5.5
Control: Logs are printed, where appropriate; logs are reviewed; the review DS5.7
process is documented; incidents are placed into the issue management system and X
DS9.2
are investigated and closed. Those issues requiring escalation are forwarded to the DS13.3
appropriate personnel on a timely basis. Open issues are aged and monitored.
42.1.1.1 Determine how each of the logs described is managed, reviewed and
approved.
42.1.1.2 Determine the criteria for an incident for each of the logs and the
procedure for initiating an incident.
42.1.1.3 Determine how incidents are monitored, aged, closed or escalated.
DS5.5
43. Test objective: To verify that systems logs are reviewed and incidents are
© 2009 ISACA. All rights reserved. Page 37
 UNIX/LINUX Operating System Security Audit/Assurance Program
COSO

Control Environment
COBIT Reference Issue

Risk Assessment
Hyper-link Cross- Comments

Control Activities
Audit/Assurance Program Step Cross-

Information and
Communication
reference reference

Monitoring
monitored and managed.
43.1.1.1.1 Obtain the sulog, syslog and cron log for a range of dates.
43.1.1.1.2 Verify that each log has been reviewed with appropriate
evidence of review.
43.1.1.1.3 Determine if an incident should have been initiated based
on the criteria established in the policy and if an incident
has been established.
43.1.1.1.4 Follow the incident through the resolution process.
Determine if the incident was appropriately followed up, on
a timely basis, closed or escalated.
43.1.1.1.5 For escalated incidents, determine if they have been closed
and evaluate the response:
 Verifying the incident criteria includes:
 Short or incomplete logs
 Logs containing unusual timestamps
 Logs with incorrect permissions or ownership
 Records of reboots or starting of services
 Missing logs
 su entries or logons from unusual places
 Too many failed logons
43.1.1.2 Verify that all system logs are copied to a central file server for review
and archiving.
44. Log archive AI3.2
X
Control: Logs are archived in secure locations and retained according to policy. DS5.5

44.1.1.1 Determine the procedure for archiving the logs described.

44.1.1.2 Determine how long the logs are retained and if this is in accordance
with policy and the needs of potential forensic investigations.

© 2009 ISACA. All rights reserved. Page 38

 UNIX/LINUX Operating System Security Audit/Assurance Program
COSO

Control Environment
COBIT Reference Issue

Risk Assessment
Hyper-link Cross- Comments

Control Activities
Audit/Assurance Program Step Cross-

Information and
Communication
reference reference

Monitoring
44.1.1.3 Determine if the security protecting the logs will meet the rules of
evidence for the governing bodies.
45. Test objective: To verify that the logs are maintained according to policy. DS5.5

45.1.1.1.1 Select a range of dates for system logs.

45.1.1.1.2 Determine if the logs are available by requesting their
retrieval.
45.1.1.1.3 Evaluate the security and ability to access and review the
logs.
45.2 Monitoring facilities
Audit/assurance objective: Relevant controls should be established in automated monitoring DS5.5
facilities.
45.2.1 In case multiple systems/servers are available, verify that each
facility/system/server writes messages into its own file and directs all messages
to a central syslog server.
45.2.2 Verify the list of specific keywords (e.g., Refused, Denied, WARN, Blocked,
Cleaned, Quarantined) used. Tools, e.g., swatch, logsurfer, are used for these
tasks.
45.2.3 Verify if automated monitoring is not available and which of the alternative
processes is used for raising alerts/incidents.
45.2.4 Verify if automated monitoring is not available; log files are evaluated once per
week or at regular intervals.
5.3 Last Log
DS5.4
Control: Last log is reviewed regularly for users not logging out of the system or logged
DS5.5
in for prolonged periods.
5.3.1 Obtain and review last log for logon/logoff details. Identify users logged on for
prolonged periods or not logging off.

© 2009 ISACA. All rights reserved. Page 39

 UNIX/LINUX Operating System Security Audit/Assurance Program
COSO

Control Environment
COBIT Reference Issue

Risk Assessment
Hyper-link Cross- Comments

Control Activities
Audit/Assurance Program Step Cross-

Information and
Communication
reference reference

Monitoring
46. OPERATING SYSTEM AND APPLICATION PATCHES AND CONFIGURATION
CHANGE MANAGEMENT
46.1 Baseline
Audit/assurance objective: A baseline of approved daemons, scripts, configurations and user
information should be maintained for each server. The baseline should be evaluated for
accuracy. The baseline should be compared to the servers on a regular basis to identify
irregularities.
47. Baseline comparisons DS5.5
Control: Baseline comparisons are run regularly to identify unauthorized or X
DS9.3
erroneous baseline changes.
47.1.1.1 Verify that baseline comparisons are run regularly.
47.1.1.2 Verify that the baseline comparisons include scripts in the baseline.
48. Configuration baseline
Control: An approved list of daemons, scripts, programs, etc. is maintained for DS9.1 X
each server.
48.1.1.1 Verify that the baseline includes every executable file that is or could
run as root, critical control files and their directories.
49. Patch list AI3.3
Control: A patch list of operating system patches, service packs, etc. is maintained. X
DS5.5
During the baseline test, patches are verified.
49.1.1.1 Obtain the patch list for the servers under review.
49.1.1.2 Determine that the patch list is current as suggested by the operating
system vendor.

DS5.5 X
50. Baseline verification
Control: The baseline configuration is compared to the servers on a
© 2009 ISACA. All rights reserved. Page 40
 UNIX/LINUX Operating System Security Audit/Assurance Program
COSO

Control Environment
COBIT Reference Issue

Risk Assessment
Hyper-link Cross- Comments

Control Activities
Audit/Assurance Program Step Cross-

Information and
Communication
reference reference

Monitoring
regular basis; the comparison is documented and the differences are
analyzed.
50.1.1.1 Determine that the policy has a requirement for the frequency of
baseline verification.
50.1.1.2 Determine if baseline verifications are executed as prescribed in the
policy.
50.1.1.3 Determine if differences are investigated. The baseline or the live
operating system may require modification.
51. Accounting data recording
Control: An accounting recording and reporting process is installed to ensure that AI3.2
X
important events are recorded, but the accounting function does not affect DS5.3
performance.
51.1.1.1 Determine if accounting is turned on and reviewed regularly.
51.1.1.2 Issue the command ls -l /usr/adm/pacct. If the file exists and has a
recent modify date, then accounting is turned on.
51.1.1.3 Determine if a reporting or filtering process is utilized.
51.1.1.4 Evaluate the availability of accounting data for forensic review.
51.2 Operating System Configuration
Audit/assurance objective: The operating system should be implemented to provide a good
practice security configuration.
52. Cron and At AI3.2
Control: The cron and at daemons are configured to prevent unauthorized access X
DS13.2
to scheduling capabilities to prevent unauthorized resources from being processed.
52.1.1.1 Determine if the cron.allow, at.allow, cron.deny and at.deny files are
in use.
52.1.1.2 Determine if the user IDs are identified in the cron.allow, at.allow,

© 2009 ISACA. All rights reserved. Page 41

 UNIX/LINUX Operating System Security Audit/Assurance Program
COSO

Control Environment
COBIT Reference Issue

Risk Assessment
Hyper-link Cross- Comments

Control Activities
Audit/Assurance Program Step Cross-

Information and
Communication
reference reference

Monitoring
cron.deny and at.denyare appropriate. Note: Evidence of approval and
justification should be available for users identified in cron.allow.
52.1.1.3 Determine if all programs executed as cron jobs are secured from
unauthorized modification using file system permissions.
52.1.1.4 Determine if this table is reviewed regularly.
53. UNIX logon program AI3.2
Control: The appropriate UNIX logon program is used based upon the sensitivity DS5.3 X
of data on the server. DS5.4

53.1.1.1 Determine which logon program is used by the UNIX operating

system. Four versions of the logon program can be linked to /bin/login.
The most secure version, login.secure, requires a password for the
superuser account (root) and restricts the superuser account to log on
only at the operator console.
53.1.1.2 Review the table in the /etc/initab file, which contains the instructions
for the init utility. The init utility executes at the system startup that
calls the getty utility for each terminal. The getty utility displays a
logon prompt and accepts the user name. Next, the getty utility calls
the logon utility and validates the user name and password, and starts
the shell to accept commands from the user.
53.1.1.3 Determine if the getty and logon utilities are replaced by other
utilities/ programs. These other programs/utilities are called by the init
utility.
53.1.1.4 Verify if NIS or NIS+ is used to authenticate users to the system.
Confirm that the contents of the distributed password file cannot be
viewed by unprivileged users (command ypcat passwd). Note:
Implementation of NIS will allow all users with command line access
into the system to view encrypted user account passwords. Ensure that
the NIS domain name used cannot be easily found by an attacker.

© 2009 ISACA. All rights reserved. Page 42

 UNIX/LINUX Operating System Security Audit/Assurance Program
COSO

Control Environment
COBIT Reference Issue

Risk Assessment
Hyper-link Cross- Comments

Control Activities
Audit/Assurance Program Step Cross-

Information and
Communication
reference reference

Monitoring
53.1.1.5 Operation of an NIS server should be viewed as a security risk.
Deactivate NIS. Migrate to secure solutions such as NIS+ or
LDPAS/Kerberos.
53.2 Source code and compilers not present on production servers
Audit/assurance objectives: Source code and compilers should not be present on the
production servers to prevent unauthorized modification of the operating system kernel or
applications.
PO8.3
54. Source code
AI2.5 X
Control: Storing source code on production servers is prohibited.
AI3.2
54.1.1.1 Verify that the operating system source code is not stored on the
server. Search the drives for instances of the operating system source
code.
55. Compilers AI3.2 X
Control: C and other compilers are removed from production servers.
55.1.1.1 Verify that all compilers have been removed from production servers.
55.2 Core Files
Audit/assurance objective: Core files (generated during a memory dump after a system crash)
should be secured if they contain sensitive information.
55.2.1 Core File Security 55.2.8 55.2.9
55.2.2
55.2.3
55.2.4
55.2.5
55.2.6
55.2.7
Control: Core files containing passwords, etc. are secure.
6.4.1.1 Verify that no core files are retained on the server after they are no 55.2.16 55.2.17
55.2.10
55.2.11
55.2.12
55.2.13
55.2.14
55.2.15
longer needed.
55.3 Routine operating system configuration changes/updates
Audit/assurance objective: Only operating systems configuration changes and
updates/upgrades that are authorized, evaluated and prioritized should enter the change
process.

© 2009 ISACA. All rights reserved. Page 43

 UNIX/LINUX Operating System Security Audit/Assurance Program
COSO

Control Environment
COBIT Reference Issue

Risk Assessment
Hyper-link Cross- Comments

Control Activities
Audit/Assurance Program Step Cross-

Information and
Communication
reference reference

Monitoring
56. Management of operating system configuration changes
Control: Management classifies, reviews and approves operating system change AI6.2
X X X X
requests. This control ensures that management has considered the changes in the AI6.4
queue and has approved the changes.
56.1.1.1 Obtain the enterprise’s standards, procedures, and guidelines for
identifying, classifying and approving operating system configuration
change requests.
56.1.1.2 Based on reviewing documentation, interview and observation:
56.1.1.2.1 Determine if a process exists to classify operating system
change requests as an infrastructure change.
56.1.1.2.2 Determine if a process exists to perform a risk assessment
that is focused on the impact of the change on other systems
or applications.
56.1.1.2.3 Determine if there is a process to perform an impact
analysis on changes to determine the affect the change
would have on the integrity and availability of the business
process.
56.1.1.2.4 Determine if the appropriate approvers within IT operations
and IT technical support (operating systems responsibility)
document their approval of the change.
56.1.1.2.5 Determine if the change requests are subject to
prioritization.
56.1.1.2.6 If prioritization is performed, determine if appropriate
management regularly authorizes the priority.
57. Test objective: To verify compliance with the review and prioritization
DS5.5
process.
57.1.1.1.1 Using the move ticket, obtain a population of requested
changes.
© 2009 ISACA. All rights reserved. Page 44
 UNIX/LINUX Operating System Security Audit/Assurance Program
COSO

Control Environment
COBIT Reference Issue

Risk Assessment
Hyper-link Cross- Comments

Control Activities
Audit/Assurance Program Step Cross-

Information and
Communication
reference reference

Monitoring
57.1.1.1.2 When making the selection, select representative samples
resulting from emergency requests, systems requests and
problem tickets.
57.1.1.1.3 For each selected ticket:
57.1.1.1.3.1 Trace the move request to the originating request
(systems request, problem ticket or emergency
request, if different).
57.1.1.1.3.2 Determine if there was a risk assessment
performed for impact on other systems or
applications.
57.1.1.1.3.3 Determine if there was an impact analysis
performed to determine the effect the change
would have on the enterprise.
57.1.1.1.3.4 Determine if the appropriate approvers within IT
operations and IT technical support (operating
systems responsibility) document their approval
of the change
57.1.1.1.3.5 Determine if the change request had been subject
to prioritization.
57.1.1.1.3.6 If prioritization had been granted, determine if
appropriate management had authorized the
priority.

58. Completion of review and testing prior to implementation AI3.2

Control: Program changes require signoffs by the appropriate management AI6.2 X X X
prior to implementation. DS5.5

58.1.1.1 Determine that the sign-off process prior to a change moving into
production includes the following:
© 2009 ISACA. All rights reserved. Page 45
 UNIX/LINUX Operating System Security Audit/Assurance Program
COSO

Control Environment
COBIT Reference Issue

Risk Assessment
Hyper-link Cross- Comments

Control Activities
Audit/Assurance Program Step Cross-

Information and
Communication
reference reference

Monitoring
58.1.1.1.1 Technical support indicating completion of testing, quality
assurance, documentation.
58.1.1.1.2 IT operations, indicating acceptance of documentation,
scheduling changes, backup changes, runtime changes, etc.
58.1.1.1.3 Information security, indicating acceptance of information
security changes.
59. Test Objective: To verify the sign-off process to ensure that all signoffs
were completed before implementation and that the appropriate DS5.5
personnel approved the move.
59.1.1.1.1 Obtain a sample of operating system implementation
tickets.
59.1.1.1.2 For each ticket, verify timely approvals by:
59.1.1.1.2.1 Technical support function, indicating
completion of testing, quality assurance,
documentation.
59.1.1.1.2.2 IT operations, indicating acceptance of
documentation, scheduling changes, backup
changes, runtime changes, etc.
59.1.1.1.2.3 Information security, indicating acceptance of
information security changes.

60. Management monitoring of configuration changes/upgrades AI6.4

Control: Management reviews program changes to ensure that only authorized X X
AI6.5
operating system configuration changes are included in the modification process.
60.1.1.1 Determine if a baseline comparison is executed after an update.
60.1.1.2 Determine how management reviews the changes to ensure that only
© 2009 ISACA. All rights reserved. Page 46
 UNIX/LINUX Operating System Security Audit/Assurance Program
COSO

Control Environment
COBIT Reference Issue

Risk Assessment
Hyper-link Cross- Comments

Control Activities
Audit/Assurance Program Step Cross-

Information and
Communication
reference reference

Monitoring
authorized changes have been implemented.
61. Test objective: To verify the process of comparing authorized changes to DS5.5
completed changes:
61.1.1.1.1 Select a sample of operating system configuration
changes/upgrades.
61.1.1.1.2 Obtain the request supporting the change.
61.1.1.1.3 Based on the request, obtain an understanding of the
changes required.
61.1.1.1.4 Review the baseline comparison to determine if the changes
requested were processed.
61.2 Emergency changes
Audit/assurance objective: Emergency operating system changes should be controlled,
documented and initiated only in true emergencies.
62. Emergency priority
Control: Changes using the emergency change procedure should be initiated only AI6.3 X X X
for changes where time is of the essence.
62.1.1.1 Through interviews, observation and review of documentation,
determine if there is a definition for an emergency change.
63. Emergency testing DS5.5
Control: Emergency changes are adequately tested before being placed into X X
AI6.3
production
63.1.1.1 Through interviews, observation and review of documentation,
determine the process used to review testing procedures before an
emergency change is accepted into production.
63.1.1.2 Review the existence of test results and management review. DS5.5

© 2009 ISACA. All rights reserved. Page 47

 UNIX/LINUX Operating System Security Audit/Assurance Program
COSO

Control Environment
COBIT Reference Issue

Risk Assessment
Hyper-link Cross- Comments

Control Activities
Audit/Assurance Program Step Cross-

Information and
Communication
reference reference

Monitoring
64. Emergency change approval
Control: Emergency changes are authorized by appropriate management before AI6.3 X X X
being placed into production.
64.1.1.1 Through interviews, observation and review of documentation,
determine the process used to authorize emergency moves to
production. Differentiate between minor and major enhancements,
operating system and configuration files.
64.1.1.1.1 Ensure programming function, indicating completion of
testing, quality assurance, documentation.
64.1.1.1.2 Review with user, indicating satisfactory user acceptance
test and approval and knowledge of implementation date.
64.2 Change management governance
Control objective: Change management process is subject to management oversight to ensure
consistent and timely processing of changes.
65. Operating system change summaries
Control: Management receives timely reports summarizing change management AI6.4 X X X X
activities, key performance indicators and escalation of issues requiring
management attention.
65.1.1.1 Identify the reports that management receive and, the frequency and
scope of the reports.
65.1.1.2 Determine if service level agreements (SLA) are in use. If so, verify
that the reports summarize SLA attainment and/or deficiency.
65.1.1.3 Determine the escalation process for change management processes
operating outside of normal conditions.
66. SYSTEM BACKUP AND RECOVERY
66.1 System backups
Audit/assurance objective: The systems should be backed up on a regular basis in a manner to
© 2009 ISACA. All rights reserved. Page 48
 UNIX/LINUX Operating System Security Audit/Assurance Program
COSO

Control Environment
COBIT Reference Issue

Risk Assessment
Hyper-link Cross- Comments

Control Activities
Audit/Assurance Program Step Cross-

Information and
Communication
reference reference

Monitoring
minimize data loss in the event of hardware or software failure, or a physical incident.
67. Backup procedures
Control: Appropriate backup procedures are in effect to ensure backups are DS11.5 X
scheduled to be executed automatically, and include the necessary files to ensure
the capability of restoring the operating system and applications.
67.1.1.1 Verify that relevant crontab file (usually root) contains the backup
procedure.
67.1.1.2 Compare this information with the contents of the file that is a text file
that contains a list of file systems and partitions, which are backed up
during a full backup. This file provides the command with a
description of the systems in order to execute a proper backup and
restore.
67.1.1.3 Determine that the backup program runs at least nightly.
67.1.1.4 Determine the frequency with which the backup script is run.
67.1.1.5 Verify that the frequency is appropriate for the operation being
audited.
67.1.1.6 Examine the backup scripts.
67.1.1.7 Determine that the relevant files are backed up, including critical
system files.

67.1.1.8 Determine if the sync utility is periodically executed to copy disk

buffers to disk so that loss of data is kept to a minimum in the event of
system failure. This can be verified by reviewing the contents of the
table stored in the \etc\crontab file that lists the programs executed
periodically. These programs are executed by the cron utility as
background processes.
67.1.1.9 If the backup process records a status log (e.g., backup success or
© 2009 ISACA. All rights reserved. Page 49
 UNIX/LINUX Operating System Security Audit/Assurance Program
COSO

Control Environment
COBIT Reference Issue

Risk Assessment
Hyper-link Cross- Comments

Control Activities
Audit/Assurance Program Step Cross-

Information and
Communication
reference reference

Monitoring
failure), verify that this is regularly reviewed by the system
administrator (i.e., daily).
67.1.1.10 Determine if write verify passes are made to enhance the reliability
of the new archive. Write verify passes will occur by default unless
they are disabled.
68. Backup generations DS11.5 X
Control: Multiple generations of the files are maintained off site.
68.1.1.1 Determine how many generations of the server files are retained. At
least one month of files should be retained. If financial information is
stored on the server, the backup must subscribe to regulatory
requirements.
69. Test objective: To verify that the backup generations are adequate for the DS5.5
business processes executed on the server.
69.1.1.1.1 Select several servers of varying business criticality.
69.1.1.1.2 Determine the number of generations backup maintained
for each server.
69.1.1.1.3 Determine if the generations are adequate for the business
priority.
69.1.1.1.4 Determine if the offsite rotation of backups is adequate.
70. Backup testing DS5.5
X
Control: Backup tapes are subject to test restores to ensure readability. DS11.5

70.1.1.1 Determine if there is a program to restore backups on a rotational basis

and verify the accuracy and readability of the data contained therein.

© 2009 ISACA. All rights reserved. Page 50

 UNIX/LINUX Operating System Security Audit/Assurance Program

VII. Maturity Assessment COBIT Control Practice Assessed Target Reference Comments
Maturity Maturity Hyperlink
AI6.1 Change assessment
The maturity Standards and
is anProcedures
opportunity for the reviewer to assess the maturity of the processes reviewed. Based on the results of audit/assurance review, and the
1. Develop, document and promulgate a changelevel
reviewer’s observations, assign a maturity management framework
to each of that specifies
the following C OBITthe policies
control and
practices.
processes, including:
• Roles and responsibilities
• Classification and prioritization of all changes based on business risk
• Assessment of impact
• Authorization and approval of all changes by the business process owners and IT
• Tracking and status of changes
• Impact on data integrity (e.g., all changes to data files being made under system and application control
rather than by direct user intervention)
2. Establish and maintain version control over all changes.
3. Implement roles and responsibilities that involve business process owners and appropriate technical IT
functions. Ensure appropriate segregation of duties.
4. Establish appropriate record management practices and audit trails to record key steps in the change
management process. Ensure timely closure of changes. Elevate and report to management changes that are
not closed in a timely fashion.
5. Consider the impact of contracted services providers (e.g., of infrastructure, application development and
shared services) on the change management process. Consider integration of organizational change
management processes with change management processes of service providers. Consider the impact of the
organizational change management process on contractual terms and SLAs.
AI6.2 Impact Assessment, Prioritization and Authorization
1. Develop a process to allow business process owners and IT to request changes to infrastructure, systems or
applications. Develop controls to ensure that all such changes arise only through the change request
management process.
2. Categorize all requested changes (e.g., infrastructure, operating systems, networks, application systems,
purchased/packaged application software).
3. Prioritize all requested changes. Ensure that the change management process identifies both the business and
technical needs for the change. Consider legal, regulatory and contractual reasons for the requested change.
4. Assess all requests in a structured fashion. Ensure that the assessment process addresses impact analysis on
infrastructure, systems and applications. Consider security, legal, contractual and compliance implications of
the requested change. Consider also interdependencies amongst changes. Involve business process owners in
the assessment process, as appropriate.
5. Ensure that each change is formally approved by business process owners and IT technical stakeholders, as
appropriate.
AI6.4 Change Status Tracking and Reporting
1. Ensure that a documented process exists within the overall change management process to declare, assess,
authorize and record an emergency change.
© 2009 ISACA. All rights reserved. Page 51
 UNIX/LINUX Operating System Security Audit/Assurance Program
COBIT Control Practice Assessed Target Reference Comments
Maturity Maturity Hyperlink
2. Ensure that emergency changes are processed in accordance with the emergency change element of the
formal change management process.
3. Ensure that all emergency access arrangements for changes are appropriately authorized, documented and
revoked after the change has been applied.
4. Conduct a post-implementation review of all emergency changes, involving all concerned parties. The
review should consider implications for aspects such as further application system maintenance, impact on
development and test environments, application software development quality, documentation and manuals,
and data integrity.
DS5.3 Identity Management
1. Establish and communicate policies and procedures to uniquely identify, authenticate and authorize access
mechanisms and access rights for all users on a need-to-know/need-to-have basis, based on predetermined
and preapproved roles. Clearly state accountability of any user for any action on any of the systems and/or
applications involved.
2. Ensure that roles and access authorization criteria for assigning user access rights take into account:
• Sensitivity of information and applications involved (data classification)
• Policies for information protection and dissemination (legal, regulatory, internal policies and contractual
requirements)
• Roles and responsibilities as defined within the enterprise
• The need-to-have access rights associated with the function
• Standard but individual user access profiles for common job roles in the organization
• Requirements to guarantee appropriate segregation of duties
3. Establish a method for authenticating and authorizing users to establish responsibility and enforce access
rights in line with sensitivity of information and functional application requirements and infrastructure
components, and in compliance with applicable laws, regulations, internal policies and contractual
agreements.
4. Define and implement a procedure for identifying new users and recording, approving and maintaining
access rights. This needs to be requested by user management, approved by the system owner and
implemented by the responsible security person.
5. Ensure that a timely information flow is in place that reports changes in jobs (i.e., people in, people out,
people change). Grant, revoke and adapt user access rights in co-ordination with human resources and user
departments for users who are new, who have left the organization, or who have changed roles or jobs.

© 2009 ISACA. All rights reserved. Page 52

 UNIX/LINUX Operating System Security Audit/Assurance Program
COBIT Control Practice Assessed Target Reference Comments
Maturity Maturity Hyperlink
DS5.4 User Account Management
1. Ensure that access control procedures include but are not limited to:
• Using unique user IDs to enable users to be linked to and held accountable for their actions
• Awareness that the use of group IDs results in the loss of individual accountability and are permitted only
when justified for business or operational reasons and compensated by mitigating controls. Group IDs must
be approved and documented.
• Checking that the user has authorization from the system owner for the use of the information system or
service, and the level of access granted is appropriate to the business purpose and consistent with the
organizational security policy
• A procedure to require users to understand and acknowledge their access rights and the conditions of such
access
• Ensuring that internal and external service providers do not provide access until authorization procedures
have been completed
• Maintaining a formal record, including access levels, of all persons registered to use the service
• A timely and regular review of user IDs and access rights
2. Ensure that management reviews or reallocates user access rights at regular intervals using a formal process.
User access rights should be reviewed or reallocated after any job changes, such as transfer, promotion,
demotion or termination of employment. Authorizations for special privileged access rights should be
reviewed independently at more frequent intervals.
DS9.1 Configuration Repository and Baseline
1. Implement a configuration repository to capture and maintain configuration management items. The
repository should include hardware; application software; middleware; parameters; documentation;
procedures; and tools for operating, accessing and using the systems, services, version numbers and
licencing details.
2. Implement a tool to enable the effective logging of configuration management information within a
repository.
3. Provide a unique identifier to a configuration item so the item can be easily tracked and related to physical
asset tags and financial records.
4. Define and document configuration baselines for components across development, test and production
environments, to enable identification of system configuration at specific points in time (past, present and
planned).
5. Establish a process to revert to the baseline configuration in the event of problems, if determined appropriate
after initial investigation.
6. Install mechanisms to monitor changes against the defined repository and baseline. Provide management
reports for exceptions, reconciliation and decision making.
DS9.2 Identification and Maintenance of Configuration Items
1. Define and implement a policy requiring all configuration items and their attributes and versions to be
identified and maintained.
© 2009 ISACA. All rights reserved. Page 53
 UNIX/LINUX Operating System Security Audit/Assurance Program
COBIT Control Practice Assessed Target Reference Comments
Maturity Maturity Hyperlink
2. Tag physical assets according to a defined policy. Consider using an automated mechanism, such as
barcodes.
3. Define a policy that integrates incident, change and problem management procedures with the maintenance
of the configuration repository.
4. Define a process to record new, modified and deleted configuration items and their relative attributes and
versions. Identify and maintain the relationships between configuration items in the configuration repository.
5. Establish a process to maintain an audit trail for all changes to configuration items.
6. Define a process to identify critical configuration items in relationship to business functions (component
failure impact analysis).
7. Record all assets—including new hardware and software, procured or internally developed—within the
configuration management data repository.
8. Define and implement a process to ensure that valid licenses are in place to prevent the inclusion of
unauthorized software.
DS9.3 Configuration Integrity Review
1. To validate the integrity of configuration data, implement a process to ensure that configuration items are
monitored. Compare recorded data against actual physical existence, and ensure that errors and deviations
are reported and corrected.
2. Using automated discovery tools where appropriate, reconcile actual installed software and hardware
periodically against the configuration database, license records and physical tags.
3. Periodically review against the policy for software usage the existence of any software in violation or in
excess of current policies and license agreements. Report deviations for correction.

© 2009 ISACA. All rights reserved. Page 54

 UNIX/LINUX Operating System Security Audit/Assurance Program

VIII. Assessment Maturity vs. Target Maturity—UNIX/LINUX Only

© 2009 ISACA. All rights reserved. Page 55