This is the accessible text file for GAO report number GAO-08-1029G
entitled 'Federal Information System Controls Audit Manual (FISCAM):
Exposure Draft' which was released on July 31, 2008.
This text file was formatted by the U.S. Government Accountability
Office (GAO) to be accessible to users with visual impairments, as part
of a longer term project to improve GAO products' accessibility. Every
attempt has been made to maintain the structural and data integrity of
the original printed product. Accessibility features, such as text
descriptions of tables, consecutively numbered footnotes placed at the
end of the file, and the text of agency comment letters, are provided
but may not exactly duplicate the presentation or format of the printed
version. The portable document format (PDF) file is an exact electronic
replica of the printed version. We welcome your feedback. Please E-mail
your comments regarding the contents or accessibility features of this
document to Webmaster@gao.gov.
This is a work of the U.S. government and is not subject to copyright
protection in the United States. It may be reproduced and distributed
in its entirety without further permission from GAO. Because this work
may contain copyrighted images or other material, permission from the
copyright holder may be necessary if you wish to reproduce this
material separately.
United States Government Accountability Office:
GAO:
July 2008:
Federal Information System Controls Audit Manual (FISCAM):
Exposure Draft:
GAO-08-1029G:
United States Government Accountability Office:
Washington, DC 20548:
July 2008:
To Audit Officials, Agency CIOs, And Others Interested In Federal
Information System Controls Auditing And Reporting:
This letter transmits the exposure draft of the Government
Accountability Office (GAO) Federal Information System
Controls Audit Manual (FISCAM) for your review and comment.
The FISCAM presents a methodology for performing information
system (IS) control[Footnote 1] audits of federal and other governmental
entities in accordance with professional standards, and was
originally issued in January 1999. We have updated the FISCAM
for significant changes affecting IS audits.
GAO would like to thank the President’s Council on Integrity and
Efficiency (PCIE) and the state auditor community for their
significant input into the development of this revised FISCAM.
Summary of Major Revisions to FISCAM:
The exposure draft revisions reflect changes in (1) technology
used by government entities, (2) audit guidance and control
criteria issued by the National Institute of Standards and
Technology (NIST), and (3) generally accepted government auditing
standards (GAGAS), as presented in Government Auditing Standards (also
known as the “Yellow Book”). [Footnote 2] The Federal Information
System Controls Audit Manual (FISCAM) provides a methodology for
performing information system (IS) control audits in accordance with
GAGAS. However, at the discretion of the auditor, this manual may be
applied on other than GAGAS audits. As defined in GAGAS, IS controls
consist of those internal controls that are dependent on information
systems processing and include general controls and application
controls. This manual focuses on evaluating the effectiveness of such
general and application controls. This manual is intended for both (1)
auditors to assist them in understanding the work done by IS controls
specialists, and (2) IS controls specialists to plan and perform the IS
controls audit.
In addition, the FISCAM is consistent with the GAO/PCIE Financial Audit
Manual (FAM). Also, the FISCAM control activities are consistent with
and have been mapped to the NIST Special Publication 800-53.
The FISCAM, which is consistent with NIST and other criteria, is
organized to facilitate effective and efficient IS control audits.
Specifically, the methodology in the FISCAM incorporates:
* Top-down, risk based approach that considers materiality and
significance in determining effective and efficient audit procedures.
* Evaluation of entitywide controls and their effect on audit risk.
* Evaluation of general controls and their pervasive impact on business
process application controls.
* Evaluation of security management at all levels (entitywide, system,
and business process application levels).
* A control hierarchy (control categories, critical elements, and
control activities) to assist in evaluating the significance of
identified IS control weaknesses.
* Groupings of control categories consistent with the nature of the
risk.
* Experience gained in GAO’s performance and review of IS control
audits, including field testing the concepts in this revised FISCAM.
As discussed above, this manual is organized in a hierarchical
structure to assist the auditor in performing the IS controls audit.
Chapter 3 (general controls) and Chapter 4 (business process
application level controls) contain several control categories, which
are groupings of related controls pertaining to similar types of risk.
For each control category, the manual identifies critical
elements—tasks that are essential for establishing adequate controls
within the category. For each critical element, there is a discussion
of the associated control activities that are generally necessary to
achieve the critical element, as well as related potential control
techniques and suggested audit procedures. This hierarchical structure
facilitates the auditor’s audit planning and the auditor’s analysis of
identified control weaknesses.
Because control activities are generally necessary to achieve the
critical elements, they are generally relevant to a GAGAS audit unless
the related control category is not relevant, the audit scope is
limited, or the auditor determines that, due to significant IS control
weaknesses, it is not necessary to assess the effectiveness of all
relevant IS controls. Within each relevant control activity, the
auditor should identify control techniques implemented by the entity
and determine whether the control techniques, as designed, are
sufficient to achieve the control activity, considering IS audit risk
and the audit objectives. The auditor may be able to determine whether
control techniques are sufficient to achieve a particular control
activity without evaluating and testing all of the control techniques.
Also, depending on IS audit risk and the audit objectives, the nature
and extent of control techniques necessary to achieve a particular
control objective will vary.
If sufficient, the auditor should determine whether the control
techniques are implemented (placed in operation) and are operating
effectively. Also, the auditor should evaluate the nature and extent of
testing performed by the entity. Such information can assist in
identifying key controls and in assessing risk, but the auditor should
not rely on testing performed by the entity in lieu of appropriate
auditor testing. If the control techniques implemented by the entity,
as designed, are not sufficient to address the control activity, or the
control techniques are not effectively implemented as designed, the
auditor should determine the effect on IS controls and the audit
objectives.
Throughout the updated FISCAM, revisions were made to reflect today’s
networked environment. The nature of IS risks continues to evolve.
Protecting government computer systems has never been more important
because of the complexity and interconnectivity of systems (including
Internet and wireless), the ease of obtaining and using hacking tools,
the steady advances in the sophistication and effectiveness of attack
technology, and the emergence of new and more destructive attacks.
In addition, the FISCAM includes narrative that is designed to provide
a basic understanding of the methodology (Chapter 2), general controls
(Chapter 3) and business process application controls (Chapter 4)
addressed by the FISCAM. The narrative may also be used as a reference
source by the auditor and the IS control specialist. More experienced
auditors and IS control specialists may find it unnecessary to
routinely refer to such narrative in performing IS control audits. For
example, a more experienced auditor may have sufficient knowledge,
skills, and abilities to directly use the control tables in Chapters 2
and 3 (which are summarized in Appendices II and III).
A summary of significant changes to FISCAM is presented on the
pages 6-10.
Instructions for Commenting on the Exposure Draft:
The exposure draft of FISCAM is available only in electronic form at
[hyperlink, http://www.gao.gov/cgi-bin/getrpt?rptno=GAO-08-1029G] on
GAO’s Web page. We request comments from federal audit officials, CIOs,
financial managers, the public accounting profession, and other
interested parties. Please associate your comments with specific
references to section, paragraph, and page number. Also, please
provide the rationale for your comments and proposed changes,
along with suggested revised language. Please send your comments
electronically to FISCAM@gao.gov no later than September 5, 2008.
We anticipate that the final version of FISCAM will be issued in the
fall of 2008 for use in conducting fiscal year 2009 federal financial
statement audits.
Should you need additional information, please call Greg Wilshusen
at (202) 512-6244; David Irvin at (214) 777-5643; or me at (202) 512-
7439.
Sincerely yours,
Signed by:
Robert F. Dacey:
Chief Accountant:
U.S. Government Accountability Office:
Attachment and enclosures:
Summary Of Significant Changes To The FISCAM:
Chapter 1:
* Expanded purpose:
- provide guidance for performing effective and efficient Information
System (IS) controls audits, either alone or as part of a performance
audit, a financial audit, or an attestation engagement, including
communication of any identified IS control weaknesses; and;
- inform financial, performance, and attestation auditors about IS
controls and related audit issues, so that they can (1) plan their work
in accordance with Generally Accepted Government Auditing Standards
(GAGAS) and (2) integrate the work of IS controls specialists with
other aspects of the financial or performance audit or attestation
engagement.
* Conformity with July 2007 Revision to Government Auditing Standards –
(“Yellow Book”)(GAGAS), including information system control
categories.
* Conformity with AICPA auditing standards, including new risk
standards.
* An overall framework of IS control objectives (see summary on pages
11-13).
Chapter 2:
* IS audit methodology consistent with GAGAS and FAM, including
planning, testing, and reporting phases (see a summary of methodology
steps on pages 14-15), which incorporates:
- A top-down, risk-based evaluation that considers materiality and
significance in determining effective and efficient audit procedures
(the auditor determines which IS control techniques are relevant to the
audit objectives and which are necessary to achieve the control
activities; generally, all control activities are relevant unless the
audit scope is limited or the auditor determines that, due to
significant IS control weaknesses, it is not necessary to test all
relevant IS controls).
- An evaluation of entitywide IS controls and their effect on audit
risk, and therefore on the extent of audit testing (effective
entitywide IS controls can reduce audit risk, while ineffective
entitywide IS controls result in increased audit risk and generally are
a contributory cause of IS control weaknesses at the system and
business process application levels)—NIST SP 800-53 principally relates
to controls at the system and application level.
- An evaluation of general controls and their pervasive impact on
business process application controls (effective general controls
support the effectiveness of business process application controls,
while ineffective general controls generally render business process
application controls ineffective).
- An evaluation of security management at all levels of control --
entitywide, system (includes networks, operating systems, and
infrastructure applications), and business process application levels.
- A control hierarchy (control categories, critical elements, and
control activities) to assist in evaluating the significance of
identified IS control weaknesses (if a critical element is not
achieved, the respective control category is not likely to be achieved;
if one of the nine control categories are not effectively achieved, IS
controls are ineffective, unless other factors sufficiently reduce the
risk).
- Groupings of control categories consistent with the nature of the
risk.
* Change from “installation level” general controls to “system level”
general controls to reflect the logically networked structure of
today’s systems
* IS controls audit documentation guidance for each audit phase ??
Additional audit considerations that may affect an IS audit, including:
- information security risk factors;
- automated audit tools;
- sampling techniques.
Chapter 3:
* Reorganized general control categories, consistent with GAGAS:
- Security management;
- broadened to consider statutory requirements and best practices;
- Access controls - restructured to incorporate system software,
eliminate redundancies, and facilitate IS auditing in a networked
environment:
System boundaries;
Identification and authentication;
User authorization;
Sensitive system resources;
Audit and monitoring;
Physical security.
- Configuration management - broadened to include network components
and applications;
- Segregation of Duties - relatively unchanged;
- Contingency Planning - updated for new terminology.
* Updated general control activities that (1) are consistent with
current NIST and OMB information security guidance (particularly NIST
Special Publication 800-53) including references/mapping of each
critical element to such guidance, and (2) consider new IS risks and
audit experience.
Chapter 4:
* Audit methodology and IS controls for business process applications
that (1) are consistent with GAGAS and current NIST and OMB information
security guidance (particularly NIST Special Publication 800-53)
including references/mapping to such guidance, and (2) consider new IS
risks and audit experience:
- Application security (formerly general controls at the application
level);
- Business process controls related to the validity, completeness,
accuracy, and confidentiality of transactions and data during
application processing:
Transaction data input;
Transaction data processing;
Transaction data output;
Master file data setup and maintenance;
* Interface controls;
* Data management systems controls.
Appendices:
* Expanded appendices to support IS audits;
- Updated information system controls audit planning checklist;
- Tables for summarizing the results of the IS audit;
- Mapping of FISCAM to NIST Special Publication 800-53;
- Knowledge, skills, and abilities needed to perform IS audits;
- Scope of an IS audit in support of a financial audit;
- Entity’s use of service organizations;
- Application of FISCAM to Single Audits;
- Application of FISCAM to FISMA;
- Complete FISMA text;
- Information System Controls Audit Documentation;
- Updated Glossary.
[End of section]
Information System Controls Objectives:
General Controls:
Security Management:
Controls provide reasonable assurance that security management is
effective, including effective:
* security management program;
* periodic assessments and validation of risk;
* security control policies and procedures;
* security awareness training and other security-related personnel
issues;
* periodic testing and evaluation of the effectiveness of information
security policies, procedures, and practices;
* remediation of information security weaknesses, and;
* security over activities performed by external third parties.
Access Controls:
Controls provide reasonable assurance that access to computer resources
(data, equipment, and facilities) is reasonable and restricted to
authorized individuals, including effective:
* protection of information system boundaries;
* identification and authentication mechanisms;
* authorization controls;
* protection of sensitive system resources;
* audit and monitoring capability, including incident handling, and;
* physical security controls.
Configuration Management:
Controls provide reasonable assurance that changes to information
system resources are authorized and systems are configured and operated
securely and as intended, including effective:
* configuration management policies, plans, and procedures;
* current configuration identification information;
* proper authorization, testing, approval, and tracking of all
configuration changes;
* routine monitoring of the configuration;
* updating software on a timely basis to protect against known
vulnerabilities, and;
* documentation and approval of emergency changes to the configuration.
Segregation of Duties:
Controls provide reasonable assurance that incompatible duties are
effectively segregated, including effective:
* segregation of incompatible duties and responsibilities and related
policies, and;
* control of personnel activities through formal operating procedures,
supervision, and review.
Contingency Planning:
Controls provide reasonable assurance that contingency planning (1)
protects information resources and minimizes the risk of unplanned
interruptions and (2) provides for recovery of critical operations
should interruptions occur, including effective:
* assessment of the criticality and sensitivity of computerized
operations and identification of supporting resources;
* steps taken to prevent and minimize potential damage and
interruption;
* comprehensive contingency plan, and;
* periodic testing of the contingency plan, with appropriate
adjustments to the plan based on the testing.
[End of section]
Business Process Application Controls:
Completeness – controls provide reasonable assurance that all
transactions that occurred are input into the system, accepted for
processing, processed once and only once by the system, and properly
included in output.
Accuracy – controls provide reasonable assurance that transactions are
properly recorded, with correct amount/data, and on a timely basis (in
the proper period); key data elements input for transactions are
accurate; data elements are processed accurately by applications that
produce reliable results; and output is accurate.
Validity – controls provide reasonable assurance (1) that all recorded
transactions and actually occurred (are real), relate to the
organization, are authentic, and were properly approved in accordance
with management’s authorization; and (2) that output contains only
valid data.
Confidentiality – controls provide reasonable assurance that
application data and reports and other output are protected against
unauthorized access.
[End of section]
IS Audit Methodology Steps:
Plan the Information System Controls Audit:
* Understand the Overall Audit Objectives and Related Scope of the
Information System Controls Audit.
* Understand the Entity’s Operations and Key Business Processes.
* Obtain a General Understanding of the Structure of the Entity’s
Networks.
* Identify Key Areas of Audit Interest.
* Assess Information System Risk on a Preliminary Basis.
* Identify Critical Control Points.
* Obtain a Preliminary Understanding of Information System Controls.
* Perform Other Audit Planning Procedures;
- Relevant Laws and Regulations;
- Consideration of the Risk of Fraud;
- Audit Resources;
- Multiyear Testing Plans;
- Communication with Entity Management and Those Charged with
Governance;
- Service Organizations;
- Using the Work of Others;
- Audit Plan.
Perform Information System Controls Audit Tests:
* Understand Information Systems Relevant to the Audit Objectives.
* Determine which IS Control Techniques are Relevant to the Audit
Objectives.
* For each Relevant IS Control Technique Determine Whether it is
Suitably Designed to Achieve the Critical Activity and has been
Implemented.
* Perform Tests to Determine Whether such Control Techniques are
Operating Effectively.
* Identify Potential Weaknesses in IS Controls and Consider
Compensating Controls.
Report Audit Results:
* Evaluate the Effects of Identified IS Control Weaknesses:
- Financial Audits, Attestation Engagements, and Performance Audits.
* Consider Other Audit Reporting Requirements and Related Reporting
Responsibilities.
[End of section]
Exposure Draft Contents:
Chapter 1:
Introduction:
1.0 Chapter 1 Overview:
1.1 Purpose and Anticipated Users of the Manual:
1.2 Nature of Information System Controls:
1.3 Determining the Nature and Extent of Audit Procedures:
1.4 Organization of This Manual:
1.4.1 Appendices:
Chapter 2. Performing the Information System Controls Audit:
2.0 Introduction:
2.1 Planning the Information System Controls Audit:
2.1.1 Overview:
2.1.2 Understand the Overall Audit Objectives and Related Scope of the
Information System Controls:
2.1.3 Understand the Entity’s Operations and Key Business Processes:
2.1.4 Obtain a General Understanding of the Structure of the Entity’s
Networks:
2.1.5 Identify Key Areas of Audit Interest:
2.1.6 Assess Information System Risk on a Preliminary Basis:
2.1.7 Identify Critical Control Points:
2.1.8 Obtain a Preliminary Understanding of Information System
Controls:
2.1.9 Perform Other Audit Planning Procedures:
2.1.9.A Relevant Laws and Regulations:
2.1.9.B Consideration of the Risk of Fraud:
2.1.9.C Audit Resources:
2.1.9.D Multiyear Testing Plans:
2.1.9.E Communication with Entity Management and Those Charged with
Governance:
2.1.9.F Service Organizations:
2.1.9.G Using the Work of Others:
2.1.9.H Audit Plan:
2.1.10 Documentation of Planning Phase:
2.2 Perform Information System Controls Audit Tests:
2.2.1 Overview:
2.2.2 Appropriateness of Control Tests:
2.2.3 Documentation of Control Testing Phase:
2.3 Report Audit Results:
2.3.1 Financial Audits and Attestation Engagements:
2.3.2 Performance Audits:
2.3.3 Other Audit Reporting Considerations:
2.3.4 Related Reporting Responsibilities:
2.3.5 Documentation of Reporting Phase:
2.4 Documentation:
2.5 Other Information System Controls Audit Considerations:
2.5.1 Additional IS Risk Factors:
2.5.1.A Defense-In-Depth Strategy:
2.5.1.B Web Applications:
2.5.1.C ERP Systems:
2.5.1.D Interface Controls:
2.5.1.E Database Management Systems:
2.5.1.F Network-based Access Control Systems:
2.5.1.G Workstations:
35 2.5.2 Automated Audit Tools:
2.5.3 Use of Sampling Techniques:
Chapter 3. Evaluating and Testing General Controls:
3.0 Introduction:
3.1. Security Management (SM):
Security Program Guidance:
Security Management Critical Elements:
Critical Element SM-1: Establish a Security Management Program:
SM-1.1. The security management program is adequately documented,
approved, and up-to-date:
SM-1.2. A security management structure has been established:
SM-1.3. Information security responsibilities are clearly assigned:
SM-1.4. Subordinate security plans are documented, approved, and kept
up-to-date:
SM-1.5. An inventory of systems is developed, documented, and kept up-
to-date:
Control Techniques and Suggested Audit Procedures for Critical Element
SM-1:
Critical Element SM-2. Periodically assess and validate risks:
Control Techniques and Suggested Audit Procedures for Critical Element
SM-2:
Critical Element SM-3. Document security control policies and
procedures:
Control Techniques and Suggested Audit Procedures for Critical Element
SM-3:
Critical Element SM-4. Implement effective security awareness and other
security-related personnel policies:
SM-4.1 Ensure that resource owners, system administrators, and users
are aware of security policies:
SM-4.2. Hiring, transfer, termination, and performance policies address
security:
SM-4.3. Employees have adequate training and expertise:
Control Techniques and Suggested Audit Procedures for Critical Element
SM-4:
Critical Element SM-5. Monitor the effectiveness of the security
program:
Control Techniques and Suggested Audit Procedures for Critical Element
SM-5:
Critical Element SM-6. Effectively Remediate Information Security
Weaknesses:
Control Techniques and Suggested Audit Procedures for Critical Element
SM-6:
Critical Element SM-7. Ensure that activities performed by external
third parties are adequately secure:
Control Techniques and Suggested Audit Procedures for Critical Element
SM-7:
3.2. Access Controls (AC):
Critical Element AC-1. Adequately protect information system
boundaries:
AC-1.1. Appropriately control connectivity to system resources:
AC-1.2. Appropriately control network sessions:
Control Techniques and Suggested Audit Procedures for Critical Element
AC-1:
Critical Element AC-2. Implement effective identification and
authentication mechanisms:
AC-2.1. Users are appropriately identified and authenticated:
Control Techniques and Suggested Audit Procedures for Critical Element
AC-2:
Critical Element AC-3. Implement effective authorization controls:
AC-3.1. User accounts are appropriately controlled:
AC-3.2. Processes and services are adequately controlled:
Critical Element AC-4. Adequately protect sensitive system resources:
AC-4.1. Access to sensitive system resources is restricted and
monitored:
AC-4.2. Adequate media controls have been implemented:
AC-4.3. Cryptographic controls are effectively used:
Control Techniques and Suggested Audit Procedures for Critical Element
AC-4:
Critical Element AC-5. Implement an effective audit and monitoring
capability:
AC-5.1. An effective incident response program is documented and
approved:
AC-5.2. Incidents are effectively identified and logged:
AC-5.3. Incidents are properly analyzed and appropriate actions taken:
Control Techniques and Suggested Audit Procedures for Critical Element
AC-5:
Critical Element AC-6. Establish adequate physical security controls:
AC-6.1. Establish a physical security management program based on risk:
AC-6.2. Establish adequate perimeter security based on risk:
AC-6.3. Establish adequate security at entrances and exits based on
risk:
AC-6.4. Establish adequate interior security based on risk:
AC-6.5. Adequately protect against emerging threats based on risk:
Control Techniques and Suggested Audit Procedures for Critical Element
AC-6:
3.3. Configuration Management (CM):
Critical Element CM-1. Develop and document CM policies, plans, and
procedures:
Control Techniques and Suggested Audit Procedures for Critical Element
CM-1:
Critical Element CM-2. Maintain current configuration identification
information:
Control Techniques and Suggested Audit Procedures for Critical Element
CM-2:
Critical Element CM-3. Properly authorize, test, approve, track, and
control all configuration changes:
Control Techniques and Suggested Audit Procedures for Critical Element
CM-3:
Critical Element CM-4. Routinely monitor the configuration:
Control Techniques and Suggested Audit Procedures for Critical Element
CM-4:
Critical Element CM-5. Update software on a timely basis to protect
against known vulnerabilities:
Vulnerability scanning:
Patch management:
Virus protection:
Emerging threats:
Noncurrent software:
Software usage:
Control Techniques and Suggested Audit Procedures for Critical Element
CM-5:
Critical Element CM-6. Appropriately document and approve emergency
changes to the configuration:
Control Techniques and Suggested Audit Procedures for Critical Element
CM-6:
3.4. Segregation of Duties (SD):
Critical Element SD-1. Segregate incompatible duties and establish
related policies:
SD-1.1. Incompatible duties have been identified and policies
implemented to segregate these duties:
SD-1.2. Job descriptions have been documented:
SD-1.3. Employees understand their duties and responsibilities:
Control Techniques and Suggested Audit Procedures for Critical Element
SD-1:
Critical Element SD-2. Control personnel activities through formal
operating procedures, supervision, and review:
SD-2.1. Formal procedures guide personnel in performing their duties:
SD-2.2. Active supervision and review are provided for all personnel:
Control Techniques and Suggested Audit Procedures for Critical Element
SD-2:
3.5. Contingency Planning (CP):
Critical Element CP-1. Assess the criticality and sensitivity of
computerized operations and identify supporting resources:
CP-1.1. Critical data and operations are identified and prioritized:
CP-1.2. Resources supporting critical operations are identified and
analyzed:
CP-1.3. Emergency processing priorities are established:
Control Techniques and Suggested Audit Procedures for Critical Element
CP-1:
Critical Element CP-2. Take steps to prevent and minimize potential
damage and interruption:
CP-2.1. Data and program backup procedures have been implemented:
CP-2.2. Adequate environmental controls have been implemented:
CP-2.3. Staff have been trained to respond to emergencies:
CP-2.4. Effective hardware maintenance, problem management, and change
management help prevent unexpected interruptions:
Control Techniques and Suggested Audit Procedures for Critical Element
CP-2:
Critical Element CP-3. Develop and document a comprehensive contingency
plan:
CP-3.1. An up-to-date contingency plan is documented:
CP-3.2. Arrangements have been made for alternate data processing,
storage, and telecommunications facilities:
Control Techniques and Suggested Audit Procedures for Critical Element
CP-3:
Critical Element CP-4. Periodically test the contingency plan and
adjust it as appropriate:
CP-4.1. The plan is periodically tested:
CP-4.2. Test results are analyzed and the contingency plan is adjusted
accordingly:
Control Techniques and Suggested Audit Procedures for Critical Element
CP-4:
Chapter 4. Evaluating and Testing Business Process Application
Controls:
4.0 Overview:
4.0.1 The Auditor’s Consideration of Business Process Control
Objectives:
4.0.2 Steps in Assessing Business Process Application Level Controls:
4.0.3 Plan the Information System Controls Audit of Business Process
Application Level Controls:
4.0.3.A Understand the overall audit objectives and related scope of
the business process application control assessment:
4.0.3.B Understand the entity’s operations and key business processes:
4.0.3.C Obtain a general understanding of the structure of the entity’s
networks:
4.0.3.D Identify key areas of audit interest (files, applications,
systems, locations):
4.0.3.E Assess information system risk on a preliminary basis:
4.0.3.F Identify critical control points:
4.0.3.G Obtain a preliminary understanding of application controls:
4.0.3.H Perform other audit planning procedures:
4.0.4 Perform Information System Controls Audit Tests of Business
Process Application Level Controls:
4.0.5 Report Audit Results:
4.1. Application Level General Controls (AS):
Critical Element AS-1. Implement effective application security
management:
Establish an application security plan:
Periodically assess and validate application security risks:
Document and implement application security policies and procedures:
Implement effective security awareness and other security-related
personnel policies:
Monitor the effectiveness of the security program:
Effectively remediate information security weaknesses:
Implement effective security-related personnel policies:
Adequately secure, document, and monitor external third party
activities:
Critical Element AS-2. Implement effective application access controls:
Adequately protect application boundaries: Implement effective
identification and authentication mechanisms:
Implement effective authorization controls:
Adequately protect sensitive application resources:
Implement an effective audit and monitoring capability:
Establish adequate physical security controls:
Critical Element AS-3 – Implement effective application configuration
management:
Critical Element – AS-4: Segregate user access to conflicting
transactions and activities and monitor segregation:
Critical Element – AS-5: Implement effective application contingency
planning:
Assess the criticality and sensitivity of the application:
Take steps to prevent and minimize potential damage and interruption:
Develop and document an application contingency plan:
5 Periodically test the contingency plan and adjust it as appropriate:
4.2. Business Process Controls (BP):
Master Data vs. Transaction Data:
Business Process Control Objectives:
NIST Guidance:
Business Process Control Critical Elements:
BP-1 Transaction Data Input is complete, accurate, valid, and
confidential (Transaction Data Input Controls):
Implement an effective transaction data strategy and design:
Establish Input Preparation (approval and review) Policies and
Procedures:
Build Data Validation and Edits within the Application:
Implement Effective Auditing and Monitoring Capability:
BP-2 Transaction Data Processing is complete, accurate, valid, and
confidential (Transaction Data Processing Controls):
Formal Transaction Processing Procedures:
Effective auditing and monitoring capability:
BP-3 Transaction data output is complete, accurate, valid, and
confidential (Transaction Data Output Controls):
Implementing a reporting strategy:
Establishing security and controls over report generation and
distribution:
BP-4 Master Data Setup and Maintenance is Adequately Controlled:
Implementing an effective design of master data elements:
Establishing master data maintenance procedures, including approval,
review, and adequate support for changes to master data:
Implementing an effective auditing and monitoring capability:
4.3. Interface Controls (IN):
Critical Element IN-1: Implement an effective interface strategy and
design:
Critical Element IN-2: Implement effective interface processing
procedures:
4.4 Data Management System Controls (DA):
Key Concepts - Database Management Systems:
Authentication/Authorization:
SQL Commands:
System, Role, Object Privileges:
Stored Procedures:
Key Concepts – Middleware:
Middleware Controls:
Key Concepts – Cryptography:
Key Concepts – Data Warehouse, Data Reporting and Data Extraction
Software:
Segregation of Duties:
Control Activities:
Appendices:
Appendix I - Information System Controls Audit Planning Checklist:
Appendix II - Tables for Summarizing Work Performed in Evaluating and
Testing General and Business Process Application Controls:
Appendix III - Tables for Assessing the Effectiveness of General and
Business Process Application Controls:
Appendix IV - Mapping of FISCAM to SP 800-5:
Appendix V - Knowledge, Skills, and Abilities Needed to Perform
Information System Controls Audits:
Appendix VI - Scope of an Information System Controls Audit in Support
of a Financial Audit:
Appendix VII - Entity’s Use of Service Organizations:
Appendix VIII - Application of FISCAM to Single Audits:
Appendix IX - Application of FISCAM to FISMA:
Appendix X - Federal Information Security Management Act of 2002
(FISMA):
Appendix XI - Information System Controls Audit Documentation:
Appendix XII - Glossary:
Appendix XIII – Bibliography:
Figures:
Figure 1. An Example of Typical Networked Systems:
Figure 2: Example of Router Control Dependencies:
Figure 3. Example of Network Schematic Describing System Weaknesses:
Figure 4. Layered Approach to Network Security:
Figure 5. Layered Security Mitigates the Risk of Individual
Cybersecurity Threats:
Figure 6: Steps in Assessing IT Systems Controls in a Financial
Statement Audit:
Figure 7: Steps for Each Significant Application in Assessing
Information System Controls in a Financial Statement Audit:
Tables:
Table 1: Control Categories Applicable at Different Levels of Audit:
Table 2. General Control Categories Applicable at Different Levels of
Audit:
Table 3. Critical Elements for Security Management:
Table 4. Security Controls to Include in System Security Plans:
Table 5. Control Techniques and Suggested Audit Procedures for Critical
Element SM-1: Establish a security management program:
Table 6. NIST Impact Definitions for Security Objectives:
Table 7 Control Techniques and Suggested Audit Procedures for Critical
Element SM-2: Periodically assess and validate risks:
Table 8. Control Techniques and Suggested Audit Procedures for Critical
Element SM-3: Document security control policies and procedures:
Table 9. Control Techniques and Suggested Audit Procedures for Critical
Element SM-4: Implement effective security awareness and other security-
related personnel policies:
Table 10. Types of Security Testing:
Table 11. Control Techniques and Suggested Audit Procedures for
Critical Element SM-5: Monitor the effectiveness of the security
program:
Table 12. Control Techniques and Suggested Audit Procedures for
Critical Element SM-6: Effectively remediate information security
weaknesses:
Table 13. Examples of Agency-Identified Risks to Federal Systems and
Data Resulting from Reliance on Contractors:
Table 14. Control Techniques and Suggested Audit Procedures for
Critical Element SM-7: Ensure that activities performed by external
third parties are adequately secure:
Table 15. Critical Elements for Access Control:
Table 16. Control Techniques and Suggested Audit Procedures for
Critical Element AC-1: Adequately protect information system
boundaries:
Table 17. Control Techniques and Suggested Audit Procedures for
Critical Element AC-2: Implement effective identification and
authentication mechanisms:
Table 18. Control Techniques and Suggested Audit Procedures for
Critical Element AC-3: Implement effective authorization controls:
Table 19. Control Techniques and Suggested Audit Procedures for
Critical Element AC-4: Adequately protect sensitive system resources:
Table 20. Control Techniques and Suggested Audit Procedures for
Critical Element AC-5: Implement an effective audit and monitoring
capability:
Table 21. Control Techniques and Suggested Audit Procedures for
Critical Element AC-6: Establish adequate physical security controls:
Table 22. Critical Elements for Configuration Management:
Table 23. Control Techniques and Suggested Audit Procedures for
Critical Element CM-1: Develop and document CM policies, plans, and
procedures:
Table 24. Control Techniques and Suggested Audit Procedures for
Critical Element CM-2: Maintain current configuration identification
information:
Table 25. Control Techniques and Suggested Audit Procedures for
Critical Element CM-3: Properly authorize, test, approve, and track all
configuration:
Table 26. Control Techniques and Suggested Audit Procedures for
Critical Element CM-4: Routinely monitor the configuration:
Table 27. Control Techniques and Suggested Audit Procedures for
Critical Element CM-5: Update software on a timely basis to protect
against known vulnerabilities:
Table 28. Control Techniques and Suggested Audit Procedures for
Critical Element CM-6: Appropriately document and approve emergency
changes to the configuration:
Table 29. Critical Elements for Segregation of Duties:
Table 30. Control Techniques and Suggested Audit Procedures for
Critical Element SD-1: Segregate incompatible duties and establish
related policies:
Table 31. Control Techniques and Suggested Audit Procedures for
Critical Element SD-2: Control personnel activities through formal
operating procedures, supervision, and review:
Table 32. Critical Elements for Contingency Planning:
Table 33. Control Techniques and Suggested Audit Procedures for
Critical Element CP-1: Assess the criticality and sensitivity of
computerized operations and identify supporting resources:
Table 34. Control Techniques and Suggested Audit Procedures for
Critical Element CP-2: Take steps to prevent and minimize potential
damage and interruption:
Table 35: Types of Contingency-Related Plans:
Table 36. Control Techniques and Suggested Audit Procedures for
Critical Element CP-3: Develop and document a comprehensive contingency
plan:
Table 37. Control Techniques and Suggested Audit Procedures for
Critical Element CP-4: Periodically test the contingency plan and
adjust it as appropriate:
Table 38. General and Application Control Categories Applicable at
Different Levels of Audit:
Table 39. Control Techniques and Suggested Audit Procedures for
Critical Element AS-1: Implement effective application security
management:
Table 40. Control Techniques and Suggested Audit Procedures for
Critical Element AS-2: Implement effective application access controls:
Table 41. Control Techniques and suggested audit procedures for AS-3 -
Implement Effective Application Configuration Management:
Table 42. Control Techniques and Suggested Audit Procedures For
Critical Element AS-4 - Segregate user access to conflicting
transactions and activities and monitor segregation.:
Table 43. Control Techniques And Suggested Audit Procedures For
Critical Element AS-5 – Maintain an effective contingency planning
program:
Table 44. Control Techniques And Suggested Audit Procedures For
Critical Element BP-1 - Transaction Data Input is complete, accurate,
valid, and confidential:
Table 45. Control Techniques And Suggested Audit Procedures For
Critical Element BP-2 Transaction Data Processing is complete,
accurate, valid, and confidential:
Table 46. Control Techniques And Suggested Audit Procedures For
Critical Element BP-3 Transaction data output is complete, accurate,
valid, and confidential:
Table 47. Control Techniques And Suggested Audit Procedures For
Critical Element BP-4 Master Data Setup and Maintenance is Adequately
Controlled:
Table 48. Control Techniques and Suggested Audit Procedures for
Critical Element IN-1: Implement an effective interface strategy and
design:
Table 49. Control Techniques And Suggested Audit Procedures For
Critical Element Critical Element Critical Element IN-2: Implement
effective interface processing procedures:
Table 50. Control Techniques and Suggested Audit Procedures for
Critical Element DA-1 - Implement an effective data management system
strategy and design:
[End of section]
Chapter 1. Introduction:
1.0 Chapter 1 Overview:
This manual provides a methodology for performing information system
(IS) control audits in accordance with “generally accepted government
auditing standards” (GAGAS), as presented in Government Auditing
Standards (also known as the “Yellow Book”).[Footnote 3] However, at
the discretion of the auditor, this manual may be applied on other than
GAGAS audits. As defined in GAGAS, IS controls consist of those
internal controls that are dependent on information systems processing
and include general controls and application controls. This manual
focuses on such general and application controls.
As computer technology has advanced, federal agencies and other
government entities have become dependent on computerized information
systems to carry out their operations and to process, maintain, and
report essential information. Virtually all federal operations are
supported by automated systems and electronic data, and agencies would
find it difficult, if not impossible, to carry out their missions and
account for their resources without these information assets. Hence,
ineffective IS controls can result in significant risk to a broad array
of government operations and assets. For example:
* resources, such as payments and collections, could be lost or stolen;
* computer resources could be used for unauthorized purposes, including
the launching of attacks on others;
* sensitive information, such as taxpayer data, Social Security
records, medical records, other personally identifiable information,
and proprietary business information, could be inappropriately added,
deleted, read, copied, disclosed, or modified for purposes such as
espionage, identity theft, or other types of crime;
* critical operations, such as those supporting national defense and
emergency services, could be disrupted;
* data could be modified or destroyed for purposes of fraud or
disruption; and;
* agency/entity missions could be undermined by embarrassing incidents
that result in diminished confidence in an agency’s ability to conduct
operations and fulfill its responsibilities.
The nature of IS risks continues to evolve. Protecting government
computer systems has never been more important because of the
complexity and interconnectivity of systems (including Internet and
wireless), the ease of obtaining and using hacking tools, the steady
advances in the sophistication and effectiveness of attack technology,
and the emergence of new and more destructive attacks.
As a result, the reliability of computerized data and of the systems
that process, maintain, and report these data is a major concern to
managements of government entities and their auditors. Auditors may
need to evaluate the effectiveness of information system controls over
data supporting financial statements or data used to analyze specific
program costs and outcomes. In addition, auditors may be called on to
evaluate the effectiveness of IS controls to help reduce the risk due
to errors, fraud, and other illegal acts and disasters or other
incidents that cause the systems to be unavailable.
Figure 1 illustrates the potential complexity of a typical networked
infrastructure. Such infrastructures are built upon multiple hosts,
including desktop personal computers (PCs), servers, and mainframes.
Data communications links and network devices such as routers, hubs,
and switches enable the hosts to communicate with one another through
local area networks (LANs) within entities. Wide area networks (WANs)
connect LANs at different geographical locations. Moreover, entities
are typically connected to the Internet.
Figure 1. An Example of Typical Networked Systems:
[See PDF for image]
This figure illustrates an example of typical networked systems.
Included in the networked systems are the following components:
General public;
Remote users;
Business partners;
Internet;
External routers;
Intrusion detection system;
External switch;
Firewall;
Public access servers;
VPN concentrator;
Dial-in access server;
Internal router and switch;
Wireless access point;
Local Area Networks (desktop PCs, printers, internal servers);
Gateway;
Mainframe;
Routers;
Wide Area Network;
Interorganization;
Intraorganization.
Source: GAO analysis and Microsoft Vision (TM).
[End of figure]
1.1 Purpose and Anticipated Users of the Manual:
This manual describes (1) an audit methodology for assessing the
effectiveness of IS controls, and (2) the IS controls that auditors
evaluate when assessing the confidentiality, integrity, and
availability of information and information systems. The Federal
Information System Controls Audit Manual (FISCAM) is designed to be
used primarily on financial and performance audits and attestation
engagements performed in accordance with “generally accepted government
auditing standards” (GAGAS), as presented in Government Auditing
Standards (also known as the “Yellow Book”). However, at the discretion
of the auditor, this manual may be applied on other than GAGAS audits.
This manual is intended for both (1) auditors performing financial and
performance audits and attestation engagements to assist them in
understanding the work done by IS controls specialists, and (2) IS
controls specialists to plan and perform the IS controls audit. Federal
and other government auditors may use this manual. It is not an
auditing standard and it would be incorrect to refer to it as a
standard. Its purposes are to:
* provide guidance for performing effective and efficient IS controls
audits, either alone or as part of a performance audit, a financial
audit, or an attestation engagement, including communication of any
identified IS control weaknesses; and;
* inform financial, performance, and attestation auditors about IS
controls and related audit issues, so that they can (1) plan their work
in accordance with GAGAS and (2) integrate the work of IS controls
specialists with other aspects of the financial or performance audit or
attestation engagement.
The auditor should determine whether IS controls are relevant to the
audit objectives. IS controls generally are relevant to a financial
audit, as financial information is usually processed by information
systems. For financial audits, the GAO/PCIE Financial Audit Manual
(FAM)[Footnote 4] provides a framework for evaluating IS controls as
part of a financial audit. The scope of an information system controls
audit in support of a financial audit is summarized in Appendix VI. For
performance audits, GAGAS 7.27 states that auditors should determine
which audit procedures related to information system controls are
needed to obtain sufficient, appropriate evidence to support the audit
findings and conclusions.[Footnote 5] This GAGAS paragraph provides
factors that may assist auditors in making this determination.
This manual lists specific control activities and techniques and
related suggested audit procedures. These are described at a high level
and assume some level of expertise for an auditor to perform these
audit procedures effectively. Accordingly, the auditor should develop
more detailed audit steps based on the specific software and control
techniques employed by the entity, the audit objectives, and
significant areas of audit interest.
In addition, the FISCAM includes narrative that is designed to provide
a basic understanding of the methodology (Chapter 2), general controls
(Chapter 3) and business process application controls (Chapter 4)
addressed by the FISCAM. The narrative may also be used as a reference
source by the auditor and the IS control specialist. More experienced
auditors and IS control specialists may find it unnecessary to
routinely refer to such narrative in performing IS control audits. For
example, a more experienced auditor may have sufficient knowledge,
skills, and abilities to directly use the control tables in Chapters 2
and 3 (which are summarized in Appendices II and III).
Further, many of the suggested audit procedures start with the word
“review.” The intent of such language is for the auditor to do more
than simply look at the subject to be reviewed. Rather, a critical
evaluation is envisioned, in which the auditor uses professional
judgment and experience and undertakes the task with a certain level of
skepticism, critical thinking, and creativity.
Although IS controls audit work, especially control testing, is
generally performed by an IS controls specialist, financial or
performance auditors with appropriate training, expertise, and
supervision may undertake specific tasks in this area of the audit.
Throughout this manual, the term “auditor” means either (1) an IS
controls specialist or (2) a financial or performance auditor working
in consultation with or under the supervision of an IS controls
specialist. The FISCAM may be used by other staff that possess adequate
IT competence. GAGAS requires that staff assigned to conduct an audit
must collectively possess the technical knowledge, skills, and
experience necessary to be competent for the type of work being
performed. See Appendix V for additional information on the knowledge,
skills, and abilities needed to perform information system control
audits.
The following terms are used in the FISCAM to describe the degree of
responsibility they impose on auditors and audit organizations:
* must - Auditors and audit organizations are required to comply with
this unconditional requirement in all cases in which the circumstances
exist to which the unconditional requirement applies. The term “must”
is used only in FISCAM when the related requirement is specified as a
“must” in GAGAS.
* should - Auditors and audit organizations are also required to comply
with this presumptively mandatory requirement in all cases in which the
circumstances exist to which the presumptively mandatory requirement
applies; however, in rare circumstances, auditors and audit
organizations may depart from a presumptively mandatory requirement
provided they document their justification for the departure and how
the alternative procedures performed in the circumstances were
sufficient to achieve the objectives of the presumptively mandatory
requirement. The term “should” is used when (1) the related requirement
is specified as a “should” in GAGAS, or (2) performance is deemed
necessary to meet GAGAS evidence requirements for an IS controls audit.
* generally should – Although optional, compliance with this policy is
strongly encouraged.
* may – Compliance with this procedure or action is optional. It is
descriptive rather than required. It is explanatory material that
provides further explanation and guidance on the professional
requirements or identifies and describes other procedures or actions
relating to auditors’ or audit organizations’ activities.
When these or similar terms are used to describe management or entity
actions (rather than actions of the auditor or audit organization), the
general meaning of the terms is intended. If the entity does not comply
with a “must” or “should”, the auditor should assess the impact of the
noncompliance on the effectiveness of related IS controls.
1.2 Nature of Information System Controls:
An evaluation of IS controls generally includes both general and
business process application controls (also called application
controls). The entity must have effective general and business process
application controls to achieve the appropriate confidentiality,
integrity, and availability of critical information and information
systems.
Information system (IS) controls consist of those internal controls
that are dependent on information systems processing and include
general controls (entitywide, system, and business process application
levels), business process application controls (input, processing,
output, master file, interface, and data management system controls),
and user controls[Footnote 6] (controls performed by people interacting
with information systems). General and business process application
controls are always IS controls. A user control is an IS control if its
effectiveness depends on information systems processing or the
reliability (accuracy, completeness, and validity) of information
processed by information systems. Conversely, a user control is not an
IS control if its effectiveness does not depend on information systems
processing or the reliability of information processed by information
systems.
General controls are the policies and procedures that apply to all or a
large segment of an entity’s information systems and help ensure their
proper operation. Examples of primary objectives for general controls
are to safeguard data, protect business process application programs,
and ensure continued computer operations in case of unexpected
interruptions. General controls are applied at the entitywide, system,
and business process application levels. The effectiveness of general
controls is a significant factor in determining the effectiveness of
business process application controls, which are applied at the
business process application level. Without effective general controls,
business process application controls can generally be rendered
ineffective by circumvention or modification. For example, automated
edits designed to preclude users from entering unreasonably large
dollar amounts in a payment processing system can be an effective
application control. However, this control is not effective (cannot be
relied on) if the general controls permit unauthorized program
modifications that might allow some payments to be exempted from the
edits or unauthorized changes to be made to data files after the edit
is performed. GAGAS paragraph 7.23 discusses the following types of
general controls: security management, logical and physical access,
configuration management, segregation of duties, and contingency
planning. Chapter 3 discusses the general controls in an IS controls
audit and provides more detail on the critical elements of each type of
general control.
Business process application controls are directly related to
individual computerized applications. They help ensure that
transactions are complete, accurate, valid, and confidential. Business
process application controls include (1) programmed control techniques,
such as automated edits, and (2) manual follow-up of computer-generated
reports, such as reviews of reports identifying rejected or unusual
items. GAGAS paragraph 7.23 defines application controls, or business
controls, as those controls that help ensure the validity,
completeness, accuracy, and confidentiality of transactions and data
during application processing. Chapter 4 discusses the business process
application level controls in an IS controls audit and provides more
detail on the critical elements of each type of business process
application control.
The overall framework of IS control objectives presented in the FISCAM
can be viewed in different ways. One way to summarize the objectives is
presented below.
General Controls:
Security Management:
Controls provide reasonable assurance that security management is
effective, including effective:
* security management program,
* periodic assessments and validation of risk,
* security control policies and procedures,
* security awareness training and other security-related personnel
issues,
* periodic testing and evaluation of the effectiveness of information
security policies, procedures, and practices,
* remediation of information security weaknesses, and;
* security over activities performed by external third parties.
Access Controls:
Controls provide reasonable assurance that access to computer resources
(data, equipment, and facilities) is reasonable and restricted to
authorized individuals, including effective:
* protection of information system boundaries,
* identification and authentication mechanisms,
* authorization controls,
* protection of sensitive system resources,
* audit and monitoring capability, including incident handling, and;
* physical security controls.
Configuration Management:
Controls provide reasonable assurance that changes to information
system resources are authorized and systems are configured and operated
securely and as intended, including effective:
* configuration management policies, plans, and procedures,
* current configuration identification information,
* proper authorization, testing, approval, and tracking of all
configuration changes,
* routine monitoring of the configuration,
* updating software on a timely basis to protect against known
vulnerabilities, and,
* documentation and approval of emergency changes to the configuration.
Segregation of Duties:
Controls provide reasonable assurance that incompatible duties are
effectively segregated, including effective:
* segregation of incompatible duties and responsibilities and related
policies, and;
* control of personnel activities through formal operating procedures,
supervision, and review.
Contingency Planning:
Controls provide reasonable assurance that contingency planning (1)
protects information resources and minimizes the risk of unplanned
interruptions and (2) provides for recovery of critical operations
should interruptions occur, including effective:
* assessment of the criticality and sensitivity of computerized
operations and identification of supporting resources,
* steps taken to prevent and minimize potential damage and
interruption,
* comprehensive contingency plan, and;
* periodic testing of the contingency plan, with appropriate
adjustments to the plan based on the testing.
Business Process Application Controls:
Completeness – controls provide reasonable assurance that all
transactions that occurred are input into the system, accepted for
processing, processed once and only once by the system, and properly
included in output.
Accuracy – controls provide reasonable assurance that transactions are
properly recorded, with correct amount/data, and on a timely basis (in
the proper period); key data elements input for transactions are
accurate; data elements are processed accurately by applications that
produce reliable results; and output is accurate.
Validity – controls provide reasonable assurance (1) that all recorded
transactions and actually occurred (are real), relate to the
organization, are authentic, and were properly approved in accordance
with management’s authorization; and (2) that output contains only
valid data.
Confidentiality – controls provide reasonable assurance that
application data and reports and other output are protected against
unauthorized access.
1.3 Determining the Nature and Extent of Audit Procedures:
The nature, timing, and extent of audit procedures performed to assess
IS controls vary, depending on the audit objectives, the nature and
extent of audit risks and other factors. Factors that can affect the
nature, timing, and extent of audit procedures include the nature and
complexity of the entity’s information systems, the entity’s control
environment, and particular data and applications that are significant
to the financial statements or operations of the entity. As
appropriate, the IS controls specialist, and the financial,
performance, or attestation auditor generally should work cooperatively
to determine the nature, timing, and extent of IS controls audit
procedures.
Inadequate coordination can result in ineffective auditing, for
example, incomplete IS controls audits or improper consideration of the
work performed by the IS controls specialist. When performed as part of
a financial statement audit, an assessment of IS controls is part of a
comprehensive effort to evaluate both the controls over and reliability
of financial reporting. In performance audits and attestation
engagements, the nature and extent of IS controls audit procedures vary
depending on the objectives of the audit.
1.4 Organization of This Manual:
This manual is organized as follows:
* Chapter 2 describes the methodology for performing the IS controls
audit.
* Chapter 3 provides information concerning the five general control
categories, supporting critical elements, critical activities,
potential control techniques, and suggested audit procedures.
* Chapter 4 provides information concerning the four business process
application control level categories, supporting critical elements,
critical activities, potential control techniques, and suggested audit
procedures.
* Appendices provide supplemental information to assist the auditor in
applying the FISCAM methodology.
This manual provides a risk-based approach for performing the
information system controls audit that is consistent with government
auditing standards and the GAO/PCIE Financial Audit Manual (FAM).
[Footnote 7] The FISCAM is consistent with GAGAS and, where
appropriate, the FISCAM discusses the applicable GAGAS requirements.
Each of the nine control categories (five general control categories
and four business process level control categories) represents a
grouping of related controls having similar types of risk. For each
category, this manual discusses the key underlying concepts, associated
risks if the controls in the category are ineffective, and the critical
elements that should be achieved for IS controls to be effective.
This organization structure facilitates the following:
* Audit planning: Related audit steps can be grouped and broken down
into three primary levels: the entitywide level, the system level, and
the application level.
* Evaluation of findings: The effectiveness of IS controls can be
evaluated by control technique, control activity, critical element, and
control category.
* Audit report drafting: Findings can be summarized by control category
and critical element.
To evaluate IS controls, the auditor should use appropriate criteria
that are relevant to the audit objectives. For audits of federal
entities, criteria are provided by the Federal Information Security
Management Act (FISMA) (see Appendix X) and, for non-national security
systems, National Institute of Standards and Technology (NIST) Special
Publication (SP) 800-53, Recommended Security Controls for Federal
Information Systems and other NIST guidance. The Office of Management
and Budget (OMB) requires federal entities to apply other NIST guidance
to non-national security systems. Also, other sources, such as vendor
recommended IS practices and other generally accepted IS resources, may
provide criteria.[Footnote 8] In addition, NIST is responsible for
developing minimum security standards and guidelines that are
complementary with standards and guidelines employed for the protection
of national security systems and information contained in such systems.
FISMA states that standards and guidelines for national security
systems shall be developed, prescribed, enforced, and overseen as
otherwise authorized by law and as directed by the President. Also,
FISMA states that the head of each agency operating or exercising
control of a national security system shall be responsible for ensuring
that the agency:
* provides information security protections commensurate with the risk
and magnitude of the harm resulting from the unauthorized access, use,
disclosure, disruption, modification, or destruction of the information
contained in such system;
* implements information security policies and practices as required by
standards and guidelines for national security systems, issued in
accordance with law and as directed by the President; and;
* complies with the requirements of FISMA.
GAO has consulted with NIST, as provided for in FISMA, and the FISCAM
is mapped to NIST SP 800-53. Appendix IV provides a mapping of the two
documents. In addition, each critical element includes references to
related NIST SP 800-53 controls. NIST SP 800-53 includes a table of the
mapping. Also, to assist auditors, individual FISCAM control activities
reference related NIST SP 800-53 controls. This manual provides
additional narrative to assist the auditor in evaluating IS controls.
In addition, FISCAM incorporates other NIST guidance, including, for
example, NIST SP 800-100, Information Security Handbook: A Guide for
Managers, which includes coverage of programmatic areas such as
information security governance, capital planning and investment
control, and system development life cycle.
The FISCAM, which is consistent with NIST and other criteria, is
organized to facilitate effective and efficient IS controls audits.
Specifically, the methodology in the FISCAM incorporates:
* A top-down, risk-based evaluation that considers materiality and
significance in determining effective and efficient audit procedures
(the auditor determines which IS control techniques are relevant to the
audit objectives and which are necessary to achieve the control
activities; generally, all control activities are relevant unless the
audit scope is limited or the auditor determines that, due to
significant IS control weaknesses, it is not necessary to test all
relevant IS controls).
* An evaluation of entitywide IS controls and their effect on audit
risk, and therefore on the extent of audit testing (effective
entitywide IS controls can reduce audit risk, while ineffective
entitywide IS controls result in increased audit risk and generally are
a contributory cause of IS control weaknesses at the system and
business process application levels)—NIST SP 800-53 principally relates
to controls at the system and application level.
* An evaluation of general controls and their pervasive impact on
business process application controls (effective general controls
support the effectiveness of business process application controls,
while ineffective general controls generally render business process
application controls ineffective).
* An evaluation of security management at all levels of control
(entitywide, system, and business process application levels).
* A control hierarchy (control categories, critical elements, and
control activities) to assist in evaluating the significance of
identified IS control weaknesses (if a critical element is not
achieved, the respective control category is not likely to be achieved;
if one of the nine control categories are not effectively achieved, IS
controls are ineffective, unless other factors sufficiently reduce the
risk).
* Groupings of control categories consistent with the nature of the
risk.
* Experience gained in GAO’s performance and review of IS control
audits, including field testing the concepts in this revised FISCAM.
As discussed above, this manual is organized in a hierarchical
structure to assist the auditor in performing the IS controls audit.
Chapter 3 (general controls) and Chapter 4 (business process
application level controls) contain several control categories, which
are groupings of related controls pertaining to similar types of risk.
For each control category, the manual identifies critical
elements—tasks that are essential for establishing adequate controls
within the category. For each critical element, there is a discussion
of the associated objectives, risks, and control activities, as well as
related potential control techniques and suggested audit procedures.
This hierarchical structure facilitates the auditor’s audit planning
and analysis of identified control weaknesses.
Because control activities are generally necessary to achieve the
critical elements, they are generally relevant to a GAGAS audit unless
the related control category is not relevant, the audit scope is
limited, or the auditor determines that, due to significant IS control
weaknesses, it is not necessary to assess the effectiveness of all
relevant IS controls. Within each relevant control activity, the
auditor should identify control techniques implemented by the entity
and determine whether the control techniques, as designed, are
sufficient to achieve the control activity, considering IS audit risk
and the audit objectives. The auditor may be able to determine whether
control techniques are sufficient to achieve a particular control
activity without evaluating and testing all of the control techniques.
Also, depending on IS audit risk and the audit objectives, the nature
and extent of control techniques necessary to achieve a particular
control objective will vary.
If sufficient, the auditor should determine whether the control
techniques are implemented (placed in operation) and are operating
effectively. Also, the auditor should evaluate the nature and extent of
testing performed by the entity. Such information can assist in
identifying key controls and in assessing risk, but the auditor should
not rely on testing performed by the entity in lieu of appropriate
auditor testing. As discussed later in this section, if the control
techniques implemented by the entity, as designed, are not sufficient
to address the control activity, or the control techniques are not
effectively implemented as designed, the auditor should determine the
effect on IS controls and the audit objectives.
The entity’s management is responsible for implementing an appropriate
system of cost-effective IS controls, including an effective monitoring
program to provide management with reasonable assurance that IS
controls are properly designed and effectively operating. The auditor’s
responsibility is to perform tests of the IS controls and provide
conclusions on the results of such tests to support the audit
objectives.
1.4.1 Appendices:
The appendices to the FISCAM, summarized below, provide additional
information to assist the auditor in performing the IS controls audit.
List of Appendices:
Appendix I:
Description: Information System Controls Audit Planning Checklist;
Purpose: To assist the auditor in requesting relevant background
information.
Appendix II:
Description: Tables for Summarizing Work Performed in Evaluating and
Testing General and Business Process Application Controls;
Purpose: To assist the auditor in summarizing work performed.
Appendix III:
Description: Tables for Assessing the Effectiveness of General and
Business Process Application Controls;
Purpose: To assist the auditor in assessing and reporting on IS
controls.
Appendix IV:
Description: Mapping of FISCAM to SP 800-53;
Purpose: To show correlation between FISCAM critical elements and NIST
SP 800-53.
Appendix V:
Description: Knowledge, Skills, and Abilities Needed to Perform
Information System Controls Audits;
Purpose: Skill sets necessary to perform the IS controls audit.
Appendix VI:
Description: Scope of an Information System Controls Audit in Support
of a Financial Audit;
Purpose: To show relation of FISCAM to relevant FAM sections.
Appendix VII:
Description: Entity’s Use of Service Organizations;
Purpose: Audit issues related to an entity’s use of a service
organization and use of FISCAM as a basis for performing a SAS 70
audit.
Appendix VIII:
Description: Application of FISCAM to Single Audits;
Purpose: Use of FISCAM to assess IS controls over compliance
requirements and financial reporting in connection with a single audit.
Appendix IX:
Description: Application of FISCAM to FISMA;
Purpose: Use of FISCAM for the independent evaluation of a federal
agency’s information security program required by FISMA.
Appendix X:
Description: Federal Information Security Management Act of 2002
(FISMA);
Purpose: Key legislation containing criteria for federal IS controls
audits.
Appendix XI:
Description: Information System Controls Audit Documentation;
Purpose: Summarizes IS controls audit documentation.
Appendix XII:
Description: Glossary;
Purpose: Key terms used in the FISCAM.
Appendix XIII:
Description: Bibliography;
Purpose: List of information sources.
[End of chapter]
Chapter 2. Performing the Information System Controls Audit:
2.0 Introduction:
The information system (IS) controls audit involves the following three
phases:
* Planning: The auditor determines an effective and efficient way to
obtain the evidential matter necessary to achieve the objectives of the
IS controls audit and the audit report. For financial audits, the
auditor develops an audit strategy and an audit plan. For performance
audits, the auditor develops an audit plan.
* Testing: The auditor tests the effectiveness of IS controls that are
relevant to the audit objectives.
* Reporting: The auditor concludes on the effect of any identified IS
control weaknesses on the audit objectives and reports the results of
the audit, including any material weaknesses and other significant
deficiencies.
Appendix VI provides the scope of an IS controls audit in support of a
financial statement audit.
For each of the three phases, the auditor prepares appropriate audit
documentation.
2.1 Planning the Information System Controls Audit:
2.1.1 Overview:
In planning the IS controls audit, the auditor uses the equivalent
concepts of materiality (in financial audits) and significance
[Footnote 9] (in performance audits) to plan both effective and
efficient audit procedures. Materiality and significance are concepts
the auditor uses to determine the planned nature, timing, and extent of
audit procedures. The underlying principle is that the auditor is not
required to spend resources on items of little importance; that is,
those that would not affect the judgment or conduct of a reasonable
user of the audit report, in light of surrounding circumstances. On the
basis of this principle, the auditor may determine that some areas of
the IS controls audit (e.g., specific systems) are not material or
significant, and therefore warrant little or no audit attention.
Materiality and significance include both quantitative and qualitative
factors in relation to the subject matter of the audit. Even though a
system may process transactions that are quantitatively immaterial or
insignificant, the system may contain sensitive information or provide
an access path to other systems that contain information that is
sensitive or otherwise material or significant. For example, an
application that provides public information via a website, if
improperly configured, may expose internal network resources, including
sensitive systems, to unauthorized access. Materiality is more fully
discussed in the FAM in section 230 (Determine Planning, Design, and
Test Materiality), and both terms are discussed further in GAGAS.
Planning occurs throughout the audit as an iterative process. (For
example, based on findings from the testing phase, the auditor may
change the planned audit approach, including the design of specific
tests.) However, planning activities are concentrated in the planning
phase, during which the objectives are to obtain an understanding of
the entity and its operations, including its internal control, identify
significant issues, assess risk, and design the nature, extent, and
timing of audit procedures. To accomplish this, the methodology
presented in this chapter includes guidance to help the auditor do the
following:
* Understand the overall audit objectives and related scope of the IS
controls audit;
* Obtain an understanding of an entity and its operations and key
business processes;
* Obtain a general understanding of the structure of the entity’s
networks;
* Identify key areas of audit interest (files, applications, systems,
locations);
* Assess IS risk on a preliminary basis ? Identify critical control
points (for example, external access points to networks);
* Obtain a preliminary understanding of IS controls;
* Perform other audit planning procedures.
Although each of these areas is discussed separately in this chapter,
they are not generally performed as discrete, sequential steps. For
example, the IS controls specialist may gather information related to
several steps concurrently, such as through interviews with key
information technology (IT) staff or through data requests, or may
perform steps in a different sequence. The auditor performs planning to
determine an effective and efficient way to obtain the evidential
matter necessary to support the objectives of the IS controls audit and
the audit report. The nature and extent of audit planning procedures
varies for each audit depending on several factors, including the
entity’s size and complexity, the auditor’s experience with the entity,
and the auditor’s knowledge of the entity’s operations.
A key to a high-quality audit, the senior members of the audit team
should be involved in planning. The auditor should coordinate with the
entity being audited and, if the IS controls audit is part of another
audit, with senior members of the overall audit team. In addition,
auditors generally should determine the needs of other auditors who
plan to use the work being performed and consult with them in a timely
manner, especially when making decisions involving significant
judgment.
If the IS controls audit is performed as part of a financial audit,
GAGAS require the auditor to obtain an understanding of internal
control over financial reporting sufficient to assess the risk of
material misstatement of the financial statements whether due to error
or fraud, and to design the nature, timing, and extent of further audit
procedures based on that assessment. This includes performing risk
assessment procedures to evaluate the design of controls relevant to an
audit of financial statements and to determine whether they have been
implemented. In obtaining this understanding, the auditor considers how
an entity’s use of information technology (IT) and manual procedures
affect controls relevant to the audit. The auditor’s responsibilities
for considering internal control in a financial audit are described in
more detail in the FAM.
If the IS controls audit is performed as part of a performance audit,
GAGAS[Footnote 10] (para. 7.24) states that when information systems
controls are determined to be significant to the audit objectives,
auditors should then evaluate the design and operating effectiveness of
such controls. This evaluation would include other information systems
controls that impact the effectiveness of the significant controls or
the reliability of information used in performing the significant
controls. Auditors should obtain a sufficient understanding of
information systems controls necessary to assess audit risk and plan
the audit within the context of the audit objectives.
Additionally, GAGAS (para. 7.27) states that auditors should determine
which audit procedures related to information systems controls are
needed to obtain sufficient, appropriate evidence to support the audit
findings and conclusions. It also provides the following factors to
assist the auditor in making this determination:
a. The extent to which internal controls that are significant to the
audit depend on the reliability of information processed or generated
by information systems.
b. The availability of evidence outside the information system to
support the findings and conclusions: It may not be possible for
auditors to obtain sufficient, appropriate evidence without assessing
the effectiveness of relevant information systems controls. For
example, if information supporting the findings and conclusions is
generated by information systems or its reliability is dependent on
information systems controls, there may not be sufficient supporting or
corroborating information or documentary evidence that is available
other than that produced by the information systems.
c. The relationship of information systems controls to data
reliability: To obtain evidence about the reliability of computer-
generated information, auditors may decide to assess the effectiveness
of information systems controls as part of obtaining evidence about the
reliability of the data. If the auditor concludes that information
systems controls are effective, the auditor may reduce the extent of
direct testing of data.
d. Assessing the effectiveness of information systems controls as an
audit objective: When assessing the effectiveness of information
systems controls is directly a part of an audit objective, auditors
should test information systems controls necessary to address the audit
objectives. For example, the audit may involve the effectiveness of
information systems controls related to certain systems, facilities, or
organizations.
2.1.2 Understand the Overall Audit Objectives and Related Scope of the
Information System Controls Audit:
The nature, timing, and extent of IS controls audit procedures vary
depending upon the audit objectives. For example, the IS controls
audit:
* may be performed as part of a financial or performance audit, or may
be performed as a separate engagement;
* may comprehensively address an entire entity, a component, or a
network, or may narrowly target an application, specific technology
(e.g., wireless, operating system, etc.), or location; and/or;
* may include all control objectives or only a subset of control
objectives (e.g., general controls, business process controls, or
selected components of them, such as focusing on an entity’s security
management program).
If achieving the audit objectives does not require an overall
conclusion on the effectiveness of the entity’s IS controls or relates
only to certain components of the entity or a subset of controls, the
auditor’s assessment would not necessarily identify all significant IS
control weaknesses that may exist. For example, a limited review of
controls over a type of operating system may not identify any
significant weaknesses, although there may be very significant
weaknesses in other areas that the auditor is unaware of because the
scope of the audit is limited. Consequently, the auditor should
evaluate the potential limitations of the auditor’s work on the
auditor’s report and the needs and expectations of users. The auditor
may determine that, because the limitations are so significant, the
auditor will (1) communicate the limitations to the management of the
audited entity, those charged with governance, and/or those requesting
the audit, and (2) clearly report such limitations on the conclusions
in the audit report. For example, in reporting on an audit of an
operating system, the auditor may determine that it is appropriate to
clearly report that the scope of the assessment was limited to the
operating system and that, consequently, additional IS control
weaknesses may exist that could impact the effectiveness of IS controls
related to the operating system and to the entity as a whole.
Based on the overall engagement objectives, the auditor should develop
and document the objectives of the IS controls audit. Typical IS
controls audit objectives include the following:
* To support financial statement audits by, for example, assessing the
effectiveness of IS controls related to financial reporting. (Note: The
assessment of IS controls generally occurs during the internal control
phase of a financial statement audit.) This assessment affects the
nature, timing, and extent of financial audit procedures to be
performed, as well as provide timely recommendations for improvements
in IS controls. In addition, it may cover the entire audit year or
relate only to controls at a point in time, such as at the end of the
fiscal year. The scope of an IS controls audit in support of a
financial audit is described further in the FAM and in Appendix VI.
* To supplement IT performance audits by assessing the effectiveness of
security within the context of a broader systems review.
* To support other performance audits, such as assessing data
reliability or how well an information system protects the
confidentiality, integrity, and availability of data and the effect of
this level of protection on program performance.
* To determine the effectiveness of IS controls, not in support of
another audit, so that any risks are identified. Such audits may be
designed to provide a conclusion on the effectiveness of IS controls
and describe any material weaknesses and other significant
deficiencies, or merely describe any IS control weaknesses without an
overall conclusion as to the effectiveness of IS controls.
* To support evaluation of IS controls as required by FISMA.
* To support single audits.
The auditor should also determine and document (such as in an audit
strategy and audit plan) the appropriate scope of the IS controls
audit, including:
* the organizational entities to be addressed (e.g., entitywide,
selected component(s), etc.);
* the breadth of the audit (e.g., overall conclusion on IS control
effectiveness, review of a specific application or technology area,
such as wireless or UNIX, etc.);
* the types of IS controls to be tested: ? general and/or business
process application level controls to be tested, or selected
components; or;
* all levels of the entity’s information systems, or selected levels
(e.g., entitywide, system level, or business process application level,
or selected components of them—for definitions of each level, see the
section below entitled “2.2 Perform Information System Controls Audit
Tests,”).
If the IS controls audit is performed as part of another audit, the
auditor should understand the overall audit objectives and how the IS
controls audit will integrate with the audit. The auditor should reach
a common understanding of objectives with the audit team responsible
for the overall audit.
2.1.3 Understand the Entity’s Operations and Key Business Processes:
The auditor should obtain and document an understanding of the entity
sufficient to plan and perform the audit in accordance with applicable
auditing standards and requirements. In planning the audit, the auditor
obtains information that will provide an overall understanding of the
entity, such as its mission, size and location, organization, business,
strategies, risks, and internal control structure. Understanding the
entity’s operations in the planning process enables the auditor to
identify, respond to, and resolve problems early in the audit.
The auditor’s understanding of the entity includes:
* entity management and organization,
* external and internal factors affecting the entity’s operations, and,
* key business processes (defined below).
To plan the audit, the auditor obtains a general understanding of the
entity’s and the IT function’s organizational structure, including key
members of entity and IT management.
The auditor’s main objective is to understand how the entity is managed
and how the organization is structured. The auditor should identify
significant external and internal factors that affect the entity’s
operations, particularly IT. External factors might include (1) IT
budget, (2) external systems users, (3) current political climate, and
(4) relevant legislation. Internal factors might include (1) size of
the entity, (2) number of locations, (3) structure of the entity
(centralized or decentralized), (4) complexity of operations, (5) IT
management structure, (6) impact of information systems on business
operations, (7) qualifications and competence of key IT personnel, and
(8) turnover of key IT personnel.
The auditor should document any significant factors that could affect
the IS controls audit, including the auditor’s risk assessment. The
auditor should also obtain a general understanding of the entity’s
business processes, particularly those processes most closely related
to the audit objectives. Business processes are the primary functions
that the entity performs in accomplishing its mission. Examples of
typical business processes in government entities include:
* mission-related processes, typically at the program or subprogram
level, such as education, public health, law enforcement, or income
security;
* financial management processes, such as collections, disbursements,
or payroll; and;
* other support processes, such as human resources, property
management, or security.
Understanding the entity's operations and business processes includes
understanding how business process applications are used to support key
business processes, as it tends to vary from entity to entity. The
auditor should obtain and review documentation, such as design
documents, blueprints, business process procedures, user manuals, etc.,
and inquire of knowledgeable personnel to obtain a general
understanding of each significant business process application that is
relevant to the audit objectives. This includes a detailed
understanding of:
* business rules (e.g. removing all transactions that fail edits or
only selected ones based on established criteria),
* transaction flows (detailed study of the entity’s internal controls
over a particular category of events that identifies all key procedures
and controls relating to the processing of transactions), and;
* application and software module interaction (transactions leave one
system for processing by another, e.g. payroll time card interfaces
with pay rate file to determine salary information).
Obtaining this understanding is essential to assessing information
system risk, understanding application controls, and developing
relevant audit procedures. For efficiency, the auditor may combine this
step with the steps in FISCAM section 2.2.1 subsection entitled
“Understand Information Systems Relevant to the Audit Objectives” to
aid in the identification of relevant controls.
The auditor should identify and document the key business processes
that are relevant to the audit objectives. For each key business
process, the auditor should identify the significant general support
systems and major applications that are used to support each key
business process.[Footnote 11] Also, for each key business process, the
auditor should identify the use of contractors and others to process
information and/or operate systems for or on behalf of the entity.
Throughout the remainder of this manual, references to entity systems
and business processes include the use of contractors and others to
process information and/or operate systems for or on behalf of the
entity. If the IS controls audit is performed as part of a financial
audit, as discussed in FAM 320 (Understand Information Systems) and
other FAM sections, the auditor should obtain an understanding of the
entity’s information systems (including methods and records) for
processing and reporting accounting (including supplemental
information), compliance, and operations data (including performance
measures reported in the Management’s Discussion and Analysis).
The auditor should document an understanding of the entity’s operations
and key business processes, including the following items to the extent
relevant to the audit objectives:
* the significance and nature of the programs and functions supported
by information systems;
* a general understanding of the entity’s and the IT function’s
organizational structure;
* key business processes relevant to the audit objectives, including
business rules, transaction flows, and application and software module
interaction;
* significant general support systems and major applications that
support each key business process; ? background information checklist,
if used;
* significant internal and external factors that could affect the IS
controls audit objectives;
* a detailed organization chart, particularly the IT and the IS
components;
* significant changes in the IT environment or significant applications
implemented within the recent past (e.g. 2 years) or planned within the
near future (e.g., 2 years); and;
* the entity’s reliance on third parties to provide IT services (e.g.,
in-house, remote connectivity, remote processing).
Appendix I includes an Information System Controls Audit Planning
Checklist that can be provided to the entity’s management to facilitate
gathering appropriate information for this audit step.
The auditor generally gathers planning information through different
methods (observation, interviews, reading policy and procedure manuals,
etc.) and from a variety of sources, including:
* previous audits and management reviews,
* top-level entity and IT management,
* entity management responsible for relevant significant programs,
* Office of Inspector General (IG) and internal audit management
(including any internal control officer),
* other members of the audit organization, concerning relevant
completed, planned or in-progress assignments,
* personnel in the Office of General Counsel, and;
* personnel in the Special Investigator Unit.
Also, the auditor generally gathers information from relevant reports
and articles issued by or about the entity, including:
* GAO reports;
* IG, internal audit, or other audit reports (including those for
performance audits and other reviews);
* congressional hearings and reports;
* consultant reports; and;
* material published about the entity in newspapers, magazines,
Internet sites, and other publications.
2.1.4 Obtain a General Understanding of the Structure of the Entity’s
Networks:
The auditor should obtain and document a general understanding of the
structure of the entity’s networks as a basis for planning the IS
controls audit. The auditor’s understanding includes a high-level view
of the network architecture that the entity uses to implement key
business processes. Such an understanding helps the auditor to assess
risk, identify potential critical control points on a preliminary
basis, understand technologies that may be subject to audit, and
identify key locations. The auditor generally should request
documentation of such information from the entity, including both high-
level and detailed network schematics. The auditor should obtain the
following information about the network architecture, generally
documented in network schematics:
* Internet presence;
* firewalls, routers, and switches;
* intrusion detection or prevention systems;
* critical systems, such as Web and mail systems, file transfer
systems, etc.;
* network management systems;
* connections to inter- and intra-agency sites;
* connections to other external organizations;
* remote access—virtual private network and dial-in; and;
* wireless connections.
2.1.5 Identify Key Areas of Audit Interest:
The auditor should identify key areas of audit interest, which are
those that are critical to achieving the audit objectives (e.g.,
general support and business process application systems and files (or
components thereof)). For a financial audit, this would include key
financial applications and data and related feeder systems.[Footnote
12] For a performance audit, this would include key systems that are
likely to be significant to the audit objectives. For each key area of
audit interest, the auditor should document relevant general support
systems and major applications and files, including (1) the operational
locations of each key system or file, (2) significant components of the
associated hardware and software (e.g., firewalls, routers, hosts,
operating systems), (3) other significant systems or system level
resources that support the key areas of audit interest, and (4) prior
audit problems reported. The auditor should also identify all access
paths into and out of the key areas of audit interest. By identifying
the key systems, files, or locations, the auditor can concentrate
efforts on them, and do little or no work associated with other areas.
The auditor generally should prioritize important systems, files, or
locations in order of importance to the audit objectives. The auditor
may characterize these items by the sensitivity or significance of the
information processed, dollar value of the transactions processed, or
presence or number of key edits or other controls performed by a
business process application.
2.1.6 Assess Information System Risk on a Preliminary Basis:
Overview:
The auditor should assess, on a preliminary basis, the nature and
extent of IS risk that relates to the key areas of audit interest. IS
risk is the likelihood that a loss of confidentiality, integrity, or
availability could occur that would materially/significantly affect the
audit objectives (e.g., for a financial audit, a material
misstatement). Assessing IS risk involves evaluation of both the
likelihood that such a loss of confidentiality, integrity, or
availability could occur and the materiality or significance of a loss
of confidentiality, integrity, or availability to the audit objectives.
The auditor should document factors that significantly increase or
decrease the level of IS risk and their potential impact on the
effectiveness of information system controls.
Assessing IS risk relating to the audit is different from management’s
risk assessment. In assessing IS risk, the auditor is not required or
expected to reperform management’s risk assessment. Rather, the auditor
assesses IS risk on a preliminary basis using data that would be
collected in the planning of audit (this includes using the entity’s
risk assessments and performing other audit procedures as outlined
below). The auditor’s risk assessment should reflect the impact of the
effectiveness of IS controls on the audit objectives.
The auditor’s assessment of IS risk affects the nature, timing, and
extent of IS controls audit procedures. As IS risk increases, the
auditor should perform more extensive or more effective tests of IS
controls. For example, a significant number of Internet access points
that are not centrally controlled increases IS risk. In this case, the
auditor would expand the auditor’s testing, as there are more potential
access paths to the key areas of audit interest. Risk assessments
prepared by the entity may serve as a useful tool to assist in the
identification of IS risk. However, the auditor should not rely on them
without performing audit procedures to identify and assess risk.
To develop a framework for analyzing IS risk, the auditor should
consider IS risk in the context of the following three security
objectives for information and information systems:
* Integrity—guarding against improper information modification or
destruction, which includes ensuring information nonrepudiation
[Footnote 13] and authenticity [Footnote 14]. A loss of integrity is
the unauthorized modification or destruction of information.
* Confidentiality—preserving authorized restrictions on information
access and disclosure, including means for protecting personal privacy
and proprietary information. A loss of confidentiality is the
unauthorized disclosure of information.
* Availability—ensuring timely and reliable access to and use of
information. A loss of availability is the disruption of access to or
use of information or an information system.
In some instances, one or more of the security objectives may have more
significance to the audit objectives than the others.
The auditor should identify factors or conditions that significantly
increase or decrease IS risk. These factors are general in nature; the
auditor uses judgment in determining (1) the extent of procedures to
identify the risks and (2) the impact of such risks on the entity’s
operations and the audit objectives. Because this risk assessment
involves the exercise of significant audit judgment, the auditor should
use experienced audit team personnel to perform the risk assessment.
Factors considered would include those related to inherent risk
[Footnote 15] as well as those related to the control environment, risk
assessment, communication, and monitoring components of internal
control [Footnote 16]. The auditor identifies such factors based on
information obtained in the planning phase, primarily from
understanding the entity’s operations and key business processes,
including significant IT processing performed outside the entity.
For each risk identified, the auditor should document the nature and
extent of the risk; the conditions that gave rise to that risk; and the
specific information or operations affected (if not pervasive). The
auditor should also document compensating controls or other
considerations that may mitigate the effects of identified risks. The
auditor should assess and document, on a preliminary basis, the nature
and extent of IS risks for the information and information systems
related to the key areas of audit interest, considering
confidentiality, integrity, and availability. The auditor should
document the basis for the assessed risk and its potential impact on
the audit objectives. For example, in a financial audit, the auditor
should evaluate the possibility of a material misstatement as a result
of a loss of confidentiality, integrity, or availability. As discussed
above, risk assessments prepared by the entity may serve as a useful
tool to assist the auditor in the identification of IS risks.
As noted above, IS risk includes the risk of loss of confidentiality,
integrity, or availability. Such risk includes the potential impact of
a loss to entity operations, assets, and individuals. However,
depending on the audit objectives, the impact on the audit objectives
could be greater or lesser. Federal agencies are required to use the
following three levels to categorize their systems based on the
potential impact of a breach of security on organizational operations,
organizational assets, or individuals:[Footnote 17]
* Low. The loss of confidentiality, integrity, or availability could be
expected to have a limited adverse effect on organizational operations,
organizational assets, or individuals.[Footnote 18] A limited adverse
effect means that, for example, the loss of confidentiality, integrity,
or availability might (i) cause a degradation in mission capability to
an extent and duration that the organization is able to perform its
primary functions, but the effectiveness of the functions is noticeably
reduced; (ii) result in minor damage to organizational assets; (iii)
result in minor financial loss; or (iv) result in minor harm to
individuals.
* Moderate. The loss of confidentiality, integrity, or availability
could be expected to have a serious adverse effect on organizational
operations, organizational assets, or individuals. A serious adverse
effect means that, for example, the loss of confidentiality, integrity,
or availability might (i) cause a significant degradation in mission
capability to an extent and duration that the organization is able to
perform its primary functions, but the effectiveness of the functions
is significantly reduced; (ii) result in significant damage to
organizational assets; (iii) result in significant financial loss; or
(iv) result in significant harm to individuals that does not involve
loss of life or serious life-threatening injuries.
* High. The loss of confidentiality, integrity, or availability could
be expected to have a severe or catastrophic adverse effect on
organizational operations, organizational assets, or individuals. A
severe or catastrophic adverse effect means that, for example, the loss
of confidentiality, integrity, or availability might (i) cause a severe
degradation in or loss of mission capability to an extent and duration
that the organization is not able to perform one or more of its primary
functions; (ii) result in major damage to organizational assets; (iii)
result in major financial loss; or (iv) result in severe or
catastrophic harm to individuals involving loss of life or serious life-
threatening injuries.
The auditor’s assessment of IS risk may change as audit evidence is
obtained. To determine whether audit procedures continue to be
appropriate, the auditor should periodically reassess the IS risk
during the audit. For example, the auditor may reassess the IS risk
level at the end of the planning and testing phases, as well as when
evidence is obtained that significantly affects the auditor’s risk
assessment. If IS risk changes during the audit, the auditor should
make any necessary changes to the nature, timing, and extent of planned
audit procedures.
Inherent Risk Factors:
Information systems can introduce additional risk factors not present
in a manual system. To properly assess IS risk, the auditor should (1)
evaluate each of the following factors and (2) assess the overall
impact of information systems on IS risk. The impact of these factors
typically will be pervasive in nature.
* The nature of the hardware and software may affect IS risk, as
illustrated below.
* The type of processing (online, batch oriented, or distributed)
presents different levels of IS risk. Distributed networks enable
multiple computer processing units to communicate with each other,
increasing the number of potential access points and the risk of
unauthorized access to computer resources and possible data alteration.
On the other hand, distributed networks may decrease the risk of data
inconsistencies at multiple processing units if the units share a
common database.
* Peripheral access devices or system interfaces can increase IS risk.
For example, Internet or wireless access to a system increases the
system’s accessibility to additional persons and therefore increases
the risk of unauthorized access to computer resources.
* Highly customized application software may have higher IS risk than
vendor-supplied software that has been thoroughly tested and is in
general commercial use. On the other hand, vendor-supplied software new
to commercial use may not have been thoroughly tested or undergone
client processing to a degree that would encounter existing flaws.
* Certain hardware and software may have more significant identified
weaknesses than others.
* In certain systems (e.g., enterprise resource planning—ERP—systems
[Footnote 19]), the audit trails and supporting information produced by
the systems may be limited in their usefulness (1) as a basis for
applying certain types of controls or (2) as audit evidence.
* Highly decentralized applications, particularly Web applications,
increase IS risk by adding complexity to IS and increasing potential
vulnerabilities.
* The application of new technologies generally increases the risk that
secure configurations of such technologies may not be well developed or
tested, or that IT personnel may not properly implement security over
such new technologies.
* The manner in which the entity’s networks are configured can affect
the related IS risk. For example, factors increasing IS risks include a
significant number of Internet access points that are not centrally
controlled, networks that are not segmented to protect sensitive
systems or information, use of technologies that are no longer
supported, or lack of technologies that enhance security.
* The consistency of the entity’s enterprise architecture and IT
strategy with its business strategies can affect the proper planning
and implementation of IT systems and related security.
Also, the following risk factors, discussed in FAM 260 (Identify Risk
Factors) are relevant to both financial and performance audits:
* Uniform processing of transactions: Because information systems
process groups of identical transactions consistently, any
misstatements arising from erroneous computer programming will occur
consistently in the same types of transactions. However, the risk of
random processing errors is reduced substantially in information
systems–based accounting systems.
* Automatic processing: The information system may automatically
initiate transactions or perform processing functions. Evidence of
these processing steps (and any related controls) may or may not be
visible.
* Increased potential for undetected misstatements: Information systems
use and store information in electronic form and require less human
involvement in processing than manual systems. Without adequate
controls, there is increased risk that individuals could gain
unauthorized access to sensitive information and alter data without
leaving visible evidence. Because information is in electronic form,
changes to computer programs and data are not readily detectable. Also,
users may be less likely to challenge the reliability of information
systems output than manual reports.
* Existence, completeness, and volume of the audit trail: The audit
trail is the evidence that demonstrates how a specific transaction was
initiated, processed, and summarized. For example, the audit trail for
a purchase could include a purchase order; a receiving report; an
invoice; an entry in an invoice register (purchases summarized by day,
month, and/or account); and general ledger postings from the invoice
register. Some computer systems are designed to maintain the audit
trail for only a short period, only in an electronic format, or only in
summary form. Also, the information generated may be too voluminous to
be analyzed effectively without software. For example, one transaction
may result from the automatic summarization of information from
hundreds of locations. Without the use of audit or retrieval software,
tracing transactions through the processing may be extremely difficult.
* Unusual or nonroutine transactions: As with manual systems, unusual
or nonroutine transactions increase IS risk. Programs developed to
process such transactions may not be subject to the same procedures as
programs developed to process routine transactions. For example, the
entity may use a utility program to extract specified information in
support of a nonroutine management decision.
In addition, the auditor should evaluate the additional audit risk
factors discussed in the “Additional IS Risk Factors” at the end of
this chapter.
Risk Factors Related to the Control Environment, Risk Assessment,
Communication, and Monitoring Components of Internal Control:
Also, the auditor should evaluate the following IT system factors, to
the extent relevant to the audit objectives, in making an overall
assessment of the control environment, risk assessment, communication,
and monitoring components of internal control.
a. Management's attitudes and awareness with respect to IT systems:
Management’s interest in and awareness of IT system functions
(including those performed for the entity by other organizations) is
important in establishing an organizationwide consciousness of control
issues. Management may demonstrate its interest and awareness by:
* considering the risks and benefits of computer applications;
* communicating policies regarding IT system functions and
responsibilities;
* overseeing policies and procedures for developing, modifying,
maintaining, and using computers, and for controlling access to
programs and files;
* considering the risk of material misstatement, including fraud risk,
related to IT systems;
* responding to previous recommendations or concerns;
* quickly and effectively planning for, and responding to, computerized
processing crises; and;
* using reliable computer-generated information for key operating
decisions.
b. Organization and structure of the IT system function: The
organizational structure affects the control environment. Centralized
structures often have a single computer processing organization and use
a single set of system and applications software, enabling tighter
management control over IT systems. In decentralized structures, each
computer center generally has its own computer processing organization,
application programs, and system software, which may result in
differences in policies and procedures and various levels of compliance
at each location.
c. Clearly defined assignment of responsibilities and authority:
Appropriate assignment of responsibility according to typical IT system
functional areas can affect the control environment. Factors to
consider include:
* how the position of the Chief Information Officer (CIO) fits into the
organizational structure;
* whether duties are appropriately segregated within the IT systems
function, such as operators and programmers, since lack of segregation
typically affects all systems;
* the extent to which management external to the IT systems function is
involved in major systems development decisions; and;
* the extent to which IT system policies, standards, and procedures are
documented, understood, followed, and enforced.
d. Management’s ability to identify and to respond to potential risk:
Computer processing, by its nature, introduces additional risk factors.
The entity should be aware of these risks and should develop
appropriate policies and procedures to respond to any IT system issues
that might occur. The auditor may evaluate:
* the methods for monitoring incompatible functions and for enforcing
segregation of duties and;
* management’s mechanism for identifying and responding to unusual or
exceptional conditions.
Examples of potential IT-related control environment, risk assessment,
communication, and monitoring weaknesses include:
* Management and personnel in key areas (such as accounting, IT
systems, IG, and internal auditing) have a high turnover.
* Management attitude toward IT systems and accounting functions is
that these are necessary ‘‘bean counting’’ functions rather than a
vehicle for exercising control over the entity's activities or making
better decisions.
* The number of people, particularly in IT systems and accounting, with
requisite skill levels relative to the size and complexity of the
operations is inadequate.
* Management has not adequately identified risks arising from internal
sources, such as human resources (ability to retain key people) or IT
(adequacy of backup systems in the event of systems failure).
* Accounting systems and/or information systems, including IT systems,
are not modified in response to changing conditions.
2.1.7 Identify Critical Control Points:
The auditor should identify and document critical control points in the
design of the entity’s information systems based on the auditor’s
understanding of such systems, key areas of audit interest, and IS
risk. Critical control points are those system control points that, if
compromised, could allow an individual to gain unauthorized access to
or perform unauthorized or inappropriate activities on entity systems
or data, which could lead directly or indirectly to unauthorized access
or modifications to the key areas of audit interest. Control points
typically include external access points to the entity’s networks,
interconnections with other external and internal systems, system
components controlling the flow of information through the entity’s
networks or to the key areas of audit interest, critical storage and
processing devices, and related operating systems, infrastructure
applications, and relevant business process applications. Typical
control points also include network components where business process
application controls are applied. As the audit testing proceeds and the
auditor gains a better understanding of the entity’s information
systems, of control weaknesses, and of the related risks, the auditor
should periodically reassess the critical control points. Based on
information obtained during audit planning, the auditor should identify
those critical control points in the entity’s IT systems that are
significant to the effectiveness of security over the key areas of
audit interest.
An analysis of critical control points includes consideration of
alternate work sites. Since multiple FISCAM control categories are
relevant to alternate work sites, it is not addressed as a specific
control in this document. For further information on this subject refer
to NIST guidance contained in SP 800-53 and SP 800-46.
In identifying critical control points and in planning and performing
the assessment of IS controls, auditors apply the concept of control
dependencies. A control dependency exists when the effectiveness of an
internal control is dependent on the effectiveness of other internal
controls. An assessment of the effectiveness of information system
controls over a critical control point includes testing the
effectiveness of controls over other control points upon which the
security of the critical control point is dependent. Figure 2
illustrates the concept of a control dependency in relation to a router
for a typical network.
Figure 2: Example of Router Control Dependencies:
[See PDF for image]
This figure is an illustration of Router Control Dependencies. The
following items are depicted:
* Private or public network;
* Firewall;
* Switch;
* outer;
- Dial-in; modem;
- Console port;
* Switch;
-Administrator workstation;
- Log server;
- Network management server;
- Authentication server;
- Trivial file transfer protocol server;
- Remote access server.
Source: GAO.
[End of figure]
The figure illustrates that the effectiveness of controls over the
router in this example network are dependent on controls over other
control points. In this example, because unauthorized or inappropriate
access to the other control points could affect the security of the
router, the auditor’s tests of IS controls generally should include
controls over:
* the trivial file transfer protocol (tftp) servers used to maintain a
central repository of sensitive configuration files (tftp servers do
not require authentication and are also used as remote boot devices for
routers);
* the centralized authentication server that authenticates users to the
router and other network devices;
* network switches that could share sensitive data with routers such as
passwords and shared keys (also, network switches provide a trusted
path to the routers);
* administrative workstations used to manage network devices, such as
routers; and;
* the log server, which maintains logs containing relevant information
about significant network events, such as router access.
In addition, as part of a review of the system level controls over the
router, the auditor generally should test controls over:
* the network management servers used to manage configuration files
that contain sensitive information about network devices such as
routers;
* remote access to the router via the auxiliary and console ports that
could be used to remotely manage the router;
* the firewalls that provide boundary protection (i.e., limits
connectivity to the router);
* unencrypted network traffic that could be “sniffed” to obtain router
or other privileged passwords; and;
* the PC connected to the router that could facilitate direct
connectivity to the router.
Further, the auditor generally should test other controls that may
affect the security of the router, based on the auditor’s judgment.
Note that, in addition to controls over access to the router itself, IS
controls include controls over the routing of traffic throughout the
network (see AC-1 in Chapter 3).
As the auditor performs the IS controls audit, based on the auditor’s
assessment of risk and the results of audit tests, the auditor may
determine that it is necessary to modify the scope of the audit. For
example, if significant IS control weaknesses are identified during the
audit, it may not be necessary to perform all planned tests of IS
controls. If testing is reduced due to the identification of
significant weaknesses, the auditor should document such a decision.
Also, testing may result in the identification of additional risks, and
critical control points, and/or control dependencies; the auditor
should determine whether to adjust the scope for them.
2.1.8 Obtain a Preliminary Understanding of Information System
Controls:
The auditor should obtain and document a preliminary understanding of
the design of the entity’s IS controls, including the organization,
staffing, responsibilities, authorities, and resources of the entity’s
security management function. The auditor should document a preliminary
understanding of entitywide controls (or componentwide controls if only
a component is being audited) related to security management, access
controls, configuration management, segregation of duties and,
contingency planning.
The auditor should understand the design of each of the three types of
IS controls (general, business process application, and user controls)
to the extent necessary to tentatively conclude whether these controls
are likely to be effective. If they are likely to be effective, the
auditor should consider specific IS controls in determining whether
relevant IS control objectives are achieved. If IS controls are not
likely to be effective, the auditor should obtain a sufficient
understanding of control risks arising from IS controls to assess audit
risk, design appropriate audit procedures, and develop appropriate
findings.
In addition, the auditor should obtain a preliminary understanding of
the business process application controls (business process, interface,
and data management system controls) over key business process
applications identified as or related to key areas of audit interest,
determine where those controls are applied, and determine whether the
controls are designed effectively and have been implemented (placed in
operation). For example, authentication and authorization may be
applied in network components that are different from those where key
data files or applications reside; (e.g., Web applications that reside
on one server may be used to authenticate and authorize users of legacy
systems that run on different servers or systems). The auditor should
determine the potential impact of any identified design weaknesses on
the completeness, accuracy, validity, and confidentiality of related
application data. (See Chapter 4 for a description of completeness,
accuracy, validity, and confidentiality.)
The auditor should make a preliminary assessment of whether IS controls
are likely to be effective to assist in determining the nature, timing,
and extent of testing. This assessment is based primarily on
discussions with personnel throughout the entity, including program
managers, system administrators, information resource managers, and
systems security managers; on observations of IT operations and
controls; on reviewing examples of evidence of control performance; on
prior audits or the work of others; and on reading written policies and
procedures. This preliminary assessment for financial audits is
discussed further at FAM 270 (Determine Likelihood of Effective
Information System Controls). Based on the preliminary assessment, the
auditor should make any adjustments, as necessary, to the IS risk
level, critical control points, and planned scope of the audit work.
Control activities for critical elements in each general control and
business process control category are described in Chapters 3 and 4,
respectively, and summarized in Appendix II. The auditor may use the
summary tables in Appendix II, which are also available in electronic
form from GAO [hyperlink, http://www.gao.gov], to document preliminary
findings and to assist in making the preliminary assessment of
controls. As the audit progresses through testing of internal controls,
the auditor may continue to use the electronic version of the tables to
document controls evaluated and tested, test procedures performed,
conclusions, and supporting documentation references.
The auditor should include the following information in the
documentation of their preliminary understanding of the design of IS
controls, to the extent relevant to the audit objectives:
* An identification of relevant entitywide, system, and business
process application level controls designed to achieve the control
activities for each critical element within each general control area
and a determination of whether they are designed effectively and
implemented (placed in operation), including identification of control
activities for which there are no or ineffective controls at the
entitywide level and the related risks.
* Identification of business process controls for key applications
identified as key areas of audit interest, determination of where those
controls are implemented within the entity’s systems, and the auditor’s
conclusion about whether the controls are designed effectively and
implemented (placed in operation), including identification of control
activities for which there are no or ineffective controls and the
related risks and the potential impact of any identified design
weaknesses on the completeness, accuracy, validity, and confidentiality
of application data.
* Any internal or third-party information systems reviews, audits, or
specialized systems testing (e.g., penetration tests, disaster recovery
tests, and application-specific tests) performed during the last year
and the auditor’s evaluation of the other auditor’s objectivity,
competence and conclusions.
* Management’s plans of action and milestones, or their equivalent,
that identify corrective actions planned to address known IS control
weaknesses.
* Status of the prior years’ audit findings.
* Documentation for any significant computer security related incidents
identified and reported for the last year.
* Documented security plans.
* Documented risk assessments for relevant systems (e.g., general
support systems and major applications).
* System certification and accreditation documentation or equivalent
for relevant systems.
* Documented business continuity of operations plans and disaster
recovery plans.
* A description of the entity’s use of third-party IT services.
The auditor should obtain information from relevant reports and other
documents concerning IS that are issued by or about the entity,
including:
* the entity’s prior FISMA or equivalent reports on IS;
* the entity’s annual performance and accountability report or
equivalent reports on performance including reports filed to comply
with the Federal Financial Management Improvement Act of 1996 [Footnote
20] (FFMIA) and Federal Managers Financial Integrity Act of 1982
[Footnote 21] (FMFIA);
* other reports by management or the auditor about IS;
* other reports that contain information concerning IS that are
relevant to the audit objectives;
* GAO reports;
* IG and internal audit reports (including those for performance audits
and other reviews); and;
* consultant reports.
2.1.9 Perform Other Audit Planning Procedures:
The auditor should address the following areas during the planning
phase, even though related audit procedures may be applied during the
other phases. More specifically, the auditor should address any other
issues, not identified in the previous steps, that could affect the
objectives, scope, or methodology of the IS controls audit, including:
* relevant laws and regulations;
* the risk of fraud;
* staffing and other resources needed to perform the audit;
* multiyear testing plans;
* communication to management officials and those charged with
governance concerning the planning and performance of the audit, and to
others as applicable;
* use of service organizations;
* using the work of others; and;
* preparation of an audit plan (and an audit strategy for financial
statement audits).
2.1.9.A Relevant Laws and Regulations:
The auditor should identify applicable laws and regulations that are
relevant to IS at the entity. Such laws and regulations may establish
general or specific IS control requirements or criteria. Laws and
regulations generally relevant to audits of federal agencies include
FISMA, FMFIA, FFMIA, Appendix III of OMB Circular A-130,[Footnote 22]
OMB Circular A-123,[Footnote 23] and FISMA implementing guidance.
Specific federal laws and regulations that may affect the entity
include:
* Health Insurance Portability and Accountability Act of 1996
(HIPAA),[Footnote 24];
* Gramm-Leach-Bliley,[Footnote 25];
* Requirements for information security for Medicare Administrative
Contractors,[Footnote 26];
* Chief Privacy Officer statutory requirements,[Footnote 27];
* OMB Memorandum M-05-08, Designation of Senior Agency Officials for
Privacy, and[Footnote 28];
* OMB Memorandum M-06-19, Reporting Incidents Involving Personally
Identifiable Information.[Footnote 29]
* OMB Memorandum M 07-16, Safeguarding Against and Responding to the
Breach of Personally Identifiable Information.[Footnote 30]
In IS controls audits of state and local governments, the auditor
should identify applicable legal and reporting requirements and issues.
Further information specifically related to audits of state and local
government entities can be obtained from the National Association of
State Auditors, Comptrollers and Treasurers (NASACT).[Footnote 31]
Under GAGAS, the auditor should design and perform procedures to
provide reasonable assurance of detecting instances of violations of
legal and regulatory requirements that are significant within the
context of the audit objectives. Consequently, if one of the objectives
of the audit is to determine whether the entity violated specific laws
or regulations, the auditor should plan the audit to detect significant
violations of such laws or regulations. In financial audits, the
auditor should test those laws and regulations that could have a direct
and material effect on the financial statements.
As part of an IS controls audit, the auditor’s findings will typically
be reported in terms of whether IS controls are effective. While such
general laws and regulations as FISMA, FMFIA, FFMIA, and OMB guidance
provide requirements and criteria for assessing IS, IS controls audit
objectives generally are not focused on detecting violations of such
laws and regulations, but rather on assessing controls and identifying
any control weaknesses. Consequently, such laws and regulations
generally would not be considered significant to the audit objectives
for the purposes of designing compliance tests to meet GAGAS. However,
audit objectives may sometimes include specific objectives to determine
compliance with such laws, in which case such laws and regulations
would be significant. Also, other laws such as HIPAA, which provide for
potential penalties, may be significant to the audit objectives.
2.1.9.B Consideration of the Risk of Fraud:
In audits performed under GAGAS, the auditor should assess the risks of
fraud [Footnote 32] occurring that is significant within the context of
the audit objectives (for financial audits, a material misstatement).
Auditors should gather and assess information to identify risks of
fraud that are significant within the scope of the audit objectives or
that could affect the findings or conclusions. When auditors identify
factors or risks related to fraud that has occurred or is likely to
have occurred that they believe are significant within the context of
the audit objectives, they should design procedures to provide
reasonable assurance of detecting such fraud. In financial audits,
GAGAS indicates that auditors should assess the risk of material
misstatements of financial statement amounts or other financial data
significant to the audit objectives due to fraud and to consider that
assessment in designing the audit procedures to be performed.[Footnote
33] The auditor’s responsibilities with respect to the risk of fraud in
financial statement audits are discussed further in the GAGAS and in
the AICPA’s Auditing Standards Board Statement on Auditing Standards
No. 99, titled Consideration of Fraud in a Financial Statement Audit,
as amended (AU section 316).
If the IS controls audit is performed as part of a broader financial or
performance audit, the auditor should coordinate with the audit team in
the identification of and response to the risk of fraud. The auditor
should be aware of fraud risks identified by the overall audit team and
communicate any fraud risks or suspected fraud associated with IT to
the overall audit team. Also, the overall audit team may identify audit
procedures to be performed by the IS controls specialist to detect
fraud significant to the audit.
The audit team should hold a brainstorming session at the start of the
audit to discuss potential fraud risks, fraud factors such as
individuals’ incentives or pressures to commit fraud, the opportunity
for fraud to occur, and rationalizations or attitudes that could allow
individuals to commit fraud. For example, the following factors related
to IS may indicate a risk of fraud:
* failure to provide an adequate security management program, including
inadequate monitoring of control effectiveness;
* weaknesses in access and other IS controls that could allow overrides
of internal controls or access to systems susceptible to fraud (e.g.,
payment systems);
* lack of adequate segregation of duties;[Footnote 34] and;
* pervasive or long-standing IS control weaknesses.
The auditor should gather and assess information necessary to identify
fraud risks that could be relevant to the audit objectives or affect
the results of their audit. For example, the auditor may obtain
information through discussion with officials of the audited entity or
through other means to determine the susceptibility of the program to
fraud, the status of internal controls the entity has established to
detect and prevent fraud, or the risk that officials of the audited
entity could override internal control. The auditor should exercise
professional skepticism in assessing these risks to determine which
factors or risks could significantly affect the results of their work
if fraud has occurred or is likely to have occurred.
When the auditor identifies factors or risks related to fraud that they
believe are significant within the context of the audit objectives or
the results of the audit, they should design procedures to provide
reasonable assurance of detecting such fraud. The auditor should
prepare audit documentation related to their identification and
assessment of and response to fraud risks.
Assessing the risk of fraud is an ongoing process throughout the audit
and relates not only to planning the audit but also to evaluating
evidence obtained during the audit. When testing general and business
process application level controls, the auditor should be alert for
information or other conditions that indicate fraud that is significant
within the context of the audit objectives may have occurred.
A specific area of concern for fraud is override of controls,
particularly in ERP applications. Because ERP applications are by their
nature highly integrated, the potential risk of management override of
controls is heightened. The audit generally should include procedures
to identify system-based overrides. These procedures might include
testing for instances of users performing inappropriate combinations of
transactions (i.e., transactions that should have been segregated) and
other similar procedures. Some examples of antifraud controls to
consider include: workflow approvals, restricting access to sensitive
files, segregation of duties, review of audit trails, and review of key
management reports. Access controls, segregation of duties, and audit
trails are discussed in Chapter 3.
The auditor should also evaluate situations or transactions that could
be indicative of fraud. When information comes to the auditors’
attention (through audit procedures, allegations received through fraud
hotlines, or other means) indicating that fraud may have occurred, the
auditor should evaluate whether the possible fraud could significantly
affect the audit results. If the fraud could significantly affect the
audit results, auditors should modify the audit steps and procedures,
as necessary, to (1) determine if fraud likely has occurred and (2) if
so, determine its effect on the audit results.
The auditor’s training, experience, and understanding of the program
being audited may provide a basis for recognizing that some acts coming
to his or her attention may be indicative of fraud. Whether an act is,
in fact, fraud is a determination to be made through the judicial or
other adjudicative system and is beyond auditors’ professional
expertise and responsibility. However, the auditor is responsible for
being aware of vulnerabilities to fraud associated with the area being
audited to identify indications that fraud may have occurred.
2.1.9.C Audit Resources:
As with other types of audits, the staff assigned to perform the IS
controls audit must collectively possess adequate professional
competence. Therefore, it is important to carefully plan IS controls
audits to ensure that adequate and appropriate resources are available
to perform the audit. IS controls audits need a broad range of
technical skills. In addition to skills necessary to assess each
control category, IS controls audits generally use technical
specialists with skills in such areas as networks, Windows/Novell,
Unix, data management systems, and mainframe system and access control
software. See Appendix V for a discussion of typical skill sets for IS
controls specialists. Based on the knowledge obtained during audit
planning, the auditor should identify resource requirements and
determine whether internal resources are available or whether
contractors will be necessary to complete the audit. The auditor should
then schedule the resources for the appropriate periods of time.
Regardless of the size of the entity, the auditor must still perform
the necessary planning to ensure that audit requirements are fully
satisfied. This includes small/independent agencies which generally
have a less complex, less risky IS control environment, which requires
inherently fewer IS controls audit resources. The Committee of
Sponsoring Organizations (COSO)[Footnote 35] publication “Internal
Controls over Financial Reporting – Guidance for Smaller Public
Companies” includes guidance that could be used by smaller agencies in
planning their audits.
The auditor may determine that it is necessary to contract for audit
services for all or a portion of the IS controls audit. For example,
the auditor may determine that it is necessary to contract only for
certain technical skills needed to perform the audit. Contracting for
audit services offers two significant benefits to an entity’s audit
organization—it allows audit coverage beyond that possible with the
existing audit staff level, and it allows the audit activity to address
technical and other issues in which the in-house staff is not skilled.
Engagements that employ contractors in this way may help train in-house
staff for future audits. However, when contracting for audit services,
some in-house audit personnel generally should be actively involved.
For example, the audit organization should be instrumental in
determining the scope of the contracted services, and in developing the
task order or request for proposal for the work. The FISCAM may be
required to be used as a basis for the work to be performed.
Also, an auditor generally should be designated to monitor the contract
for the entity. The contract monitor should have sufficient knowledge
of IS controls to monitor and to assess the quality and adequacy of the
work performed by the contractor, including the adequacy of the audit
documentation. The contract monitor should discuss the contract with
the contractor, including the product deliverables, the established
time frames for deliverables, and documentation standards to adhere to.
The auditor generally should hold this meeting before the contractor
begins work. In addition, the contract monitor should attend critical
meetings the contractor has with entity representatives, including the
opening and close-out meetings.
The contract monitor should conduct a technical review of the work
performed and may use this manual as guidance to determine whether the
work addressed relevant issues and the audit procedures were adequate.
For financial audits, the contract monitor may reperform some tests in
accordance with FAM 650, “Using the Reports and Work of Others.” Also,
the contract monitor should review the audit report and supporting
audit documentation to determine whether the audit report is adequately
supported.
2.1.9.D Multiyear Testing Plans:
In circumstances where the auditor regularly performs IS controls
audits of the entity (as is done, for example, by an IG or for annual
financial audits), the auditor may determine that a multiyear plan for
performing IS controls audits is appropriate. Such a plan will cover
relevant key agency applications, systems, and processing centers .
These strategic plans should cover no more than a 3-year period and
include the schedule and scope of assessments to be performed during
the period and the rationale for the planned approach. The auditor
typically evaluates these plans annually and adjusts them for the
results of prior and current audits and significant changes in the IT
environment, such as implementation of new systems.
Multiyear testing plans can help to assure that all agency systems and
locations are considered in the IS control evaluation process, to
consider relative audit risk and prioritization of systems, and to
provide sufficient evidence to support an assessment of IS control
effectiveness, while helping to reduce annual audit resources under
certain conditions. When appropriate, this concept allows the auditor
to test computer-related general and business process application
controls on a risk basis rather than testing every control every year.
Under a multiyear testing plan, different controls are comprehensively
tested each year, so that each significant general and business process
control is selected for testing at least once during the multiyear
period, which should not be more than 3 years. For example, a multiyear
testing plan for an entity with five significant business process
applications might include comprehensive tests of two or three
applications annually, covering all applications in a 2 or 3 year
period. For systems with high IS risk, the auditor generally should
perform annual testing.
Such multiyear testing plans are not appropriate in all situations. For
example, they are not appropriate for first-time audits, for audits
where some significant business process applications or general
controls have not been tested within a sufficiently recent period (no
more than 3 years), or for audits of entities that do not have strong
entitywide controls. Also, using this concept, the auditor performs
some limited tests and other activities annually for general and
business process controls not selected for full testing; examples of
such activities include updating the auditor’s understanding of the
control environment, inquiring about control changes, and conducting
walk-throughs. For example, because of the importance of system level
critical control points, the auditor generally updates the
understanding of these yearly through limited tests. Multiyear testing
is discussed in greater detail in FAM section 395 G: “Multiyear Testing
of Controls.”
2.1.9.E Communication with Entity Management and Those Charged with
Governance:
The auditor should communicate information about the audit to
appropriate entity management and those charged with governance. The
auditor should document this communication, usually with an engagement
letter. This step is particularly important in an IS controls audit
because of the sensitivity of entity information systems and the nature
of tests performed. Multiple meetings may be necessary with various
levels of management so that they are adequately aware of the audit
process. GAGAS requires that to help the various parties involved in
the audit understand the audit objectives, time frames, and any data
needs, the auditor should provide them with information about the
specific nature of the audit, as well as general information concerning
the planning and conduct of the audit and reporting.
As part of this communication, it may be useful to provide general
protocols for conducting the IS controls audit. Such protocols might
include the following:
* Define the scope of the engagement. This might include an overview of
the audit objectives, information about what is to be tested, when
testing will occur, where and from what locations testing will be
performed, who will be performing and monitoring the testing, and how
the testing will be performed (for example, the methodology and tools
that will be employed). However, it is important to not disclose
detailed audit procedures so that the tests become ineffective.
* Communicate risks and steps taken by management to manage such risks.
While risks cannot be eliminated entirely, they can be managed to an
acceptable level to avoid, or at least minimize, service degradation or
interruption. Auditors can communicate actions they have taken to
minimize risks such as (a) not performing denial-of-service testing,
(b) coordinating testing with the audited site, (c) having
knowledgeable personnel from the audited site monitoring all testing,
(d) testing the tools that will be used and gaining expertise in their
use, (e) logging test parameters, (f) logging testing and results, (g)
using network analyzers to monitor loads placed on the network during
testing, and (h) performing testing during nonpeak hours, if possible.
* Identify roles and responsibilities. Address the roles and
responsibilities of each participant. Participants will likely include
the test team, the auditors, the system owners, the systems security
officer, the systems administrators, and contractors, if applicable.
* Address logistical requirements. Logistical requirements would
include information about such items as the organization’s range of
Internet Protocol addresses and telephone numbers (particularly
sensitive numbers that should be excluded from testing), analog
telephone lines, wireless connections, Internet access paths, policies
governing user accounts and passwords, etc. On-site workspace
arrangements and agency points of contact might also be addressed.
GAGAS requires certain communications with management, those charged
with governance, and others. For financial audits, see AU 380 and GAGAS
4.06. For performance audits, see GAGAS 7.46-7.48. In situations in
which those charged with governance are not clearly evident, auditors
should document the process followed and conclusions reached for
identifying those charged with governance.
2.1.9.F Service Organizations:
When IS controls, which are significant to a GAGAS audit, are performed
by a service organization external to the audited entity, the auditor
should determine how to obtain sufficient, appropriate evidence about
the operating effectiveness of such controls. The auditor should
coordinate these procedures with the audit procedures performed in
support of critical element SM-7 “Ensure That Activities Performed by
External Third Parties are Adequately Secure”. For example, the auditor
should determine how management of the audited entity monitors the
effectiveness of IS controls at the service organization, such as
through the receipt and analysis of a service auditor (SAS 70) report.
SAS 70 reports are discussed in more detail in Appendix VII. If the
auditor uses a SAS 70 report, the auditor is responsible for
determining whether SAS 70 report provides sufficient evidence about
the operating effectiveness of IS controls performed by the service
organization that are significant to the audit. Also, see section
2.1.9.G below. If IS controls are performed by service organizations,
the auditor should document conclusions whether such controls are
significant to the audit objectives and any audit procedures performed
with respect to such controls (e.g., review of service auditor
reports).
The auditor should integrate evidence obtained about the operating
effectiveness of service auditor controls into the IS controls audit.
For example, the auditor should evaluate the effectiveness of IS
controls for the combination of IS controls at the audited entity and
at the service organization collectively. The preparation and use of
service auditor reports are discussed further in Appendix VII,
including how to determine whether the service auditor report contains
sufficient, appropriate evidence.
2.1.9.G Using the Work of Others:
The auditor may be able to use the work of the other auditors to
support findings or conclusions for the current audit. If auditors use
the work of other auditors, they should perform procedures that provide
a sufficient basis for using that work. For financial audits, further
information on using the work of other auditors is discussed in FAM 650
and AU 336. For performance audits, as discussed in GAGAS 7.41-.43,
auditors should obtain evidence concerning the other auditors’
qualifications and independence and should determine whether the scope,
quality, and timing of the audit work performed by the other auditors
is adequate for reliance in the context of the current audit
objectives. Procedures that auditors may perform in making this
determination include reviewing the other auditors’ report, audit plan,
or audit documentation, and/or performing tests of the other auditors’
work. The nature and extent of evidence needed will depend on the
significance of the other auditors’ work to the current audit
objectives and the extent to which the auditors will use that work.
As discussed in GAGAS 7.43, some performance audits may necessitate the
use of specialized techniques or methods that require the skills of a
specialist. If auditors intend to use the work of specialists, they
should obtain an understanding of the qualifications and independence
of the specialists. (See GAGAS paragraph 3.05 for independence
considerations when using the work of others.) Evaluating the
professional qualifications of the specialist involves the following:
a. the professional certification, license, or other recognition of the
competence of the specialist in his or her field, as appropriate;
b. the reputation and standing of the specialist in the views of peers
and others familiar with the specialist’s capability or performance;
c. the specialist’s experience and previous work in the subject matter;
and;
d. the auditors’ prior experience in using the specialist’s work.
If the auditor plans to use the work of others, the auditor should
document conclusions concerning the planned use of the work of others
and any audit procedures performed with respect to using the work of
others.
2.1.9.H Audit Plan:
The auditor should prepare a written audit plan for each audit. The
auditor should describe the objectives, scope, and methodology for the
IS controls audit. The auditor should include planning information,
discussed in the preceding sections of this chapter. If the IS controls
audit is a component of a performance audit or attestation engagement,
the auditor should integrate such information, as appropriate, into the
overall audit plan. If the IS controls audit is a component of a
financial audit, the auditor should integrate such information, as
appropriate, with the overall audit strategy and audit plan for the
financial audit. Additionally, the auditor generally should use the IS
controls audit plan as a tool to communicate with the audit team. If
the auditor believes that another auditor will use his or her work, the
auditor may use the plan to coordinate with the other auditor.
In planning the audit, the auditor generally will first assess the
effectiveness of entitywide and system level general controls prior to
testing business process application level controls, unless the purpose
of the audit is to identify control weaknesses in the application area.
Without effective entitywide and system level general controls,
business process application level controls may be rendered ineffective
by circumvention or modification. Consequently, if general controls are
not designed or operating effectively, the auditor may conclude that
assessing business process application level controls is not efficient
or necessary to achieve the audit objectives. In such cases, the
auditor should develop appropriate findings and consider the nature and
extent of risks and their effect on the audit objectives and the
nature, timing, and extent of audit procedures. However, if an audit
objective is to identify control weaknesses within a business process
application, an assessment of the business process application level
controls may be appropriate. Also, testing of business process
application level controls may be warranted when the auditor finds
general control weaknesses mainly in areas with a relatively
insignificant impact on business process controls and the key areas of
audit interest, but not in more significant areas.
GAGAS require that a written audit plan be prepared for each
performance audit. The form and content of the written audit plan may
vary among audits and may include an audit strategy, audit program,
project plan, audit planning paper, or other appropriate documentation
of key decisions about the audit objectives, scope, and methodology and
of the auditor’s basis for these decisions. The auditor should update
the plan, as necessary, to reflect any significant changes to the plan
made during the audit. GAGAS include financial audit planning
documentation standards.
2.1.10 Documentation of Planning Phase:
The auditor should document the following information developed in the
planning phase:
* Objectives of the IS audit IS controls audit and, if it is part of a
broader audit, a description of how such objectives support the overall
audit objectives.
* The scope of the IS audit IS controls audit.
* The auditor’s understanding of the entity’s operations and key
business processes, including, to the extent relevant to the audit
objectives, the following:
- The significance and nature of the programs and functions supported
by information systems;
- Key business processes relevant to the audit objectives, including
business rules, transaction flows, and application and software module
interaction;
- Significant general support systems and major applications that
support each key process;
- Background information request, if used;
- Significant internal and external factors that could affect the IS
auditIS controls audit objectives;
- Detailed organization chart, particularly the IT and the IS
components;
- Significant changes in the IT environment/architecture or significant
applications implemented within the past 2 years or planned within the
next 2 years; and;
- The entity’s reliance on third parties to provide IT services (e.g.,
in-house, remote connectivity, remote processing).
* A general understanding of the structure of the entity’s or
component’s networks as a basis for planning the IS auditIS controls
audit, including high-level and detailed network schematics relevant to
the audit objectives.
* Key areas of audit interest, including relevant general support
systems and major applications and files. This includes (1) the
operational locations of each key system or file, (2) significant
components of the associated hardware and software (e.g., firewalls,
routers, hosts, operating systems), (3) other significant systems or
system-level resources that support the key areas of audit interest,
and (4) prior audit problems reported. Also, the auditor should
document all access paths in and out of the key areas of audit
interest.
* Factors that significantly increase or decrease IS risk and their
potential impact on the effectiveness of information system controls.
For each risk identified, the auditor should document the nature and
extent of the risk; the conditions that gave rise to that risk; and the
specific information or operations affected (if not pervasive).
* Preliminary assessment of IS risks related to the key areas of audit
interest and the basis for the assessed risk. For each risk identified,
the auditor should document the nature and extent of the risk; the
conditions that gave rise to that risk; and the specific information or
operations affected (if not pervasive). The auditor should also
document other considerations that may mitigate the effects of
identified risks.
* Critical control points.
* A preliminary understanding of the entity’s IS controls, including
the organization, staffing, responsibilities, authorities, and
resources of the entity’s security management function. The auditor
should include the following information in the documentation of their
preliminary understanding of the design of IS controls, to the extent
relevant to the audit objectives:
- Identification of entitywide level controls (and appropriate system
level controls) designed to achieve the control activities for each
critical element within each general control area and a determination
of whether they are designed effectively and implemented (placed in
operation), including identification of control activities for which
there are no or ineffective controls at the entitywide level and the
related risks;
- Identification of business process level controls for key
applications identified as key areas of audit interest, determination
of where those controls are implemented (placed in operation) within
the entity’s systems, and the auditor’s conclusion about whether the
controls are designed effectively, including identification of control
activities for which there are no or ineffective controls and the
related risks and the potential impact of any identified design
weaknesses on the completeness, accuracy, validity, and confidentiality
of application data;
- Any internal or third-party information systems reviews, audits, or
specialized systems testing (e.g., penetration tests, disaster recovery
tests, and application-specific tests) performed during the last year;
- Management’s plans of action and milestones, or their equivalent,
that identify corrective actions planned to address known IS weaknesses
IS control weaknesses;
- Status of the prior years’ audit findings;
- Documentation for any significant computer security related incidents
identified and reported for the last year;
- Documented security plans;
- Documented risk assessments for relevant systems (e.g., general
support systems and major applications);
- System certification and accreditation documentation or equivalent
for relevant systems;
- Documented business continuity of operations plans and disaster
recovery plans; and;
- A description of the entity’s use of third-party IT services.
* Relevant laws and regulations and their relation to the audit
objectives.
* Description of the auditor’s procedures to consider the risk of
fraud, any fraud risk factors that the auditor believes could affect
the audit objectives, and planned audit procedures to detect any fraud
significant to the audit objectives.
* Audit resources planned.
* Current multiyear testing plans.
* Documentation of communications with entity management.
* If IS controls are performed by service organizations, conclusions
whether such controls are significant to the audit objectives and any
audit procedures performed with respect to such controls (e.g., review
of service auditor reports)
* If the auditor plans to use the work of others, conclusions
concerning the planned use of the work of others and any audit
procedures performed with respect to using the work of others.
* Audit plan that adequately describes the objectives, scope, and
methodology of the audit.
* Any decision to reduce testing of IS controls due to the
identification of significant IS control weaknesses.
2.2 Perform Information System Controls Audit Tests:
2.2.1 Overview:
In the testing phase of the IS controls audit, the auditor uses
information obtained in the planning phase to test the effectiveness of
IS controls that are relevant to the audit objectives. As audit
evidence is obtained through performing control testing, the auditor
should reassess the audit plan and consider whether changes are
appropriate.
While determining whether IS controls are appropriately designed and
implemented and while performing tests of IS controls, the auditor
should periodically assess the cumulative audit evidence obtained to
identify any revisions needed to the audit plan. For example, if
significant weaknesses have been identified, the auditor may decide to
perform less testing in remaining areas if audit objectives have been
achieved. Conversely, the performance of tests may uncover additional
areas to be tested. For those IS controls that the auditor determines
are properly/suitably designed and implemented, the auditor determines
whether to perform tests of the operating effectiveness of such
controls. In determining whether to test the operating effectiveness of
IS controls, the auditor should determine whether it is possible and
practicable to obtain sufficient, appropriate audit evidence without
testing IS controls. For federal financial statement audits and for
single audits (compliance requirements), the auditor is required to
test controls that are suitably designed and implemented to achieve a
low assessed level of control risk.
As discussed in Chapter 1, this manual is organized in a hierarchical
structure to assist the auditor in performing the IS controls audit.
Chapter 3 provides information concerning the general controls, and
Chapter 4 provides information concerning four business process
application level controls. Each of the chapters contains several
control categories, which are groupings of related controls pertaining
to similar types of risk. For each control category, this manual
discusses the key underlying concepts and associated risks if the
controls in the category are ineffective.
Chapter 3 is organized by five general control categories:
* security management,
* access controls,
* configuration management,
* segregation of duties, and,
* contingency planning.
Chapter 4 is organized into four business process application level
control categories:
* business process application level general controls [Footnote 36]
(also referred to as application security),
* business process controls,
* interface and conversion controls, and,
* data management systems controls.
The last three business process application level control categories
are collectively referred to as “business process application
controls.”
For each control category, the manual identifies critical
elements—tasks that are essential for establishing adequate controls
within the category. For each critical element, there is a discussion
of the associated objectives, risks, and control activities, as well as
related potential control techniques and suggested audit procedures.
This hierarchical structure facilitates the auditor’s analysis of
identified control weaknesses.
Within each relevant control activity, the auditor should identify
control techniques implemented by the entity and determine whether the
control techniques, as designed, are sufficient to achieve the control
activity. If sufficient, the auditor should determine whether the
control techniques are implemented (placed in operation) and are
operating effectively. Also, the auditor should evaluate the nature and
extent of testing performed by the entity. Such information can assist
in identifying key controls and in assessing risk, but the auditor
should not rely on testing performed by the entity in lieu of
appropriate auditor testing. As discussed later in this section, if the
control techniques implemented by the entity, as designed, are not
sufficient to address the control activity, or the control techniques
are not effectively implemented as designed, the auditor should
determine the effect on IS controls and the audit objectives.
The auditor identifies control techniques and determines the
effectiveness of controls at each of the following levels:
* Entitywide or component level.(general controls) Controls at the
entity or component level consist of the entitywide or componentwide
processes designed to achieve the control activities. They are focused
on how the entity or component manages IS related to each general
control activity in Chapter 3. For example, the entity or component may
have an entitywide process for configuration management, including
establishment of accountability and responsibility for configuration
management, broad policies and procedures, development and
implementation of monitoring programs, and possibly centralized
configuration management tools. The absence of entitywide processes may
be a root cause of weak or inconsistent controls, by increasing the
risk that IS controls are not applied consistently across the
organization.
* System level (general controls). Controls at the system level consist
of processes for managing specific system resources related to either a
general support system or major application. These controls are more
specific than those at the entity or component level and generally
relate to a single type of technology. Within the system level are
three further levels that the auditor should assess: network, operating
system, and infrastructure application. The three sublevels can be
defined as follows:
- Network. A network is an interconnected or intersecting configuration
or system of components. For example, a computer network allows
applications operating on various computers to communicate.
- Operating system. An operating system is software that controls the
execution of computer programs and may provide various services. For
example, an operating system may provide services such as resource
allocation, scheduling, input/output control, and data management.
- Infrastructure applications. Infrastructure applications are software
that is used to assist in performing systems operations, including
management of network devices. These applications include databases, e-
mail, browsers, plug-ins, utilities, and applications not directly
related to business processes.
For example, infrastructure applications allow multiple processes
running on one or more machines to interact across a network. For an
example of the identification of system level controls, take
configuration management. The auditor who is evaluating configuration
management at the system level should determine whether the entity has
applied appropriate configuration management practices for each
significant type of technology (e.g., firewalls, routers) in each of
the three sublevels (e.g., specific infrastructure applications). Such
configuration management practices typically include standard
configuration guidelines for the technology and tools to effectively
determine whether the configuration guidelines are effectively
implemented.
* Business process application level. Controls at the business process
application level consist of policies and procedures for controlling
specific business processes. For example, the entity’s configuration
management should reasonably ensure that all changes to application
systems are fully tested and authorized.
Chapter 3 includes general control activities that are applicable to
the entitywide and system levels, and Chapter 4 includes the general
controls applied at the business process application level (also
referred to as application security) as well as the three categories of
business process application controls. The control techniques for
achieving the control activities and the related audit tests vary
according to the level to which they are being applied. However, they
are described at a high level in this manual, and these descriptions
assume some expertise about the subject to be effectively performed.
Thus, the auditor should develop more detailed audit steps based on the
entity’s specific software and control techniques, after consulting
with the financial or performance auditor about audit objectives and
significant areas of audit interest. This manual lists specific control
activities and techniques and related suggested audit procedures. Table
1 shows the control categories applicable at each level.
Table 1: Control Categories Applicable at Different Levels of Audit:
General Controls:
Control Categories: Security Management:
Entitywide/Component Level: Applicable;
System Level, Network: Applicable;
System Level, Operating Systems: Applicable;
System Level, Infrastructure Applications: Applicable;
Business Process Application Level: Applicable.
Control Categories: Access Controls:
Entitywide/Component Level: Applicable;
System Level, Network: Applicable;
System Level, Operating Systems: Applicable;
System Level, Infrastructure Applications: Applicable;
Business Process Application Level: Applicable.
Control Categories: Configuration Management:
Entitywide/Component Level: Applicable;
System Level, Network: Applicable;
System Level, Operating Systems: Applicable;
System Level, Infrastructure Applications: Applicable;
Business Process Application Level: Applicable.
Control Categories: Segregation of Duties:
Entitywide/Component Level: Applicable;
System Level, Network: Applicable;
System Level, Operating Systems: Applicable;
System Level, Infrastructure Applications: Applicable;
Business Process Application Level: Applicable.
Control Categories: Contingency Planning:
Entitywide/Component Level: Applicable;
System Level, Network: Applicable;
System Level, Operating Systems: Applicable;
System Level, Infrastructure Applications: Applicable;
Business Process Application Level: Applicable.
Business Process Application Controls:
Control Categories: Business Process Controls:
Entitywide/Component Level: Not applicable;
System Level, Network: Not applicable;
System Level, Operating Systems: Not applicable;
System Level, Infrastructure Applications: Not applicable;
Business Process Application Level: Applicable.
Control Categories: Interfaces:
Entitywide/Component Level: Not applicable;
System Level, Network: Not applicable;
System Level, Operating Systems: Not applicable;
System Level, Infrastructure Applications: Not applicable;
Business Process Application Level: Applicable.
Control Categories: Data Management Systems:
Entitywide/Component Level: Not applicable;
System Level, Network: Not applicable;
System Level, Operating Systems: Not applicable;
System Level, Infrastructure Applications: Not applicable;
Business Process Application Level: Applicable.
Source: GAO.
[Ed of table]
The auditor should evaluate the effectiveness of IS controls including
system and/or application level controls related to each critical
control point. The auditor should evaluate all potential ways in which
the critical control point could be accessed. Generally, for each
critical control point, this would include assessing controls related
to the network, operating system, and infrastructure application
components. For example, if a particular router was deemed to be a
critical control point, the auditor generally should test controls
related to the router itself (a network component), its operating
system, and the infrastructure application that is used to manage the
router. Access to any of these could lead to access to the control
point. See the discussion of control dependencies in the above section
entitled “Identify Critical Control Points”.
As discussed in audit planning (section 2.1.2), the auditor determines
the appropriate scope of the IS controls audit, including:
* the organizational entities to be addressed (e.g., entitywide,
selected component(s), etc.);
* the breadth of the audit (e.g., overall conclusion on IS control
effectiveness, review of a specific application or technology area,
such as wireless or UNIX, etc.);
* the types of IS controls to be tested:
* general and/or business process application level controls to be
tested, or selected components; or;
* all levels of the entity’s information systems, or selected levels
(e.g., entitywide, system level, or business process application level,
or selected components of them.
The auditor should perform the following procedures as part of testing
the effectiveness of information system controls:
* Understand information systems relevant to the audit objectives,
building on identification of key areas of audit interest and critical
control points.
* Determine which IS control techniques are relevant to the audit
objectives. The control categories, critical elements, and control
activities in Chapters 3 and 4 are generally relevant to all audits.
However, if the auditor is not performing a comprehensive audit, for
example, an application review, then there may be no need to assess
controls in Chapter 3.
* For each relevant IS control technique, determine whether it is
suitably designed to achieve the critical activity and has been
implemented -- placed in operation (if not done earlier).
* Perform tests to determine whether such control techniques are
operating effectively.
* Identify potential weaknesses in IS controls. For each potential
weakness, consider the impact of compensating controls or other factors
that mitigate or reduce the risks related to potential weaknesses.
Understand Information Systems Relevant to the Audit Objectives:
The auditor should obtain and document an understanding of the
information processing steps performed in information systems that are
significant to the audit objectives, including:
* The manner in which transactions are initiated;
* The nature and type of records and source documents;
* The processing involved from the initiation of transactions to their
final processing, including the nature of computer files and the manner
in which they are accessed, updated, and deleted; and;
* For financial audits, the process used to prepare the entity's
financial statements and budget information, including significant
accounting estimates, disclosures, and computerized processing.
This understanding builds on information obtained in audit planning
(e.g., identification of key areas of audit interest and critical
control points). For efficiency, the auditor may combine this step with
audit planning to aid in the identification of relevant controls. The
auditor should perform and document walk-throughs for all business
process applications that are significant to the audit objectives. Walk-
throughs are important for understanding the information processing and
for determining appropriate audit procedures.
Identify IS Control Techniques That Are Relevant to the Audit
Objectives:
Based on the results of audit planning and other procedures performed,
the auditor should identify the control categories, critical elements,
control activities, and control techniques that are relevant to the IS
audit. In doing this, the auditor considers the audit objectives and
audit scope, the extent of IS risk and the preliminary understanding of
IS controls. The process for identifying relevant control techniques is
summarized below.
For IS audits that are stand alone GAGAS audits, generally all of the
control categories, critical elements, and control activities are
relevant to the audit objectives, unless specifically not part of the
audit objectives. For example, in an evaluation of the effectiveness of
business process controls in a specific application, the general
controls in Chapter 3 may or may not be part of the audit objectives.
At the entitywide level and for each critical control point (including
control dependencies) at the system and business process application
levels, the auditor should identify and document the control techniques
used by the entity to achieve each relevant control activity. For
purposes of illustration, using the example of the router serving as a
critical control point (as discussed in section 2.1.7), the auditor
would identify and document the control techniques used by the entity
to achieve the control activities related to each relevant control
category and critical element for the router and for the related
control dependencies.
If the IS audit is part of a broader financial audit, performance
audit, or attestation engagement, the auditor should obtain, from the
overall audit team, audit documentation that identifies internal
controls that are significant to the audit objectives. For financial
audits performed under the FAM, such controls are identified in the SCE
form. For each internal control technique that is identified as
significant to the audit objectives (significant control technique),
the audit team should determine whether it is an IS control. An IS
controls specialist generally should review and concur with the audit
team’s identification of IS controls, particularly with respect to
whether all IS controls were properly identified as such.
The auditor should identify and document the other entitywide, system,
and business process level IS controls upon which the effectiveness of
each significant IS control technique depends. These other IS controls
will principally relate to the entitywide level controls and to
controls over each of the critical control points (including control
dependencies) at the system and business process application levels.
For example, if the IS control is the review of an exception report,
the auditor should identify and test the business process application
controls directly related to the production of the exception report, as
well as the general and other business process application controls
upon which the reliability of the information in the exception report
depends, including the proper functioning of the business process
application that generated the exception report and the reliability of
the data used to generate the exception report. In addition, the
auditor should test the effectiveness of the user control (i.e.,
management review and followup on the items in the exception report).
For each relevant IS control technique, the auditor should determine
whether it is (1) designed effectively to achieve the related control
activity, considering IS audit risk and the audit objectives, and (2)
implemented (placed in operation). The auditor may be able to determine
whether control techniques are sufficient to achieve a particular
control activity without evaluating and testing all of the control
techniques. Also, depending on IS audit risk and the audit objectives,
the nature and extent of control techniques necessary to achieve a
particular control objective will vary.
The auditor generally should evaluate the design effectiveness and test
only the control techniques necessary to achieve the relevant audit
activities. For example, if there are two control techniques, each of
which individually would achieve the control activity, the auditor
generally would evaluate and test only one control technique. However,
if the auditor determines that the control technique evaluated and
tested was not effective, the auditor would consider the effectiveness
of the other control technique.
Also, the auditor should evaluate the nature and extent of testing
performed by the entity. Such information can assist in identifying key
controls and in assessing risk, but the auditor should not rely on
testing performed by the entity in lieu of appropriate auditor testing.
If the control techniques implemented by the entity, as designed, are
not sufficient to address the control activity, or the control
techniques are not effectively implemented as designed, the auditor
should determine the effect on IS controls and the audit objectives.
For efficiency, the auditor may implement a tiered approach to the
identification and evaluation of the design effectiveness of relevant
IS control techniques, as discussed later in this session, beginning
with entitywide level controls, followed by system level controls, then
by business process application level controls.
Appendices II and III may be used to identify and summarize relevant IS
controls at the entitywide, system, and business process application
levels.
Test Information System Controls:
The auditor should design and conduct tests of relevant control
techniques that are effective in design to determine their
effectiveness in operation.
It is generally more efficient for the auditor to test IS controls on a
tiered basis, starting with the general controls at the entitywide and
system levels, followed by the general controls at the business process
application level, and concluding with tests of business process
application, interface, and data management system controls at the
business process application level. Such a testing strategy may be used
because ineffective IS controls at each tier generally preclude
effective controls at the subsequent tier.
If the auditor identifies IS controls for testing, the auditor should
evaluate the effectiveness of:
* general controls at the entitywide and system level;
* general controls at the business process application level; and;
* specific business process application controls (business process
controls, interface controls, data management system controls), and/or
user controls, unless the IS controls that achieve the control
objectives are general controls.
The auditor should determine whether entitywide and system level
general controls are effectively designed, implemented, and operating
effectively by:
* identifying applicable general controls;
* determining how those controls function, and whether they have been
placed in operation; and;
* evaluating and testing the effectiveness of the identified controls.
The auditor generally should use knowledge obtained in the planning
phase. The auditor should document the understanding of general
controls and should conclude whether such controls are effectively
designed, placed in operation, and, for those controls tested,
operating as intended.
Tests of General Controls at the Entitywide and System Levels:
The auditor may test general controls through a combination of
procedures, including observation, inquiry, inspection (which includes
a review of documentation on systems and procedures), and reperformance
using appropriate test software. Although sampling is generally not
used to test general controls, the auditor may use sampling to test
certain controls, such as those involving approvals.
If general controls at the entitywide and system levels are not
effectively designed and operating as intended, the auditor will
generally be unable to obtain satisfaction that business process
application-level controls are effective. In such instances, the
auditor should (1) determine and document the nature and extent of
risks resulting from ineffective general controls and (2) identify and
test any manual controls that achieve the control objectives that the
IS controls were to achieve.
However, if manual controls do not achieve the control objectives, the
auditor should determine whether any specific IS controls are designed
to achieve the objectives. If not, the auditor should develop
appropriate findings principally to provide recommendations to improve
internal control. If specific IS controls are designed to achieve the
objectives, but are in fact ineffective because of poor general
controls, testing would typically not be necessary, except to support
findings.
Tests of General Controls at the Business Process Application Level:
If the auditor reaches a favorable conclusion on general controls at
the entitywide and system levels, the auditor should evaluate and test
the effectiveness of general controls for those applications within
which business process application controls or user controls are to be
tested. These business process application level general controls are
referred to as Application Security (AS) controls in Chapter 4.
If general controls are not operating effectively within the business
process application, business process application controls and user
controls generally will be ineffective. If the IS controls audit is
part of a financial or performance audit, the IS controls specialist
should discuss the nature and extent of risks resulting from
ineffective general controls with the audit team. The auditor should
determine whether to proceed with the evaluation of business process
application controls and user controls.
Tests of Business Process Application Controls and User Controls:
The auditor generally should perform tests of those business process
application controls (business process, interface, data management),
and user controls necessary to achieve the control objectives where the
entitywide, system, and application-level general controls were
determined to be effective.
If IS controls are not likely to be effective, the auditor should
obtain a sufficient understanding of control risks arising from
information systems to:
* identify the impact on the audit objectives,
* design audit procedures, and,
* develop appropriate findings. Also, in such circumstances, the
auditor considers whether manual controls achieve the control
objectives, including manual controls that may mitigate weaknesses in
IS controls. If IS controls are not likely to be effective and if
manual controls do not achieve the control objectives, the auditor
should identify and evaluate any specific IS controls that are designed
to achieve the control objectives to develop recommendations for
improving internal controls.
IS controls that are not effective in design do not need to be tested.
If the auditor determined in a prior year that controls in a particular
accounting application were ineffective and if management indicates
that controls have not significantly improved, the auditor need not
test them.
2.2.2 Appropriateness of Control Tests:
To assess the operating effectiveness of IS controls, auditors should
perform an appropriate mix of audit procedures to obtain sufficient,
appropriate evidence to support their conclusions. Such procedures
could include the following:
* Inquiries of IT and management personnel can enable the auditor to
gather a wide variety of information about the operating effectiveness
of control techniques. The auditor should corroborate responses to
inquiries with other techniques.
* Questionnaires can be used to obtain information on controls and how
they are designed.
* Observation of the operation of controls can be a reliable source of
evidence. For example, the auditor may observe the verification of edit
checks and password controls. However, observation provides evidence
about controls only when the auditor was present. The auditor needs
other evidence to be satisfied controls functioned the same way
throughout the period.
* The auditor may review documentation of control polices and
procedures. For example, the entity may have written policies regarding
confidentiality or logical access. Review of documents will allow the
auditors to understand and assess the design of controls.
* Inspection of approvals/reviews provides the auditor with evidence
that management is performing appropriate control checks. The auditor
may combine these tests with discussions and observations.
* Analysis of system information (e.g., configuration settings, access
control lists, etc.) obtained through system or specialized software
provides the auditor with evidence about actual system configuration.
* Data review and analysis of the output of the application processing
may provide evidence about the accuracy of processing. For example, a
detailed review of the data elements or analytical procedures of the
data as a whole may reveal the existence of errors. Computer-assisted
audit techniques (CAAT) may be used to test data files to determine
whether invalid transactions were identified and corrected by
programmed controls. However, the absence of invalid transactions alone
is insufficient evidence that the controls effectively operated.
* Reperformance of the control could be used to test the effectiveness
of some programmed controls by reapplying the control through the use
of test data. For example, the auditor could prepare a file of
transactions that contains known errors and determine if the
application successfully captures and reports the known errors.
Based on the results of the IS controls audit tests, the auditor should
determine whether the control techniques are operating effectively to
achieve the control activities. Controls that are not properly designed
to achieve the control activities or that are not operating effectively
are potential IS control weaknesses. For each potential weakness, the
auditor should determine whether there are specific compensating
controls or other factors that could mitigate the potential weakness.
If the auditor believes that the compensating controls or other factors
could adequately mitigate the potential weakness and achieve the
control activity, the auditor should obtain evidence that the
compensating or other control is effectively operating and actually
mitigates the potential weakness. If it effectively mitigates the
potential weakness, the auditor can conclude that the control activity
is achieved; however, the auditor may communicate such weaknesses to
the entity. If the potential weakness is not effectively mitigated, the
potential weakness is an actual weakness. The auditor evaluates its
effects on IS controls in combination with other identified weaknesses
in the reporting phase.
2.2.3 Documentation of Control Testing Phase:
Information developed in the testing phase that the auditor should
document includes the following:
* An understanding of the information systems that are relevant to the
audit objectives;
* IS Control objectives and activities relevant to the audit
objectives;
* By level (e.g., entitywide, system, business process application) and
system sublevel (e.g., network, operating system, infrastructure
applications), a description of control techniques used by the entity
to achieve the relevant IS control objectives and activities;
* By level and sublevel, specific tests performed, including:
- related documentation that describes the nature, timing, and extent
of the tests;
- evidence of the effective operation of the control techniques or lack
thereof (e.g., memos describing procedures and results, output of tools
and related analysis);
- if a control is not achieved, any compensating controls or other
factors and the basis for determining whether they are effective;
- the auditor’s conclusions about the effectiveness of the entity’s IS
controls in achieving the control objective; and;
- for each weakness, whether the weakness is a material weakness,
significant deficiency or just a deficiency, as well as the criteria,
condition, cause, and effect if necessary to achieve the audit
objectives.
Appendices II and III may be used to summarize the results of testing.
2.3 Report Audit Results:
After completing the testing phase, the auditor summarizes the results
of the audit, draws conclusions on the individual and aggregate effect
of identified IS control weaknesses on audit risk and audit objectives
and reports the results of the audit. The auditor evaluates the
individual and aggregate effect of all identified IS control weaknesses
on the auditor’s conclusions and the audit objectives. The auditor
evaluates the effect of any weaknesses on the entity’s ability to
achieve each of the critical elements in Chapters 3 and 4 and on the
risk of unauthorized access to key systems or files. Also, the auditor
evaluates potential control dependencies.
For each critical element, the auditor should make a summary
determination as to the effectiveness of the entity’s related controls,
considering entitywide, system, and business process application levels
collectively. The auditor should evaluate the effect of related
underlying control activities that are not achieved. In addition, the
auditor should determine whether the weaknesses preclude the
effectiveness of each of the five categories of general controls or the
four categories of application-level controls. If the controls for one
or more of each category’s critical elements are ineffective, then the
controls for the entire category are not likely to be effective. The
auditor uses professional judgment in making such determinations. For
federal entities, if identified weaknesses relate to IS measures
reported in FISMA reporting, the auditor should determine whether they
were properly reported. Also, the auditor should determine whether IS
control weaknesses identified by the audit were identified in the
entity’s Plans of Action and Milestones (POA&M’s) or equivalent
document. If not, the auditor generally should attempt to determine why
they were not identified by the entity as appropriate and report
weaknesses in the reporting process.
Also, the auditor should evaluate whether the aggregate combination of
weaknesses could result in unauthorized access to systems or files
supporting key areas of audit interest. Guidance for evaluating IS
controls and determining the appropriate reporting are discussed
separately for financial audits and attestation engagements and for
performance audits in the following sections.
For example, a series of weaknesses might result in individuals having
the ability to gain unauthorized external access to agency systems,
escalate their privileges to obtain a significant level of access to
critical control points, and consequently achieve access to key areas
of audit interest. The auditor can use simplified network schematics
annotated with weaknesses related to key system components to document
the impact of a series of weaknesses. Such documentation may be
developed as the audit progresses, allowing the auditor to demonstrate
on the system that the weaknesses in fact exist and can be exploited to
achieve the expected result. Also, such documentation can assist in
communicating the related risks to entity management. Figure 3 is an
example of a simplified network schematic annotated with weaknesses
related to key system components.
Figure 3. Example of Network Schematic Describing System Weaknesses:
[See PDF for image]
This figure is an illustration of a network schematic describing system
weaknesses. The following items and information are depicted:
1) Router:
* Access lists not applied;
* Unencrypted management protocols.
2) Firewall;
3) Intrusion detection system:
* Ineffective with encrypted traffic;
* Full data capture not performed;
* Default installation.
4) Server:
* Operating system, database management system, and application servers
unpatched and vulnerable;
* Unnecessary and vulnerable services;
* Weak certificate management;
* Weak session management;
* Clear text passwords;
* Application input not effective.
5) Switch (see number 9);
6) Firewall:
* Excessive rules (in/out);
* unpatched and vulnerable firewall and operating system.
7) Wireless access:
* unencrypted protocols;
* Unauthorized wireless access points;
* Terminates on internal network.
8) Switch (see number 9);
9) Network devices:
* Unpatched and vulnerable services;
* Default Simple Network Management Protocols read/write strings;
* Network not segmented;
* Access lists not applied;
* Unencrypted management protocols.
10) Workstations:
* Operating system unpatched and vulnerable;
* Applications unpatched and vulnerable;
* Unnecessary and vulnerable services;
* Users running as local admin;
* Insecure Active X settings;
* Personal firewalls not used.
11) Servers:
* Operating system and management system unpatched and vulnerable;
* Unnecessary and vulnerable services;
* Poorly configured services;
* Outdated and vulnerable applications;
* Default and easily guessed passwords;
* Excessive directory and file permissions;
* Unencrypted or weak protocols.
Source: GAO.
[End of figure]
Further, the auditor should evaluate the potential impact of any
identified weaknesses on the completeness, accuracy, validity, and
confidentiality of application data relevant to the audit objectives.
(See Chapter 4 for a description of completeness, accuracy, validity,
and confidentiality.)
When IS controls audits are performed as part of a broader financial or
performance audit or attestation engagement, the IS controls specialist
should coordinate with the auditor to determine whether significant
controls are dependent on IT processing. In very rare circumstances,
the auditor may determine that IS controls, in the aggregate, are
ineffective, but that the entity has overall compensating controls not
dependent on IT processing or that other factors mitigate or reduce the
risks arising from IS control weaknesses. For example, manual reviews
of support for all disbursements could mitigate certain IS risks
related to a disbursement system. If compensating controls or other
factors are present, the auditor should document such controls or
factors, test them appropriately to determine whether they effectively
mitigate the identified IS control weaknesses, and draw conclusions
about the nature and extent of the risks that remain after considering
such controls or factors.
As noted earlier in the section entitled “Understand the Overall Audit
Objectives and Related Scope of the Information System Controls Audit,”
if achieving the audit objectives does not require an overall
conclusion on IS controls or only relates to certain components of the
entity or a subset of controls, the auditor’s assessment would not
necessarily identify all significant IS control weaknesses. For
example, a limited review of controls over a type of operating system
may not identify any significant weaknesses, although there may be very
significant weaknesses in other areas that the auditor may not be aware
of because of the limited scope of the audit. Consequently, the auditor
should evaluate the potential limitations of the auditor’s work on the
auditor’s report and the needs and expectations of users. The auditor
may determine that, because the limitations are so significant, the
auditor (1) will communicate the limitations to the audited entity,
those charged with governance, and those requesting the audit and (2)
clearly report such limitations on the conclusions in the audit report.
For example, in reporting on an audit of an operating system, the
auditor may determine that it is appropriate to clearly report that the
scope of the assessment was limited to the operating system and that,
consequently, additional IS control weaknesses may exist that could
impact the effectiveness of IS controls related to the operating system
and to the entity as a whole.
The auditor should express the effect of identified IS control
weaknesses in terms of the audit objectives. The following sections
provide guidelines for assessing IS controls in financial and
performance audits. For financial audits and attestation engagements,
GAGAS states that auditors should report material weaknesses and other
significant deficiencies.
2.3.1 Financial Audits and Attestation Engagements:
The auditor should conclude whether IS control weaknesses, individually
or in the aggregate, constitute a significant deficiency or material
weakness in financial reporting. The auditor should coordinate these
procedures with the overall audit team. For financial audits, GAGAS and
OMB Circular A-123 state that a control deficiency exists when the
design or operation of a control does not allow management or
employees, in the normal course of performing their assigned functions,
to prevent or detect misstatements on a timely basis. A deficiency in
design exists when (a) a control necessary to meet the control
objective is missing or (b) an existing control is not properly
designed so that even if the control operates as designed, the control
objective is not always met. A deficiency in operation exists when a
properly designed control does not operate as designed or when the
person performing the control does not possess the necessary authority
or qualifications to perform the control effectively. In addition, in
financial audits of federal entities, the auditor should evaluate the
effect of IS control weaknesses on FFMIA and FMFIA reporting.
GAGAS uses the following definitions and guidelines for classifying
internal control weaknesses:
A significant deficiency is a deficiency in internal control, or
combination of deficiencies, that adversely affects the entity’s
ability to initiate, authorize, record, process, or report financial
data reliably in accordance with generally accepted accounting
principles such that there is more than a remote likelihood [Footnote
37] that a misstatement of the entity’s financial statements that is
more than inconsequential[Footnote 38] will not be prevented or
detected.
A material weakness is a significant deficiency, or combination of
significant deficiencies, that results in more than a remote likelihood
that a material misstatement of the financial statements will not be
prevented or detected.
OMB Circular A-123 uses the same definition for significant deficiency,
but continues to refer to it as a reportable condition.
In determining whether IS control deficiencies, individually or in the
aggregate, constitute a significant deficiency or material weakness,
the auditor should evaluate several factors, including the following:
* The likelihood that an individual could obtain unauthorized access to
or perform unauthorized or inappropriate activities on key entity
systems or files that could affect information recorded in the
financial statements. This might include (1) the ability to obtain root
access to systems that house key financial systems (including feeder
systems), thereby enabling unauthorized users to read, add, delete, or
modify financial data either directly or through the introduction of
unauthorized software; (2) the ability to directly access and modify
files containing financial information; or (3) the ability to assign
unauthorized application user rights, thereby entering unauthorized
transactions.
* The nature of unauthorized access that could be obtained (e.g.,
limited to system or application programmers or system administrators;
all authorized system users; or anyone through unauthorized external
access through the Internet) or the nature of unauthorized or
inappropriate activity that could be performed.
* The likelihood that financial statement amounts could be materially
affected.
* The likelihood that other controls including business process
application controls would prevent or detect such unauthorized access.
Generally, if the effectiveness of such other controls depends on
computer processed information, it is unlikely that they could
effectively prevent or detect such access, unless the identified IS
control weaknesses could not reasonably result in the ability to
compromise such other controls.
* The risk that management could override controls (such as through
excessive access rights).
Based upon these considerations, the auditor should determine whether
IS control deficiencies, individually or in the aggregate, are a
material weakness or significant deficiency. Also, the auditor should
evaluate whether significant deficiencies, in combination, result in
material weaknesses. If so, the auditor should determine them to be
material weaknesses in drawing conclusions as to the effectiveness of
internal control and reporting findings, as discussed in FAM paragraphs
580.42–.48 and 580.51–.58. If the control deficiencies constitute a
material weakness, the auditor should conclude that internal controls
are not effective.
Financial auditors may take one of two different approaches to
reporting on internal control: (1) express an opinion on internal
control (see FAM paragraphs 580.38-.48) or (2) report weaknesses found,
categorized as material weaknesses or other significant deficiencies,
but do not give an opinion (see FAM paragraphs 580.49-.50). GAO
auditors generally express an opinion on internal control. In either
case, the auditor considers whether internal control is sufficient to
meet the following control objectives insofar as those objectives
pertain to preventing or detecting misstatements, losses, or
noncompliance that would be material in relation to the financial
statements:
* Reliability of financial reporting—transactions are properly
recorded, processed, and summarized to permit the preparation of the
financial statements and supplemental information in accordance with
Generally Accepted Accounting Principles (GAAP), and assets are
safeguarded against loss from unauthorized acquisition, use, or
disposition.
* Compliance with applicable laws and regulations—transactions are
executed in accordance with laws governing the use of budget authority;
other laws and regulations that could have a direct and material effect
on the financial statements or required supplementary information
(RSI); and any other laws, regulations, and governmentwide policies
identified by OMB in its audit guidance.
The auditor may report weaknesses that do not meet the criteria for
significant deficiencies in a letter to management or orally to an
appropriate level of the entity. The auditor may include suggestions
for corrective action for these less significant weaknesses if enough
is understood about their cause. (More detailed information on how and
where to report control weaknesses for financial statement audits is
presented in sections 580.48 through 580.52 of the FAM.)
2.3.2 Performance Audits:
The auditor should draw conclusions on the effectiveness of IS controls
relevant to the audit objectives. Depending on the audit objectives,
the auditor’s report will vary. For example, the auditor’s report may:
* provide an overall conclusion (e.g., the entity’s IS controls are or
are not effective in achieving the IS control objectives relevant to
the audit) and communicate identified weaknesses;
* limit reporting to identified weaknesses without providing an overall
conclusion (e.g., “based on our work, we identified the following IS
control weaknesses”); or;
* if in support of a broader performance audit, report findings in the
context of the audit objectives, such as how they relate to the
assessment of the reliability of computer-processed data.
GAGAS state that auditors should include in their audit reports the
scope of their work on internal control (which includes IS controls)
and any deficiencies in internal control that are significant within
the context of the audit objectives and based upon the audit work
performed. Determining whether and how to communicate to officials of
the audited entity internal control deficiencies that have an
inconsequential effect on the financial statement or subject matter is
a matter of professional judgment. Auditors should document such
communications. The auditor may report such inconsequential weaknesses
orally to officials of the entity or in a separate written
communication.
In determining the significance of the IS control weaknesses, the
auditor should evaluate several factors, including the following:
* The likelihood that an individual could obtain unauthorized access to
or perform unauthorized or inappropriate activities on key entity
systems or files that could affect key areas of audit interest. This
might include (1) the ability to obtain root access to systems that
house key areas of audit interest (including supporting systems),
thereby enabling an intruder to read, add, delete, or modify data
either directly or through the introduction of unauthorized software;
(2) the ability to directly access and modify files related to key
areas of audit interest; or (3) the ability to assign unauthorized
application user rights, thereby enabling an intruder to enter
unauthorized transactions or perform unauthorized activities.
* The nature of unauthorized access that could be obtained (e.g.,
limited to system or application programmers or system administrators;
authorized system users; or anyone through unauthorized external access
through the Internet).
* The likelihood that the achievement of the audit objectives would be
significantly affected.
* The likelihood that other controls including business process
application controls would prevent or detect such unauthorized access.
Generally, if the effectiveness of such other controls depends on
computer processed information, it is unlikely that they could
effectively prevent or detect such access, unless the identified IS
control weaknesses could not reasonably result in the ability to
compromise such other controls.
* The risk that management could override controls (such as through
excessive access rights).
2.3.3 Other Audit Reporting Considerations:
It is important to report IS control weaknesses in terms that are
understandable to individuals who may have limited expertise regarding
information systems issues. In this regard, the auditor generally
should define technical terms and avoid jargon and undefined
abbreviations and acronyms.
Auditors should develop the elements of the findings to the extent
necessary to achieve the audit objectives. The extent to which the
auditor should develop the elements for a finding (criteria, condition,
cause, and effect) depends on the audit objectives. If auditors are
able to sufficiently develop the findings, they should provide
recommendations for corrective action if they are significant within
the context of the audit objectives.
Criteria describe the required or desired state, or what is expected
from the program or operation. Condition is the actual situation. Cause
is the factor or factors responsible for the difference between
condition and criteria. Effect is the impact of the difference between
the condition and the criteria. This information helps senior
management understand the significance of the weakness and develop
appropriate corrective actions. For most types of IS control
weaknesses, this manual includes a discussion of risks and potential
negative effects that can be adapted for audit reports. GAO has issued
numerous reports that can be used as models for reporting computer-
related weaknesses. Current IS reports can be obtained from GAO’s
report database on GAO’s Web site [hyperlink, http://www.gao.gov].
In many cases, auditors will have detailed information on control
weaknesses that is too technical to be meaningful to most senior
managers and other users of the audit report, but may be valuable to
the audit report, but that may be valuable to the entity’s technical
staff in understanding the precise cause of the weaknesses and in
developing corrective actions. The auditors generally should provide
this information to the entity’s technical staff in briefings. The
auditor should provide information to technical staff that is in
substance the same as that reported to senior management.
The auditor should effectively communicate the results of an IS
controls audit to the appropriate persons through appropriate reports.
This serves several purposes, including:
* informing the audited entity and those charged with governance of
control weaknesses; issues of noncompliance with laws, regulations, and
provisions of contracts or grant agreements; and instances of fraud,
illegal acts, or abuse;
* providing the audited entity with recommendations to correct such
control weaknesses;
* providing the financial or performance auditor an understanding of
the information systems control environment and the effects of IT on
the processing of transactions;
* complying with legal reporting requirements; and;
* complying with auditing standards, including generally accepted
government auditing standards.
However, the auditor should avoid the disclosure of sensitive IS data.
An individual could potentially compromise a system from any location
in the world, as long as they have access to a computer and a telephone
line or Internet connection. Technical information discussed in an
audit report could potentially assist individuals by reducing the time
and effort to obtain unauthorized access and compromise a system. Also,
to avoid disclosure of sensitive information, the auditor should
provide draft IS reports to the entity for a sensitivity review. The
auditor should evaluate entity sensitivity concerns and make
appropriate report revisions, considering legal or regulatory
requirements, including the exercise of information classification
authority.
Generally, in the federal environment, either one report with limited
distribution or two reports, one of which has limited distribution, are
issued. Information systems security audit reports may or may not be
put on agency Web sites or released under FOIA, generally depending on
the degree or extensiveness of sensitive data. Even though these
reports may not be posted on agency Web sites, they are still typically
issued to agency management. Also, state laws and regulations may
affect the form of reporting. For further information, see Information
Systems Security Auditing: Legal and Reporting Considerations.
[Footnote 39]
2.3.4 Related Reporting Responsibilities:
In addition to reporting the results of the audit, the auditor may have
other related reporting responsibilities established by law,
regulation, or policy. The auditor should identify any other reporting
requirements and respond appropriately.
In financial audits of federal entities, the auditor should determine
whether the IS control weaknesses, individually or in the aggregate,
constitute a material weakness for FMFIA reporting or a lack of
substantial compliance of the entity’s systems with FFMIA. See FAM
260.53-57 for further information. Also, further information about
reporting IS control weaknesses in relation to a financial audit are
discussed in FAM 580 (Draft Reports).
OMB Circular A-123 provides requirements for complying with FMFIA. The
Circular requires management to assess controls and provide an annual
assurance statement on the overall adequacy and effectiveness of
internal control within the agency. In addition, management is required
to provide a separate assurance statement on the effectiveness of
internal control over financial reporting, which includes safeguarding
of assets and compliance with applicable laws and regulations. Also,
OMB audit guidance requires management to include representations about
internal control in its management representation letter to the
auditor.
FMFIA requires agencies to evaluate and report on the adequacy of the
systems of internal accounting and administrative control. For the
overall assessment of internal control, OMB Circular A-123 defines a
material weakness as a reportable condition which the agency head
determines to be significant enough to report outside of the agency. It
defines a reportable condition as a control deficiency, or combination
of control deficiencies, that in management’s judgment, should be
communicated because they represent significant weaknesses in the
design or operation of internal control that could adversely affect the
organization’s ability to meet its internal control objectives. For the
assessment of internal control over financial reporting, Circular A-123
uses the same definitions for material weakness and significant
deficiency described above for financial audits, except that OMB uses
the term reportable condition rather than the term significant
deficiency. Also, FMFIA and OMB Circular A-123 require management to
report nonconformances with system requirements. The Circular defines
nonconformances as instances in which financial management systems do
not substantially conform to financial systems requirements. Financial
management systems include both financial and financially-related (or
mixed) systems.
The auditor should evaluate the material weaknesses reported under
FMFIA to determine whether they meet the definitions of material
weakness and reportable condition for reporting as part of management’s
assertion about the effectiveness of internal control.
FISMA requires federal agencies to report significant deficiencies in
IS as material weaknesses under FMFIA and, if relating to financial
management systems, as an instance of a lack of substantial compliance
of systems with FFMIA. The term “significant deficiency” used in FISMA
differs from the same term used in GAGAS. OMB defines a FISMA
significant deficiency as “a weakness in an agency’s overall
information systems security program or management control structure,
or within one or more information systems that significantly restricts
the capability of the agency to carry out its mission or compromises
the security of its information, information systems, personnel, or
other resources, operations, or assets. In this context, the risk is
great enough that the agency head and outside agencies must be notified
and immediate or near-immediate corrective action must be taken.” The
following points provide guidance in determining whether there is a
FISMA significant deficiency:
* If IS controls are ineffective with respect to one of the nine
control categories (see table 1), such ineffective control(s) represent
a FISMA significant deficiency.
* If IS controls are ineffective with respect to one or more critical
elements (that is, tasks that are essential for establishing adequate
controls within a given control category; examples are given in
Chapters 3 and 4), such ineffective control(s) represent a FISMA
significant deficiency unless, based upon the facts and circumstances,
other factors sufficiently mitigate the effect of the control
weaknesses.
* If individual weaknesses meet the above definition, such ineffective
control(s) represent FISMA significant deficiencies.
FFMIA requires agencies to implement and maintain financial management
systems that comply substantially with federal financial management
systems requirements, applicable federal accounting standards, and the
U.S. Government Standard General Ledger[Footnote 40] at the transaction
level. FFMIA requires auditors to assess whether an agency’s financial
management systems comply with system requirements. IS control
weaknesses are a major concern for federal agencies and the general
public and are one of the frequently cited reasons for noncompliance
with FFMIA.
2.3.5 Documentation of Reporting Phase:
The auditor should document appropriate IS information developed in the
reporting phase, including:
* The auditor’s conclusion about the effectiveness of IS controls (in
relation to the IS controls audit objectives) in achieving the critical
elements and the relevant control activities and the basis for the
conclusion, including the factors that the auditor considered in making
the determination.
* If part of a broader audit, the impact of any identified IS control
weaknesses on the overall audit objectives.
* Copies of any reports or written communications issued in connection
with the audit, including the draft the agency commented on and entity
management comments related to such reports and communications.
* For financial audits and attestation engagements, the auditor’s
determination of whether identified weaknesses represent material
weaknesses or significant deficiencies, and the basis for the auditor’s
conclusions.
* Other documentation required by the audit organization’s policies and
procedures, including quality assurance processes.
* Results of procedures to detect any fraud significant to the audit
objectives and the impact on the audit.
* Results of audit follow-up procedures to determine whether agency
corrective actions have been implemented, to sufficiently remediate
previously reported IS control weaknesses.
* As appropriate, the auditor’s considerations and determinations
concerning FMFIA, FFMIA, and other reporting responsibilities
2.4 Documentation:
The auditor should adequately document the IS controls audit. GAGAS has
general documentation requirements for financial and performance audits
and attestation engagements. In summary, they are as follows:
Financial Audits - Auditors must prepare audit documentation in
connection with each engagement in sufficient detail to provide a clear
understanding of the work performed (including the nature, timing,
extent, and results of audit procedures performed), the audit evidence
obtained and its source, and the conclusions reached. Auditors should
prepare audit documentation that enables an experienced auditor, having
no previous connection to the audit, to understand a. the nature,
timing, and extent of auditing procedures performed to comply with
GAGAS and other applicable standards and requirements; b. the results
of the audit procedures performed and the audit evidence obtained; c.
the conclusions reached on significant matters; and d. that the
accounting records agree or reconcile with the audited financial
statements or other audited information.
Attestation Engagements - Auditors must prepare attest documentation in
connection with each engagement in sufficient detail to provide a clear
understanding of the work performed (including the nature, timing,
extent, and results of attest procedures performed); the evidence
obtained and its source; and the conclusions reached. Auditors should
prepare attest documentation in sufficient detail to enable an
experienced auditor, having no previous connection to the attestation
engagement, to understand from the documentation the nature, timing,
extent, and results of procedures performed and the evidence obtained
and its source and the conclusions reached, including evidence that
supports the auditors’ significant judgments and conclusions. Auditors
should prepare documentation that contains support for findings,
conclusions, and recommendations before they issue their report.
Auditors also should document the following for attestation engagements
performed under GAGAS: a. the objectives, scope, and methodology of the
attestation engagement; b. the work performed to support significant
judgments and conclusions, including descriptions of transactions and
records examined; c. evidence of supervisory review, before the attest
report is issued, of the work performed that supports findings,
conclusions, and recommendations contained in the attest report; and d.
the auditors’ consideration that the planned procedures are designed to
achieve objectives of the attestation engagement when (1) evidence
obtained is dependent on computerized information systems, (2) such
evidence is material to the objective of the engagement, and (3) the
auditors are not relying on the effectiveness of internal control over
those computerized systems that produced the evidence. Auditors should
document (1) the rationale for determining the nature, timing, and
extent of planned procedures; (2) the kinds and competence of available
evidence produced outside a computerized information system, or plans
for direct testing of data produced from a computerized information
system; and (3) the effect on the attestation engagement report if
evidence to be gathered does not afford a reasonable basis for
achieving the objectives of the engagement.
Performance Audits – Auditors must prepare audit documentation related
to planning, conducting, and reporting for each audit. Auditors should
prepare audit documentation in sufficient detail to enable an
experienced auditor, having no previous connection to the audit, to
understand from the audit documentation the nature, timing, extent, and
results of audit procedures performed, the audit evidence obtained and
its source and the conclusions reached, including evidence that
supports the auditors’ significant judgments and conclusions. Auditors
should prepare audit documentation that contains support for findings,
conclusions, and recommendations before they issue their report.
Auditors should document the following: a. the objectives, scope, and
methodology of the audit; b. the work performed to support significant
judgments and conclusions, including descriptions of transactions and
records examined; and c. evidence of supervisory review, before the
audit report is issued, of the work performed that supports findings,
conclusions, and recommendations contained in the audit report.
In addition to meeting these general requirements, the auditor should
include, in IS controls audit documentation, the specific information
discussed throughout this chapter, and summarized in Appendix XI.
2.5 Other Information System Controls Audit Considerations:
In addition to the above, the auditor should apply the following topics
and techniques to the extent they are relevant to the entity, the audit
objectives, and the audit procedures.
* Additional IS risk factors.
* Automated audit tools.
* Sampling techniques Also, guidance is provided to the auditor in the
evaluation of IS controls associated with service organizations, single
audits, and FISMA independent evaluations. Guidance on each of these
areas is included in Appendix VII, VIII, and IX, respectively.
2.5.1 Additional IS Risk Factors:
As part of the risk assessment, the auditor should also evaluate the
following additional IS risk factors to the extent that they are
relevant to the entity and the audit objectives. The auditor’s risk
assessment also includes other risk factors not listed here (e.g.,
Voice over Internet Protocol – VoIP)
2.5.1.A Defense-In-Depth Strategy:
Defense-in-Depth is a commonly accepted “best practice” for
implementing computer security controls in today’s networked
environments. In some agencies, the auditor may encounter this strategy
as part of the agency’s security management program. Where an effective
Defense-in-Depth strategy has been implemented by the entity, the
auditor’s assessment of IS risk would generally be lower. Conversely,
where this strategy is not used, the auditor’s assessment of IS risk
would generally be higher. The auditor’s IS control testing generally
provides evidence about the effectiveness of a Defense-in-Depth
strategy. See Chapter 3 (AC-1 and CM-5) for additional information on
Defense-in-Depth strategy.
According to the National Security Agency, Defense-in-Depth integrates
people, operations, and technology capabilities to protect information
systems across multiple layers and dimensions. For example, successive
layers of defense will cause an adversary who penetrates or breaks down
one barrier to promptly encounter successive barriers until the attack
ends. The strategy recommends a balance between protection capabilities
and cost, performance, and operational considerations.
The people component of Defense-in-Depth begins with a senior-level
management commitment (normally at the chief information officer level)
that is based on a clear understanding of the perceived threat. This
component must be implemented with effective information security
policies and procedures, assignment of roles and responsibilities,
commitment of resources, training and awareness programs (for both
users and system administrators), and personnel accountability, which
includes the establishment of physical and personnel security measures
to control and monitor access to facilities and critical elements of
the information technology environment.
The operations component focuses on all activities required to sustain
an agency’s security posture on a day-to-day basis. These activities
include:
* maintaining up-to-date system security policies,
* establishing certification and accreditation programs,
* managing information system security (for example, installing patches
and virus updates, maintaining access control lists),
* performing system security assessments (for example, vulnerability
assessments),
* auditing and monitoring system activity and responding to threats,
and;
* implementing recovery and reconstitution procedures in the event of a
security breach.
The technology component includes defense in multiple places and
layered defense mechanisms that provide intrusion prevention,
detection, and response to security incidents. Since attackers may
target multiple points in an information system, an agency needs to
deploy protection mechanisms at multiple locations including the
protection of local and wide area communication networks (for example,
from denial of service attacks), protection for data transmitted over
the networks (for example, use of encryption and traffic flow security
measures), defense of enclave boundaries (for example, deploy firewalls
and intrusion detection systems), and defense of the computing
environment (for example, access control on hosts and servers). Even
the best security products have inherent weaknesses, so it is only a
matter of time before an attacker finds an exploitable vulnerability.
Therefore, it is important to deploy layered defense mechanisms such as
nested firewalls coupled with intrusion detection at outer and inner
network boundaries, between the adversary and the target.
2.5.1.B Web Applications:
Web applications, which use a web browser as part of the application,
present significant additional IS risks because, if not properly
controlled, they can expose the application and the entity’s systems to
unauthorized access. In some instances, the risk related to the
application itself may be low because it is not critical or it does not
contain sensitive information. However, if not properly controlled, it
could be used to obtain unauthorized access to other entity system
resources. Therefore, due to the heightened risk, even if a web
application itself is not part of the scope of the audit, the auditor
should assess the effectiveness of web application security and, as
appropriate, general controls to determine whether the information
system controls over the application could allow unauthorized access
through the application to other system resources.
2.5.1.C ERP Systems:
ERP systems present additional IS risks. While IS control objectives
contained in the FISCAM, if properly achieved, should address such
risks, it is important for the auditor to properly consider how the
control objectives are achieved in ERP systems. This section provides
some considerations in auditing ERP systems. The auditor should
supplement the FISCAM with audit considerations and techniques that are
specific to the particular ERP system(s) being audited. Although ERP
systems share some similar functionality, the way they are implemented
and the audit techniques (e.g., specific system queries, analysis of
superuser capabilities) applied will vary with the particular vendor.
Factors affecting the overall risk related to ERP systems include the
following:
* ERP systems are highly integrated (e.g., common databases, common
security administration) and cover/include/address a broad range of
entity activities, which leads to increased risks related to several
control areas. For example, an ERP application generally includes a
broader cross-section of users in the entity, increasing the need for
access (particularly least privilege) and segregation of duties
controls. Also, because loss of an ERP system/application can have
devastating consequences to an entity, the entity needs effective
controls over (1) system development/configuration management controls
to provide reasonable assurance that the system will operate as
intended, (2) service continuity/contingency planning to recover the
more comprehensive ERP systems, and (3) access and other general
controls to prevent unauthorized access to entity system resources that
could lead to denial of service. Further, general controls over the ERP
system and supporting databases and operating systems are important to
adequately protect access to the underlying data and processing.
* Because ERP systems are on-line-real-time systems, data validation
controls are critical to reasonably assure that only valid data is
processed by the ERP systems. Controls in ERP systems tend to be
preventive rather than detective, as subsequent detection and
correction of errors may be costly or impossible. Also, fewer controls
may be in place as the data is generally entered and validated once.
* The network architectures for ERP systems are typically more
distributed, resulting in increased access controls and other risks
than for more centralized systems.
* Because security administration is generally centralized and powerful
access is provided to system administrators, access controls over
security administration and segregation of duties controls are
important. In addition, ERP systems have powerful default user IDs that
need to be adequately controlled.
* The broader number of users may also lead to an increase in external
access (wireless or other remote access), from both a broader range of
internal users as well as external users (e.g., vendors, customers),
increasing the number of access points to the entity’s systems.
* ERP systems typically have limited, if any, paper audit trails.
Consequently, controls over audit logs and other general controls are
important for the reliability of data in the ERP systems. Also,
auditing access to ERP systems is typically performed online.
* In many instances, interfaces are developed between the ERP system
and legacy applications. As a result, the adequacy of interface
controls and configuration management controls are important to ensure
that data from legacy systems is reliable, valid, complete, and
properly converted from the legacy application into the ERP system.
* ERP systems may have a program change control module that allows for
direct changes to production code. Therefore, controls related to
segregation of development, test and production facilities and
functions may not be present. Consequently, IS risks related to
configuration management and monitoring are increased, and the entity
should secure and monitor such modules.
ERP systems contain certain controls that are not changeable by the
entity. It is important to understand these controls and how they may
help to achieve the IS control objectives.
In addition, due to the increased risks discussed above, there are a
number of other controls that are of increased significance in ERP
systems, including controls relating to:
* user access to sensitive application capabilities (e.g., pages,
screens, transactions, menus, queries), including related segregation
of duties.
* powerful user roles/profiles, including defaults.
* default user IDs and default passwords.
* default system configurations.
* access to critical tables/databases.
* access to log files.
* the effectiveness of the settings of configurable controls.
* sensitive reports/outputs.
2.5.1.D Interface Controls:
Interface controls are particularly important when applications rely on
input from legacy systems. Such legacy systems are sometimes referred
to as feeder systems. In certain instances, such legacy applications
may not have been designed to fully achieve the objectives of the
application they support. Consequently, the auditor evaluates the
adequacy of interface controls and of application controls related to
such legacy applications to provide reasonable assurance that data from
legacy systems is reliable, valid, complete, and properly converted
from the legacy applications into the applications they support. In
addition, the auditor should assess the effectiveness of application
controls over the legacy applications, if the reliability of input is
relevant to the audit objectives.
2.5.1.E Database Management Systems:
Operational characteristics of various system architectures that
include Database Management Systems (DBMS) software introduce several
potential vulnerabilities to the data/application the DBMS directly
supports and the general controls environment, itself. The degree to
which these potential vulnerabilities increase risk is determined by
the characteristics of the networks and host system(s) involved. One
area of risk exists when the DBMS architecture involves multiple
installations of the DBMS, which may be located on more than one host
system. System and/or application architectures that utilize multiple
DBMS installations are commonly used to support functionally or
geographically distributed operations, high performance requirements,
high availability requirements or some combination of these factors.
When multiple DBMSs exist, the mechanisms that allow them to
communicate with each other need to be implemented and controlled to
prevent unintended data and/or system access. Additionally, modern DBMS
software contains powerful capabilities to access the host’s operating
system and other operating systems and other DBMSs across networks. The
ability to use these capabilities needs to be carefully controlled for
each DBMS installation. Finally, some administrator accounts in DBMS
software provide privileged levels of access to the host’s operating
system. So, users with system administration privileges in DBMS
software may also have significant privileges in host operating systems
and those systems and network devices accessible from the DBMS’s host.
2.5.1.F Network-based Access Control Systems:
Implementations of network-based access control systems (such as LDAPs,
including the Microsoft Active Directory™) introduce the potential for
specific vulnerabilities. Network-based access control systems are
typically hosted on one or more server-class systems. The appropriate
configuration of the operating systems and all factors that can effect
the functioning of the operating systems for these hosts needs to be
carefully controlled. A flaw in operating system-level controls on
these hosts potentially jeopardizes the reliability of the control
functions provided by the network-based access control system and/or
the sensitive access control data contained in that system. Network-
based access control systems are designed to support high performance
and simplify network administration and maintenance. To facilitate
these design considerations, the systems provide flexible methods to
connect to and transfer information with other systems. Due to these
characteristics, it is essential that effective controls be in place to
prevent unintended system functions or data access that could
compromise access controls. The nature of networks and application
architectures that employ network-based access control systems involves
a shared or common reliance on them for critical controls. Therefore, a
compromise of a network-based access control system has the potential
of contributing to the compromise of other systems.
2.5.1.G Workstations:
In modern systems best described as networks of networks, the effect of
workstation controls can be much more significant than control over the
functions nominally identified as associated with a specific
workstation. Workstations can become critical components of a network’s
perimeter as a result of the manner in which they are configured in the
network, the types of sessions they can create with other devices, the
access privileges allowed to workstation users, software running on
those workstations, and controls over both inbound and outbound network
traffic to and from the workstation. An understanding of the
configuration of controls on workstations and network-based controls
over workstations in the context of network perimeter controls is
necessary to assess risk for any network.
2.5.2 Automated Audit Tools:
Various automated audit tools can be used to improve the effectiveness
and efficiency of the IS controls audit. Sometimes referred to as
CAATs, or computer-assisted audit techniques, such tools may be used by
the auditor to gather, or assist in gathering, audit evidence. If the
auditor plans to use automated audit tools, the auditor should
understand:
* when they could be used,
* how they can be used, and,
* the associated risks.
In addition, the auditor should be adequately trained in the
use/operation of these tools and in the interpretation of the results.
Because some tools generate a significant volume of information, the
auditor should understand how to analyze such information.
Also, the auditor should obtain reasonable assurance that the tools and
their use/application produce reliable results and present a reasonably
low risk of disrupting the entity’s systems. Organizations should
develop a process to select, evaluate, and revise software security
tools. The following are some typical steps:
* Research available security tools, listing several in each category.
* Discuss with other members of your audit organization which tools
could be most useful in-house and at sites to be audited. Discuss with
other audit organizations as appropriate.
* Determine the degree of platform-specific security software needed.
* Determine a methodology to evaluate and select software.
* Develop a procedure to train personnel in its use.
* Develop a review process to determine whether the software tool has
produced results commensurate with its cost.
There are many different types of automated audit tools:
* Commercial software, such as Microsoft Excel™, etc., may be used by
the auditor for analyzing data imported from client files, writing
audit programs, etc.
* Generalized audit software may be used by the auditor to query and
extract information from the entity’s information system. For example,
data extraction tools and reporting facilities for access control
software can identify users with excess privileges that circumvent
segregation of duties. IDEA is the generalized software package
available to GAO auditors.
* An embedded audit module is a CAAT in which code prepared by the
auditor is embedded in the client’s software to replicate a specific
aspect of a control procedure, or to record details of certain
transactions in a file accessible only to the auditor.
* An integrated test facility is testing software that is integrated
into the client’s software and enables the auditor’s test data to be
integrated and processed with the client’s live input.
* Using an integrated test facility allows the auditor to be satisfied
that test data are processed in the same way that live data are
processed and to verify that the results are correct. Parallel
simulation is a technique in which actual client data are processed by
a copy of the client’s software that is under separate control of the
auditor and has undergone program code analysis to ensure that the
processing is identical to that of the client’s operational software.
* Program code analysis is the analysis of the client’s program code to
ensure that the instructions given to the computer are the same
instructions that the auditor has previously identified when reviewing
the systems documentation.
* A test data CAAT is a technique in which test data prepared by the
auditor are processed on the current production version of the client’s
software, but separately from the client’s normal input data. Using the
current production software provides evidence that the transactions
were processed in the manner expected.
* Specialized audit software is software designed to perform specific
tasks in specific circumstances, such as comparison of source and
object code, the analysis of unexecuted code, and the generation of
test data.
* Other specialized tools can be used to test IS controls. For example:
- Password crackers can identify the use of vendor-default or easily
guessed passwords.
- Network “sniffers” (software that can intercept and log traffic
passing over a network) can identify the transmission of passwords or
sensitive information in clear text.
- Network scanners, along with standard operating system commands, can
help identify an organization’s network security profile and determine
whether dangerous services are active in components.
- Modem locators (“war dialing” software) can help identify unsecured
dial-in modems.
CAATs can also be used in testing the effectiveness of controls, as a
companion to other controls testing. This would typically involve
making a small selection of transactions and walking them through the
system, or developing an integrated test facility and processing test
transactions through the system. The advantage of using CAATs in
controls testing is that it is possible to test every transaction
(either in a master file or transaction file), to determine whether
there were any control failures.
Any analysis performed using CAATS should be adequately documented. In
addition, a technical review should be performed by audit staff
independent of the preparer to determine that the implementation of
CAATS and the analysis of results is complete and accurate and that any
conclusions are supported by the analysis.
2.5.3 Use of Sampling Techniques:
Controls that leave documented evidence of their existence and
application (such as logs) may be tested by inspecting such evidence.
If sufficient evidence cannot be obtained through walkthroughs in
combination with observation, inquiry, and other tests, the auditor
generally should obtain more evidence by using sampling procedures to
select individual items for inspection. The auditor may use
multipurpose testing to use the same sample to test controls,
compliance, and/or substantive results (such as balances in financial
statements). Multipurpose testing is usually more efficient than
separately designed samples. Alternatively, the auditor may design a
sample to test controls alone. In this case, the auditor generally
should use random attribute sampling. FAM section 450 (Sampling Control
Tests) provides additional information on the use of this sampling
technique, including those that can be applied to performance audits.
[End of chapter]
Chapter 3. Evaluating and Testing General Controls:
3.0 Introduction:
General controls are the policies and procedures that apply to all or a
large segment of an agency’s information systems and help ensure their
proper operation. Examples of primary objectives for general controls
are to safeguard data, protect application programs, and ensure
continued computer operations in case of unexpected interruptions.
General controls are applied at the entitywide, system, and business
process application levels. The effectiveness of general controls at
the entitywide and system levels is a significant factor in determining
the effectiveness of business process controls at the application
level. Without effective general controls at the agency and system
levels, business process controls generally can be rendered ineffective
by circumvention or modification. For example, edits [Footnote 41]
designed to preclude users from entering unreasonably large dollar
amounts in a payment processing system can be an effective application
control. However, this control cannot be relied on if the general
controls permit unauthorized program modifications that might allow
some payments to be exempt from the edit. Consequently, the auditor may
decide that it is efficient to evaluate the effectiveness of general
controls separately from and before evaluating business process
controls.
In planning the evaluation of IS controls, the auditor identifies areas
of audit interest and critical control points. In identifying these
areas, the auditor considers business process applications that are
relevant to the audit objectives. Also, the auditor considers the
network components that are most significant to the effectiveness of IS
controls over the areas of audit interest. In planning the evaluation
of general controls, the auditor considers the most effective and
efficient manner to gather evidence to determine the effectiveness of
general controls over these critical control points. For example, if a
business process application for benefit payments is a key area of
audit interest, the auditor’s testing of general controls is designed,
to the extent possible, to focus on those general controls that most
directly affect the application.
The evaluation of general controls includes the following five general
control areas:
* security management, which provides a framework and continuing cycle
of activity for managing risk, developing security policies, assigning
responsibilities, and monitoring the adequacy of the agency’s computer-
related controls;
* access controls, which limit or detect access to computer resources
(data, programs, equipment, and facilities), thereby protecting them
against unauthorized modification, loss, and disclosure;
* configuration management, which prevents unauthorized changes to
information system resources (for example, software programs and
hardware configurations) and provides reasonable assurance that systems
are configured and operating securely and as intended;
* segregation of duties, which includes policies, procedures, and an
organizational structure to manage who can control key aspects of
computer-related operations; and;
* contingency planning, so that when unexpected events occur, critical
operations continue without disruption or are promptly resumed, and
critical and sensitive data are protected.
For each of these five general control areas, this manual identifies
several critical elements that are essential for establishing adequate
controls. For each critical element, the FISCAM provides a description
of risks, control activities, and suggested audit procedures. The
auditor can use this information to evaluate agency practices. For each
critical element, the auditor should make a summary determination as to
the effectiveness of the agency’s related controls at the entitywide,
system, and application levels. If a critical element is not achieved,
the respective control category is not likely to be achieved. The
auditor should use professional judgment in making such determinations.
To evaluate the effectiveness of general controls, the auditor
identifies control techniques implemented by the agency to address each
of the general controls and determine whether these control techniques,
as designed, are sufficient to achieve the control. If sufficient, the
auditor determines whether they are implemented (placed in operation)
and operating effectively. As discussed later in this section, if the
control techniques are not sufficient or are not implemented as
designed, the auditor should determine the effect on IS controls and
the audit objectives.
As discussed in more detail in Chapter 2, general controls are
applicable at the entitywide, system, and application levels, and so
the auditor should consider general controls at each of these levels.
The control techniques and the related audit tests vary according to
the level to which they are being applied. However, in this manual they
are described at a high level in order to be applicable to many
computer environments; they may require some technical expertise about
the subject to be effectively performed at an agency. More detailed
audit steps generally should be developed by the auditor based on the
specific software and control techniques employed by the agency. Table
2 shows the relationship between the general control areas and the
levels.
Table 2. General Control Categories Applicable at Different Levels of
Audit:
General Controls:
Control Categories: Security Management:
Entitywide/Component Level: Applicable;
System Level, Network: Applicable;
System Level, Operating Systems: Applicable;
System Level, Infrastructure Applications: Applicable;
Business Process Application Level: Applicable.
Control Categories: Access Controls:
Entitywide/Component Level: Applicable;
System Level, Network: Applicable;
System Level, Operating Systems: Applicable;
System Level, Infrastructure Applications: Applicable;
Business Process Application Level: Applicable.
Control Categories: Configuration Management:
Entitywide/Component Level: Applicable;
System Level, Network: Applicable;
System Level, Operating Systems: Applicable;
System Level, Infrastructure Applications: Applicable;
Business Process Application Level: Applicable.
Control Categories: Segregation of Duties:
Entitywide/Component Level: Applicable;
System Level, Network: Applicable;
System Level, Operating Systems: Applicable;
System Level, Infrastructure Applications: Applicable;
Business Process Application Level: Applicable.
Control Categories: Contingency Planning:
Entitywide/Component Level: Applicable;
System Level, Network: Applicable;
System Level, Operating Systems: Applicable;
System Level, Infrastructure Applications: Applicable;
Business Process Application Level: Applicable.
Source: GAO.
[End of table]
The auditor’s evaluation of the effectiveness of IS controls should
include system level controls related to each critical control point.
Assessing the effectiveness of controls over critical control points
should include consideration of all potential ways in which the
critical control point could be accessed. Generally, for each critical
control point, this would include assessing controls related to the
network, operating system, and infrastructure application components.
For example, if a particular router was deemed to be a critical control
point, the auditor would test controls related to the router itself (a
network component), as well as its operating system, and the
infrastructure applications used to manage the router. Access to any of
these could lead to access to the control point.
To facilitate the auditor’s evaluation, tables identifying commonly
used control techniques and related audit procedures are included after
the discussion of each critical element and also in Appendix II.
These tables can be used for both the preliminary evaluation and the
more detailed evaluation and testing of controls. For the preliminary
evaluation, the auditor can use the tables to guide and document
initial inquiries and observations; for the more detailed evaluation
and testing, the auditor can use the suggested procedures in developing
and carrying out a testing plan. Such a plan would include more
extensive inquiries; inspections of facilities, systems, and written
procedures; and tests of key control techniques, which may include
using audit or system software and vulnerability analysis tools. To
help document these evaluations and allow steps to be tailored to
individual audits, electronic versions of the tables are available on
our Web site at [hyperlink, http://www.gao.gov/aac.html].
When evaluating general controls, auditors may want to supplement the
control techniques and audit procedures contained in this document with
other guidance, including:
* National Institute of Standards and Technology (NIST) information
security standards and guidelines;
* international security standards published by the International
Organization for Standardization and the International Electrotechnical
Commission;
* Information Systems Audit and Control Association (ISACA) auditing
standards, guidelines, and procedures; and;
* requirements unique to the environment and agency being audited.
3.1. Security Management (SM):
An entitywide information security management program is the foundation
of a security control structure and a reflection of senior management’s
commitment to addressing security risks. The security management
program should establish a framework and continuous cycle of activity
for assessing risk, developing and implementing effective security
procedures, and monitoring the effectiveness of these procedures.
Overall policies and plans are developed at the entitywide level.
System and application-specific procedures and controls implement the
entitywide policy. Without a well-designed program, security controls
may be inadequate; responsibilities may be unclear, misunderstood, or
improperly implemented; and controls may be inconsistently applied.
Such conditions may lead to insufficient protection of sensitive or
critical resources and disproportionately high expenditures for
controls over low-risk resources. Through FISMA, Congress requires each
federal agency to establish an agencywide information security program
to provide security to the information and information systems that
support the operations and assets of the agency, including those
managed by a contractor or other agency.
Security Program Guidance:
General guidance on planning and managing an agency information
security program is contained in (1) NIST SP 800-12,[Footnote 42] which
provides guidance on security-related management, operational, and
technical controls and (2) our executive guide describing risk
management principles found at leading organizations (discussed in the
next section).[Footnote 43] In response to FISMA, NIST has since
published a series of information security standards and guidelines for
agencies to effectively manage risk to agency operations and agency
assets. Key publications are:
* FIPS Publication 200, Minimum Security Requirements for Federal
Information and Information Systems;
* FIPS Publication 199, Standards for Security Categorization of
Federal Information and Information Systems
* NIST SP 800-53, Recommended Security Controls for Federal Information
Systems.
FIPS Publication 200 provides:
1. a specification for minimum security requirements for federal
information and information systems;
2. a standardized approach to security control selection using the
security categorization standard, FIPS Publication 199; and;
3. links to NIST SP 800-53, containing the security controls needed for
compliance with these minimum security requirements.
In applying the provisions of FIPS 200, agencies first categorize their
systems as required by FIPS 199 (see Table 5), and then typically
select an appropriate set of security controls from NIST SP 800-53 to
satisfy their minimum security requirements. NIST reviews and updates
the controls in NIST SP 800-53 annually to ensure that the controls
represent the current state of practice in safeguards and
countermeasures for information systems.
FIPS 200 and its supporting publication NIST SP 800-53 establish
conditions to enable organizations to be flexible in tailoring their
security control baselines. Agencies, may, for example, apply scoping
guidance taking into consideration the issues related to such things as
the technologies employed by the agency, size and complexity of the
systems, unique circumstances, and risks involved. Agencies may use
compensating controls in lieu of those controls prescribed by NIST SP
800-53. Agencies may also supplement the controls in NIST SP 800-53
with additional controls that may be needed.
In addition, NIST SP 800-100 provides a broad overview of information
security program elements, including capital planning and investment
control, performance measures, and security services, to assist
managers in understanding how to establish and implement an information
security program. This handbook summarizes and augments a number of
existing NIST standards and guidance documents and provides additional
information on related topics.
Other guidance supporting implementation of FIPS 199 and FIPS 200
include:
* NIST SP 800-18, Guide for Developing Security Plans for Federal
Information Systems.
* NIST SP 800-30, Risk Management Guide for Information Technology
Systems ? NIST SP 800-37, Guide for the Security Certification and
Accreditation of Federal Information Systems.
* NIST SP 800-60, Guide for Mapping Types of Information and
Information Systems to Security Categories
These and other publications, directives, and policies that support
compliance with FISMA are available from NIST’s website [hyperlink,
http://csrc.nist.gov].
Security Management Critical Elements:
Assessing an entitywide security management program involves evaluating
the agency’s efforts to perform each of the critical elements shown in
table 3.
Table 3. Critical Elements for Security Management:
Number: SM-1;
Description: Establish a security management program;
Number: SM-2;
Description: Periodically assess and validate risks;
Number: SM-3;
Description: Document security control policies and procedures;
Number: SM-4;
Description: Implement effective security awareness and other security-
related personnel policies;
Number: SM-5;
Description: Monitor the effectiveness of the security program;
Number: SM-6;
Description: Effectively remediate information security weaknesses;
Number: SM-7;
Description: Ensure that activities performed by external third parties
are adequately secure.
Source: GAO.
[End of table]
The following sections discuss each of these critical elements and the
control activities that support their achievement. At the end of each
critical element, a summary table is presented that associates each
activity with techniques that agencies can use to perform the activity,
as well as procedures for auditing the critical elements and control
activities.
Critical Element SM-1: Establish a Security Management Program:
Agencies should have policies, plans, and procedures that clearly
describe the agency’s security management program. FISMA requires
federal agencies to develop, document, and implement an agencywide
information security program to provide security for the information
and information systems that support the operations and assets of the
agency, including those provided or managed by another agency,
contractor, or other source. The security management program should
cover all major systems and facilities and outline the duties of those
who are responsible for overseeing security and those who own, use, or
rely on the agency’s computer resources. As part of this entitywide
program, the entity should have a security management structure in
place at the system and application levels. Thus, in managing a
particular operating system or network device, the agency should have a
clearly assigned structure and responsibilities for the security of the
operating system and device. Similarly, the entity should have a
clearly assigned structure and responsibilities related to particular
business process applications. The security program policies, plans,
and procedures should be kept up-to-date and revised to reflect system
and organizational changes, problems identified during plan
implementation, and security control assessments or audit reports.
SM-1.1. The security management program is adequately documented,
approved, and up-to-date:
The entity’s security management program should be adequately
documented. The nature and extent of the documentation of the program
may vary. For federal entities, at a minimum, the program should
adequately reflect the agency’s consideration of the following eight
elements of an agency wide information security program required by
FISMA.
1. periodic risk assessments;
2. policies and procedures to ensure cost-effective risk reduction and
compliance with applicable standards and guidance and with agency-
determined system configuration requirements;
3. subordinate information security plans for networks, facilities, and
systems;
4. security awareness training for agency employees and contractors;
5. periodic management testing and evaluation that includes testing of
all major systems;
6. a remedial action process to address any deficiencies;
7. security-incident procedures for detecting, reporting, and
responding to incidents; and;
8. continuity of operations plans and procedures for information
systems.
While most of these elements are covered in this section, security
incident procedures are covered in section 3.2 on access controls, and
continuity of operations is covered in section 3.5 on contingency
planning.
The security management program may be documented in the form of a
separate written security management program plan or may consist of
several documents that collectively record the security management
program. The documentation should be supported by subordinate (system
and application level) plans and procedures; related policies should
cover all major systems and facilities and outline the duties of those
responsible for overseeing security (the security management function),
as well as those who own, use, or rely on the agency’s computer
resources. An entitywide plan may describe such things as the overall
security architecture, applicable procedures, and applicable system and
application-level plans. The system-level plans identify the system-
level architecture (for example, network configuration, control points,
etc.), operational policies and procedures, and any business process
(application-level) plans. Similarly, application-level plans should
contain structures, procedures, and controls specific to the
application.
The security management program should be approved by an appropriate
level of management. In some instances, the entity may include the
documentation in a policy document issued by management. In addition,
for federal agencies, FISMA requires that the Director of OMB review
federal agency security management programs at least annually and
approve or disapprove them.
Finally, to be effective, the security program documentation should be
maintained to reflect current conditions. It should be periodically
reviewed and, if appropriate, updated and reissued to reflect changes
in risk due to factors such as changes in entity mission or the types
and configuration of computer resources in use. Revisions to policies
and plans should be reviewed, approved, and communicated to all
employees. Outdated policies and plans not only reflect a lack of
adequate top management concern, but also may be ineffective because
they may not address current risks.
SM-1.2. A security management structure has been established:
Senior management should establish a structure to implement the
security management program throughout the entity. The structure
generally consists of a core of personnel who are designated as
security managers. These personnel play a key role in developing,
communicating, and monitoring compliance with security polices and
reporting on these activities to senior management. The security
management function also serves as a focal point for other personnel
who play a role in evaluating the appropriateness and effectiveness of
computer-related controls on a day-to-day basis. These personnel
include program managers who rely on the agency’s computer systems,
system administrators, and system users.
As an illustration of the different responsibilities of a security
management structure, FISMA establishes responsibilities for certain
agency officials as follows:
* The agency head is responsible for (1) providing risk-based
information security, (2) complying with FISMA requirements and related
NIST standards, (3) ensuring integration of information security
management with agency strategic and operational planning, (4) ensuring
adequacy of trained information security personnel, and (5) ensuring
receipt of annual reporting from the CIO.
* The CIO is to have authority from the agency head to ensure
compliance with FISMA, including responsibility for (1) designating a
senior agency information security official, (2) developing and
maintaining the agency information security program and related
policies and procedures, (3) training and overseeing information
security personnel, and (4) assisting senior agency officials with
their information security responsibilities.
* Senior agency officials are responsible for information security for
operations and assets under their control, including (1) assessing
risk, (2) determining levels of appropriate security, (3) implementing
policies and procedures to cost-effectively reduce risks to an
acceptable level, and (4) periodically testing and evaluating security
controls.
Our survey of leading organizations[Footnote 44] found that a central
management focal point is key to ensuring that the various activities
associated with managing risk are carried out. Such responsibility is
assigned to a central security program office. A central security
program office may be supplemented by individual security program
managers, designated in units within the entity who assist in the
implementation and management of the organization’s security program.
These individual unit security managers should report to or coordinate
with the central security program office.
Responsibilities of the central security program office may include:
* facilitating risk assessments,
* coordinating development and distribution of security policies and
procedures,
* routinely monitoring compliance with these policies,
* promoting security awareness among system users,
* planning and coordinating security-related activities, including
coordination of geographically dispersed security groups,
* ensuring that desktop security plans are integrated with
infrastructure and database security plans,
* providing reports to senior management on policy and control
evaluation results and advice to senior management on security policy
issues, and;
* representing the entity in the security community.
In assessing the effectiveness of the security management structure for
an entitywide, system, or application level, the auditor considers the
security function’s scope of authority, placement, training and
experience, and tools. For example, security management personnel
should:
* have sufficient authority to obtain data needed to monitor compliance
with policies, report results to senior management, and elevate
concerns regarding inappropriate risk management decisions or
practices;
* have sufficient resources to carry out their responsibilities,
including staff and tools (for example, computers, established audit
trails, and specialized security software);
* report to a level of management that maximizes the independence and
objectivity of the security function;
* not be assigned responsibilities that diminish their objectivity and
independence; and;
* have sufficient training and knowledge of control concepts, computer
hardware, software, telecommunications concepts, physical and logical
security, data architecture, database management and data access
methods, pertinent legislation, and administration and organizational
issues.
SM-1.3. Information security responsibilities are clearly assigned:
Security-related responsibilities of offices and individuals throughout
the entity that should be clearly defined include those of (1)
information resource owners and users, (2) information resources
management and data processing personnel, (3) senior management, and
(4) security administrators. Further, responsibilities for individual
employee accountability regarding the use and disclosure of information
resources should be established. Appendix III of OMB Circular A-130
requires that the rules of the system and application “shall clearly
delineate responsibilities and expected behavior of all individuals
with access...and shall be clear about the consequences of behavior not
consistent with the rules.”
Senior management and information resource management have ultimate
responsibility for providing direction and ensuring that information
security responsibilities are clearly assigned and carried out as
intended. Security plans should clearly establish who “owns” the
various computer resources, particularly data files, and what the
responsibilities of ownership are. Ownership of computer resources
should be assigned to persons responsible for their reliability and
integrity. For example, owners of data files and application programs
are generally the managers of the programs supported by these
applications. These managers are primarily responsible for the proper
operation of the program and for accurate reporting of related computer
data. Similarly, owners of computer facilities and equipment are
generally managers who are responsible for the physical protection of
these resources. If a resource has multiple owners, policies should
clearly describe whether and how ownership responsibilities are to be
shared.
Assignment of ownership responsibilities is important because the
managers who own the resources are in the best position to (1)
determine the sensitivity of the resources, (2) analyze the duties and
responsibilities of users, and (3) determine the specific access needs
of these users. Once these factors are determined, the resource owner
can identify persons authorized to access the resource and the extent
of such access. The owners should communicate these authorizations to
the security administrators, who are then responsible for implementing
access controls in accordance with the owners’ authorizations. Section
3.2, Access Controls, further discusses access authorization.
If management and ownership responsibilities are not clearly assigned,
access authorizations may be left to personnel who are not in the best
position to determine users’ access needs. Such personnel are likely to
authorize overly broad access in an attempt to ensure that all users
can access the resources they need. This defeats the purpose of access
controls and, depending on the sensitivity of the resources involved,
can unnecessarily provide opportunities for fraud, sabotage, and
inappropriate disclosures.
SM-1.4. Subordinate security plans are documented, approved, and kept
up-to-date:
Entities should have written security plans at the system and
application levels that cover networks, facilities, and systems or
groups of systems, as appropriate. The plans and related policies
should cover all major systems and facilities and outline the duties of
those who are responsible for overseeing security and those who own,
use, or rely on the entity’s computer resources. In addition, these
system-level plans should provide an overview of the security
requirements for the system and a description of the security controls
in place or planned for meeting those requirements. These plans should
be kept up-to-date and revised to reflect system and organizational
changes, problems identified during plan implementation, and security
control assessments or audit reports. NIST SP 800-18 requires that all
security plans should be reviewed and updated, if appropriate, at least
annually. Further, NIST SP 800-18 and Appendix III of OMB Circular A-
130 provide specific guidance on what should be included in federal
agency system security plans.
FISMA states that “each agency shall develop, document, and
implement...subordinate plans for providing adequate information
security for networks, facilities, and systems or groups of information
systems, as appropriate.” System-level plans should identify the system-
level architecture (for example, network configuration, control points,
etc.), operational policies and procedures, and any application-level
plans. Application plans should contain similar elements such as
procedures and controls specific to the application.
System security plans should be clearly documented and, according to
Appendix III of OMB Circular A-130, cover each general support system
and each major application. The circular further specifies the topics
to include in the plans. Topic names will differ depending on whether
the plan is for a general support system or a major application, but
the subject matter will be similar. The required topics are shown in
table 4.
Table 4. Security Controls to Include in System Security Plans:
General support system: rules of the system[A];
Major application: application rules[A];
General support system: training;
Major application: specialized training;
General support system: personnel controls;
Major application: personnel security;
General support system: incident-response capability;
Major application: NA;
General support system: continuity of support;
Major application: contingency planning;
General support system: technical security;
Major application: technical controls;
General support system: system interconnection;
Major application: information sharing;
General support system: NA;
Major application: public access controls.
Source: Appendix III of OMB Circular A-130.
[A] These include rules delineating responsibilities and expected
behaviors of staff.
Note: In this manual, access controls are addressed in section 3.2 and
contingency planning in section 3.5.
[End of table]
To help ensure that the system security plan is complete and supported
by the agency as a whole, senior management should obtain agreement
from all affected parties to establish policies for a security program.
Such agreements will also help ensure that policies and procedures for
security developed at lower levels within the agency are consistent
with overall organizational policies and procedures. In accordance with
Appendix III of OMB Circular A-130, final responsibility for
authorization of a system to process information should be granted by a
management official. Generally, the manager whose program operations
and assets are at risk is the most appropriate management official.
However, any disagreements between program managers and security
specialists as to the adequacy of policies and controls should be
resolved by senior management.
Like the overall security policies and plans, the subordinate security
policies and plans should be maintained to reflect current conditions.
As described in SM-1.1, they should be periodically reviewed and
updated to reflect changes in risk and revisions should be reviewed,
approved, and communicated to employees. Outdated policies and plans
may be ineffective because they may not address current risks.
SM-1.5. An inventory of systems is developed, documented, and kept up-
to-date:
To implement an effective security program, entities need to maintain a
complete, accurate, and up-to-date inventory of their systems. Without
one, the entity cannot effectively manage IS controls across the
entity. For example, effective configuration management requires the
entity to know what systems they have and whether the systems are
configured as intended. Furthermore, the inventory is necessary for
effective monitoring, testing, and evaluation of IS controls, and to
support information technology planning, budgeting, acquisition, and
management.
FISMA requires that each agency develop, maintain, and annually update
an inventory of major information systems operated by the agency or
under its control. OMB Circular A-130 defines a major information
system as a system that requires special management attention because
of its importance to an agency mission; its high development,
operating, or maintenance costs; or its significant role in the
administration of agency programs, finances, property, or other
resources. The inventory must include identification of the interfaces
between the agency systems and all other systems or networks, including
interfaces not controlled by the agency. The inventory is needed to
effectively track the agency systems for annual testing and evaluation
and contingency planning.
Control Techniques and Suggested Audit Procedures for Critical Element
SM-1:
Table 5 presents control activities for critical element SM-1,
techniques that entities may use to perform the activity and procedures
for auditing the critical element and control activities.
SM-1 Related NIST SP-800-53 Controls:
See the first control for each family (e.g., AC-1, AT-1):
PL-2 System Security Plan;
PL-3 System Security Plan Update;
PL-6 Security-Related Activity Planning;
SA-2 Allocation of Resources.
Table 5. Control Techniques and Suggested Audit Procedures for Critical
Element SM-1: Establish a security management program:
Control activities:
SM-1.1. The security management program is adequately documented,
approved, and up-to-date;
Control techniques:
SM-1.1.1. An agency/entitywide security management program has been
developed, documented, and implemented that:
* covers all major facilities and operations,
* has been approved by senior management and key affected parties, and,
* covers the key elements of a security management program:
- periodic risk assessments,
- adequate policies and procedures,
- appropriate subordinate information security plans,
- security awareness training,
- management testing and evaluation,
- a remedial action process,
- security-incident procedures, and,
- continuity of operations.
Audit procedures:
Review documentation supporting the agency/entitywide security
management program and discuss with key information security management
and staff. Determine whether the program:
* adequately covers the key elements of a security management program,
* is adequately documented, and,
* is properly approved.
Determine whether all key elements of the program are implemented.
Consider audit evidence obtained during the course of the audit.
Control activities:
SM-1.1. The security management program is adequately documented,
approved, and up-to-date;
Control techniques:
SM-1.1.2. The agency/entitywide security management program is updated
to reflect current conditions.
Audit procedures:
Based on a review of security management program documentation and
interviews with key information security management and staff,
determine whether the entity has adequate policies and procedures to
identify significant changes in its IT environment that would
necessitate an update to the program, and whether the program is
periodically updated to reflect any changes.
Control activities:
SM-1.2. A security management structure has been established.
Control techniques:
SM-1.2.1. Senior management establishes a security management structure
for the entitywide, system, and applications that has adequate
independence, authority, expertise, and resources.
Audit procedures:
Review security policies and plans, the entity’s organization chart,
and budget documentation. Interview security management staff. Evaluate
the security structure: independence, authority, expertise, and
allocation of resources required to adequately protect the information
systems.
Control activities:
SM-1.2. A security management structure has been established.
Control techniques:
SM-1.2.2. An information systems security manager has been appointed at
an agency/entity level and at appropriate subordinate (i.e., system and
application) levels and given appropriate authority.
Audit procedures:
Review security program documentation detailing security
responsibilities and rules of behavior for security officials, resource
owners, and users at the entitywide, system, and application levels.
Control activities:
SM-1.4. Subordinate security plans are documented, approved, and kept
up-to-date.
Control techniques:
SM-1.4.1. System and application security plans have been documented
and implemented that:
* cover all major facilities and operations,
* have been approved by key affected parties,
* cover appropriate topics (for federal agencies, those prescribed by
OMB Circular A-130; see table 4).
Audit procedures:
Review agency/entity policies and procedures for preparing security
plans. Review the system and application security plans encompassing
key areas of audit interest and critical control points. Determine
whether the plans adequately cover appropriate topics (for federal
agencies, those prescribed by OMB Circular A-130) and are properly
approved. When conducting the audit, determine whether the plans have
been implemented and accurately reflect the conditions noted.
Control activities:
SM-1.4. Subordinate security plans are documented, approved, and kept
up-to-date.
Control techniques:
SM-1.4.2. The subordinate security plans are updated on a regular basis
or whenever there are significant changes to the agency/entity
policies, organization, IT systems, facilities, applications,
weaknesses identified, or other conditions that may affect security.
Audit procedures:
Review relevant security plans and any related documentation indicating
whether they have been reviewed and updated and are current.
Control activities:
SM-1.5. An inventory of systems is developed, documented, and kept up-
to-date.
Control techniques:
SM-1.5.1. A complete, accurate, and up-to-date inventory exists for all
major systems that includes the identification of all system interfaces.
Audit procedures:
Obtain the agency’s/entity’s systems inventory. Discuss with
agency/entity management (1) the methodology and criteria for including
or excluding systems from the inventory and (2) procedures and controls
for ensuring the completeness, accuracy, and currency of the inventory.
Determine whether systems tested during the audit are included in the
inventory. Test the inventory for completeness, accuracy, and currency.
The objective of this step in an IS controls audit being performed as
part of a financial audit or data reliability assessment is generally
limited to understanding management’s process and controls for ensuring
the accuracy of the inventory.
Source: GAO.
[End of table]
Critical Element SM-2. Periodically assess and validate risks:
A comprehensive risk assessment should be the starting point for
developing or modifying an entity’s security policies and security
plans. Such assessments are important because they help make certain
that all threats and vulnerabilities are identified and considered,
that the greatest risks are addressed, and that appropriate decisions
are made regarding which risks to accept and which to mitigate through
security controls. Appropriate risk assessment policies and procedures
should be documented and based on the security categorizations.
FISMA, the Paperwork Reduction Act of 1995, and the Clinger-Cohen Act,
explicitly emphasize a risk-based policy for cost-effective security.
In support of and reinforcing this legislation, OMB Circular A-130,
Appendix III, Security of Federal Automated Information Resources,
requires executive agencies within the federal government to plan for
security; ensure that appropriate officials are assigned security
responsibility; review the security controls in their information
systems; and authorize system processing prior to operations and
periodically thereafter.
Risk assessments should consider threats and vulnerabilities at the
entitywide level, system level, and application levels. For example, at
the entitywide level, risk assessments should consider personnel
policies and procedures, training, and security awareness activities.
At the system level, risks related to connectivity issues (for example,
Internet, dial-up, wireless) and access controls (for example, both
logical and physical) need to be assessed. At the application level,
risk assessments need to consider specific business processes and
highly-integrated enterprise resource planning (ERP) applications
(discussed in Chapter 4).
Risk assessments should consider risks to data confidentiality,
integrity, and availability, and the range of risks that an entity’s
systems and data may be subject to, including those posed by authorized
internal and external users, as well as unauthorized outsiders who may
try to break into the systems. For example, risk assessments should
take into account observed trends in the types and frequency of hacker
activity and threats. Such analyses should also draw on reviews of
system and network configurations, as well as observations and testing
of existing security controls.
Our study of security programs at leading organizations found that the
following were key success factors for risk assessments.
* Organizations had a defined process that allowed an entitywide
understanding of what a risk assessment was and avoided individual
units developing independent definitions.
* Organizations required that risk assessments be performed and
designated a central security group to schedule and facilitate them.
* Risk assessments involved a mix of individuals who have knowledge of
business operations and technical aspects of the organization’s systems
and security controls.
* The business managers were required to provide a final sign-off
indicating agreement with risk-reduction decisions and acceptance of
the residual risk.
* Organizations required that final documentation be forwarded to more
senior officials and to internal auditors so that participants could be
held accountable for their decisions.
* Leading organizations did not attempt to precisely quantify risk.
Although they would have liked to place a dollar value on risks and
precisely quantify the costs and benefits of controls, they felt that
spending time on such an exercise was not worth the trouble. They
believed that few reliable data were available on either the actual
frequency of security incidents or on the full costs of controls and of
damage due to a lack of controls.
Risk assessments are more likely to be effective when performed by
personnel with enough independence to be objective and with enough
expertise (training and experience) to be able to adequately identify
and assess technical and security risks.
Risk assessment and risk management are ongoing efforts. Although a
formal, comprehensive risk assessment is performed periodically, such
as part of a system security plan, risk should be considered whenever
there is a change in an entity’s operations or its use of technology or
in outside influences affecting its operations. Changes to systems,
facilities, or other conditions and identified security vulnerabilities
should be analyzed to determine their impact on risk, and the risk
assessment should be performed or revised as necessary. The risk
assessment and validation and related management approvals should be
documented and maintained on file. Such documentation should include
risk assessments, security test and evaluation results, security plans,
and appropriate management approvals. Further, according to NIST SP 800-
37, systems should be certified and accredited before being placed in
operation and when major system changes occur.
The NIST SP 800-30 risk management guide discusses the development of
an effective risk management program and contains both the definitions
and the practical steps necessary for assessing and mitigating risks
within IT systems.
According to this guide, the principal goal of an entity’s risk
management process should be to protect the entity and its ability to
perform its mission, not only its information technology assets.
According to FISMA, federal agencies must periodically assess the risk
and magnitude of the harm that could result from the unauthorized
access, use, disclosure, disruption, modification, or destruction of
information and information systems that support their operations and
assets. Policies and procedures are based on risk, and the rigor of
management testing and evaluation of information security should also
be based on risk. Also, the Federal Managers’ Financial Integrity Act
of 1982 requires agencies to conduct risk assessments to identify and
prioritize their vulnerabilities to waste, fraud, and abuse; Appendix
III of OMB Circular A-130 requires that agencies consider risk when
determining the need for and selecting computer-related control
techniques. However, the Circular no longer requires formal periodic
risk analyses that attempt to quantify in dollars an annual loss
exposure resulting from unfavorable events.
Pursuant to FISMA, NIST developed standards for security categorization
of federal information and information systems according to a range of
potential impacts (FIPS Pub 199). Table 6 summarizes these NIST
standards using potential impact definitions for each security
objective (confidentiality, integrity, and availability). Federal
agencies should categorize/classify their non-national security systems
according to these impact levels. The security categories are based on
the potential impact on an agency should certain events occur that
jeopardize the information and information systems needed by the agency
to accomplish its assigned mission, protect its assets, fulfill its
legal responsibilities, maintain its day-to-day functions, and protect
individuals. NIST also issued a guide for mapping types of information
and information systems to security categories (NIST SP 800-60).
Security categories are to be used in conjunction with vulnerability
and threat information in assessing the risk to an agency.
Table 6. NIST Impact Definitions for Security Objectives:
Security objective:
Confidentiality: Preserving authorized restrictions on information
access and disclosure, including means for protecting personal privacy
and proprietary information. {44 U.S.C., Sec 3542};
Potential impact, Low:
The unauthorized disclosure of information could be expected to have a
limited adverse effect on organizational operations, organizational
assets, or individuals.
Potential impact, Moderate:
The unauthorized disclosure of information could be expected to have a
serious adverse effect on organizational operations, organizational
assets, or individuals.
Potential impact, High:
The unauthorized disclosure of information could be expected to have a
severe or catastrophic adverse effect on organizational operations,
organizational assets, or individuals.
Security objective:
Integrity: Guarding against improper information modification or
destruction, and includes ensuring information non-repudiation and
authenticity. {44 U.S.C., Sec 3542}.
Potential impact, Low:
The unauthorized modification or destruction of information could be
expected to have a limited adverse effect on organizational operations,
organizational assets, or individuals.
Potential impact, Moderate:
The unauthorized modification or destruction of information could be
expected to have a serious adverse effect on organizational operations,
organizational assets, or individuals.
Potential impact, High:
The unauthorized modification or destruction of information could be
expected to have a severe or catastrophic adverse effect on
organizational operations, organizational assets, or individuals.
Security objective:
Availability: Ensuring timely and reliable access to and use of
information. {44 U.S.C. 3542}
Potential impact, Low:
The disruption of access to or use of information or an information
system could be expected to have a limited adverse effect on
organizational operations, organizational assets, or individuals.
Potential impact, Moderate:
The disruption of access to or use of information or an information
system could be expected to have a serious adverse effect on
organizational operations, organizational assets, or individuals.
Potential impact, High:
The disruption of access or use of information or an information system
could be expected to have a severe or catastrophic adverse effect on
organizational operations, organizational assets, or individuals.
Source: National Institute of Standards and Technology (NIST), FIPS
Publication 199, page 6.
[End of table]
One area that merits additional emphasis is the appropriate
consideration of risks associated with sensitive privacy information.
In addition to an appropriate consideration of related risk, specific
controls are discussed at SM-5 and AC-4.2.
In addition to FISMA, federal agencies are subject to privacy laws
aimed at preventing the misuse of personally identifiable
information.[Footnote 45] The Privacy Act of 1974 and the privacy
provisions of the E-Government Act of 2002 contain the major
requirements for the protection of personal privacy by federal
agencies. The Privacy Act places limitations on agencies’ collection,
disclosure, and use of personal information maintained in systems of
records[Footnote 46] and requires that when agencies establish or make
changes to a system of records; they must notify the public by a
“system-of-records notice.”[Footnote 47] The E-Government Act of 2002
strives to enhance protection for personal information in government
information systems or information collections by requiring that
agencies conduct privacy impact assessments. These privacy impact
assessments include an analysis of how personal information is
collected, stored, shared, and managed in a federal system. According
to OMB guidance, these privacy impact assessments must analyze and
describe how the information will be secured including administrative
and technological controls and should be current.[Footnote 48]
As discussed in NIST SP 800-60[Footnote 49], in establishing
confidentiality impact levels for each information type, responsible
parties must consider the consequences of unauthorized disclosure of
privacy information (with respect to violations of Federal policy
and/or law). The impact of privacy violations will depend in part on
the penalties associated with violation of the relevant statutes and
policies. Further, it says that, in most cases, the impact on
confidentiality for privacy information will be in the moderate range.
SM-2 Related NIST SP-800-53 Controls:
CA-4 Security Certification;
CA-6 Security Accreditation;
RA-2 Security Categorization;
RA-3 Risk Assessment;
RA-4 Risk Assessment Update.
Control Techniques and Suggested Audit Procedures for Critical Element
SM-2:
Table 7 Control Techniques and Suggested Audit Procedures for Critical
Element SM-2: Periodically assess and validate risks:
Control activities:
SM-2.1. Risk assessments and supporting activities are systematically
conducted.
Control techniques:
SM-2.1.1. Appropriate risk assessment policies and procedures are
documented and based on security categorizations.
Audit procedures:
Review risk assessment policies, procedures, and guidance.
Control activities:
SM-2.1. Risk assessments and supporting activities are systematically
conducted.
Control techniques:
SM-2.1.2. Information systems are categorized based on the potential
impact that the loss of confidentiality, integrity, or availability
would have on operations, assets, or individuals.
Audit procedures:
Determine if security risk categorizations are documented and, for
federal entities, if they comply with FISMA, NIST FIPS Pub 199 and SP
800-60.
Control activities:
SM-2.1. Risk assessments and supporting activities are systematically
conducted.
Control techniques:
SM-2.1.3. Risks are reassessed for the entitywide, system, and
application levels on a periodic basis or whenever systems,
applications, facilities, or other conditions change.
Audit procedures:
Obtain the most recent risk assessments encompassing key areas of audit
interest and critical control points. Determine if the risk assessments
are up-to-date, appropriately documented, approved by management, and
supported by sufficient testing. For federal systems, consider
compliance with FISMA, OMB, and NIST requirements/guidance and whether
the technology used is appropriately considered in the risk assessment
and validations. The objective of this step in an IS controls audit
being performed as part of a financial audit or data reliability
assessment is generally limited to understanding management’s risk
assessment process (including related controls), reading the risk
assessments for the key systems relevant to the audit objectives, and
determining whether risks identified by the IS controls audit are
properly considered in the risk assessments.
Control activities:
SM-2.1. Risk assessments and supporting activities are systematically
conducted.
Control techniques:
SM-2.1.4. Risk assessments and validations, and related management
approvals are documented and maintained on file. Such documentation
includes security plans, risk assessments, security test and evaluation
results, and appropriate management approvals.
Audit procedures:
For a selection of risk assessments determine whether required
management approvals are documented and maintained on file.
Control activities:
SM-2.1. Risk assessments and supporting activities are systematically
conducted.
Control techniques:
SM-2.1.5. Changes to systems, facilities, or other conditions and
identified security vulnerabilities are analyzed to determine their
impact on risk and the risk assessment is performed or revised as
necessary based on OMB criteria.
Audit procedures:
Review criteria used for revising risk assessments. For recent changes
that meet the criteria, determine if the risk assessment was redone or
updated.
Control activities:
SM-2.1. Risk assessments and supporting activities are systematically
conducted.
Control techniques:
SM-2.1.6. Federal systems are certified and accredited before being
placed in operation and at least every 3 years, or more frequently if
major system changes occur.
Audit procedures:
For federal systems that are significant to the audit objectives,,
review certification and accreditation documentation and determine
compliance with NIST SP 800-37. The objective of this step in an IS
controls audit being performed as part of a financial audit or data
reliability assessment is generally limited to understanding the
certification and accreditation process (including related controls),
reading the certifications and accreditations for the key systems
relevant to the audit objectives, and determining whether the
certification and accreditation documentation for the systems tested is
consistent with the testing results.
Source: GAO.
[End of table]
Critical Element SM-3. Document security control policies and
procedures:
Security control policies and procedures should be documented and
approved by management. They should also appropriately consider risk,
address general and application controls, and ensure that users can be
held accountable for their actions. Control policies and procedures may
be written to be more general at the entitywide level and more specific
at the systems (for example, specific configurations) and application
levels (for example, user access rules for specific applications). For
example, access control policies may be implemented at the entitywide
level through communication of formal written guidance; at the system
level through system-level security software, firewall rules, and
access control lists; and at the application level through very
specific controls built into the application. Also, a formal sanctions
process should be established for personnel who fail to comply with
established IS control policies and procedures.
According to FISMA, each agency information security program must
include policies and procedures that are based on risk assessments that
cost-effectively reduce information security risks to an acceptable
level, and ensure that information security is addressed throughout the
life cycle of each agency information system. NIST provides guidance
pertaining to computer security policy and procedures, described here.
Security policy is senior management’s directives to create a computer
security program, establish its goals, and assign responsibilities. The
term is also used to refer to the specific security rules for
particular systems. Because policy is written at a broad level,
agencies also develop standards, guidelines, and procedures that offer
users, managers, and others a clear approach to implementing policy and
meeting organizational goals. Standards and guidelines specify
technologies and methodologies to be used to secure systems. Standards,
guidelines, and procedures may be promulgated throughout an entity via
handbooks, regulations, or manuals.
Procedures are detailed steps to be followed to accomplish particular
security-related tasks (for example, preparing new user accounts and
assigning the appropriate privileges). Procedures provide more detail
in how to implement the security policies, standards, and guidelines.
Manuals, regulations, handbooks, or similar documents may mix policy,
guidelines, standards, and procedures, since they are closely linked.
In order for manuals and regulations to serve as important tools, they
should clearly distinguish between policy and its implementation. This
can help in promoting flexibility and cost-effectiveness by offering
alternative approaches to implementing policies.
SM-3 Related NIST SP-800-53 Controls:
See the first control for each family (e.g., AC-1, AT-1).
Control Techniques and Suggested Audit Procedures for Critical Element
SM-3:
Table 8. Control Techniques and Suggested Audit Procedures for Critical
Element SM-3: Document security control policies and procedures:
Control activities:
SM-3.1 Security control policies and procedures are documented,
approved by management and implemented.
Control techniques:
SM-3.1.1. Security control policies and procedures at all levels:
* are documented,
* appropriately consider risk,
* address purpose, scope, roles, responsibilities, and compliance,
* ensure that users can be held accountable for their actions,
* appropriately consider general and application controls,
* are approved by management, and,
* are periodically reviewed and updated.
Audit procedures:
Review security policies and procedures at the entitywide level, system
level and application level. Compare the content of the policies and
procedures to NIST guidance (e.g. SP 800-30, SP 800-37,SP 800-100) and
other applicable criteria (e.g. configuration standards).
Source: GAO.
[End of table]
Critical Element SM-4. Implement effective security awareness and other
security-related personnel policies:
Effective security-related personnel policies are critical to effective
security. Ineffective personnel policies can result in employees or
contractors inadvertently or intentionally compromising security. For
example, security may be compromised due to an inadequate awareness or
understanding, inadequate security training, or inadequate screening of
employees.
An ongoing security awareness program should be implemented that
includes first-time training for all new employees, contractors, and
users; periodic refresher training for all employees, contractors and
users; and distribution of security policies detailing rules and
expected behaviors to all affected personnel. Relevant security
awareness requirements and guidance are contained in FISMA, OMB
Circular A-130, and NIST SP 800-50, Building an Information Technology
Security Awareness and Training Program. In addition, employees with
significant security responsibilities should receive specialized
training, as described in NIST SP 800-16, “Information Technology
Security Training Requirements: A Role- and Performance-Based Model”
(April 1998).
According to FISMA, an agencywide information security program must
include security awareness training for not only agency personnel but
also contractors and other users of information systems that support
the agency’s operations and assets. This training must cover (1)
information security risks associated with users’ activities and (2)
users’ responsibilities in complying with agency policies and
procedures designed to reduce these risks. FISMA also includes
requirements for training of personnel with significant
responsibilities for information security. Further, OMB requires
personnel to be trained before they are granted access to systems or
applications. The training is to make sure that personnel are aware of
the system or application’s rules, their responsibilities, and their
expected behavior.
Other security-related personnel policies are also relevant to
effective security. Policies related to personnel actions, such as
hiring, termination, and employee expertise, are important
considerations in securing information systems. If personnel policies
are not adequate, an entity runs the risk of (1) hiring unqualified or
untrustworthy individuals; (2) providing terminated employees
opportunities to sabotage or otherwise impair entity operations or
assets; (3) failing to detect continuing unauthorized employee actions;
(4) lowering employee morale, which may in turn diminish employee
compliance with controls; and (5) allowing staff expertise to decline.
As mentioned, FISMA requires agencies to implement agencywide security
programs that include effective policies and procedures to ensure cost-
effective risk reduction and ensure compliance with FISMA and
applicable OMB (e.g., OMB Circular A-130) and NIST (e.g., SP 800-30)
guidance. This guidance specifically addresses security-related
personnel policies and procedures. For example, NIST SP 800-53
addresses personnel security and controls related to personnel
screening, termination and transfer, and third-party security.
SM-4.1 Ensure that resource owners, system administrators, and users
are aware of security policies:
For a security program to be effective, those expected to comply with
it must be aware of it. Typical means for establishing and maintaining
security awareness include:
* informing users of the importance of the information they handle and
the legal and business reasons for maintaining its integrity and
confidentiality;
* distributing documentation describing security policies, procedures,
and users’ responsibilities, including their expected behavior;
* requiring users to periodically sign a statement acknowledging their
awareness and acceptance of responsibility for security (including the
consequences of security violations) and their responsibilities for
following all organizational policies (including maintaining
confidentiality of passwords and physical security over their assigned
areas); and;
* requiring comprehensive security orientation, training, and periodic
refresher programs to communicate security guidelines to both new and
existing employees and contractors.
The leading organizations studied considered promoting awareness to be
one of the most important factors in the risk management process.
Awareness was considered to be especially important in reducing the
risks of “social engineering,” where users are talked into revealing
passwords or other sensitive information to potential thieves.
Educating users about such risks makes them think twice before
revealing sensitive data and makes them more likely to notice and
report suspicious activity.
Employee awareness is also critical in combating security threats posed
by spam, spyware, and phishing. Spam (unsolicited commercial e-mail)
consumes significant resources and is used as a delivery mechanism for
other types of cyberattacks; spyware (software that monitors user
activity without user knowledge or consent) can capture and release
sensitive data, make unauthorized changes, and decrease system
performance; and phishing (fraudulent messages to obtain personal or
sensitive data) can lead to identity theft, loss of sensitive
information, and reduced trust and use of electronic government
services. The blending of these threats creates additional risks that
cannot be easily mitigated with currently available tools.
SM-4.2. Hiring, transfer, termination, and performance policies address
security:
The security policies and procedures (including relevant personnel and
human resources policies and procedures) that should generally be in
place include the following:
* Hiring procedures include contacting references, performing
background investigations, and ensuring that periodic investigations
are performed as required by law and implementing regulations,
consistent with the sensitivity of the position, per criteria from the
Office of Personnel Management.
* Individuals are screened before they are authorized to have access to
organizational information and information systems.
* For employees and contractors assigned to work with confidential
information, confidentiality, nondisclosure, or security access
agreements specify precautions required and unauthorized disclosure
acts, contractual rights, and obligations during employment and after
termination.
* Periodic job rotations and vacations are used, if appropriate, and
work is temporarily reassigned during vacations.
* A formal sanctions process enforces (including performance ratings
for individual employees) compliance with security policies and
procedures.
* Compensation and recognition are appropriate to promote high morale.
* Where appropriate, termination and transfer procedures include:
- exit interview procedures;
- return of property, such as keys, identification cards, badges, and
passes;
- notification to security management of terminations, and prompt
termination of access to the agency’s resources and facilities
(including passwords);
- the immediate escorting of terminated employees—especially those who
have access to sensitive resources—out of the agency’s facilities; and;
- identification of the period during which nondisclosure requirements
remain in effect.
SM-4.3. Employees have adequate training and expertise:
Management should ensure that employees—including data owners, system
users, data processing personnel, and security management
personnel—have the expertise to carry out their information security
responsibilities. To accomplish this, a security training program
should be developed that includes:
* job descriptions that include the education, experience, and
expertise required;
* periodically reassessing the adequacy of employees’ skills;
* annual training requirements and professional development programs to
help make certain that employees’ skills, especially technical skills,
are adequate and current; and;
* monitoring employee training and professional development
accomplishments.
SM-4 Related NIST SP-800-53 Controls:
AT-2 Security Awareness;
AT-3 Security Training;
AT-4 Security Training Records;
PL-4 Rules of Behavior;
PS-1 Personnel Security Policy and Procedures;
PS-2 Position Categorization;
PS-3 Personnel Screening;
PS-4 Personnel Termination;
PS-5 Personnel Transfer;
PS-6 Access Agreements;
PS-7 Third-Party Personnel Security;
PS-8 Personnel Sanctions.
Control Techniques and Suggested Audit Procedures for Critical Element
SM-4:
Table 9. Control Techniques and Suggested Audit Procedures for Critical
Element SM-4: Implement effective security awareness and other security-
related personnel policies:
Control activities:
SM-4.1. Owners, system administrators, and users are aware of security
policies.
Control techniques:
SM-4.1.1. An ongoing security awareness program has been implemented
that includes security briefings and training that is monitored for all
employees with system access and security responsibilities. Coordinate
with the assessment of the training program in SM-4.3.
Audit procedures:
Review documentation supporting or evaluating the awareness program.
Observe a security briefing. Interview data owners, system
administrators, and system users. Determine what training they have
received and if they are aware of their security-related
responsibilities.
Control activities:
SM-4.1. Owners, system administrators, and users are aware of security
policies.
Control techniques:
SM-4.1.2. Security policies are distributed to all affected personnel,
including system and application rules and expected user behaviors.
Audit procedures:
Review memos, electronic mail files, or other policy distribution
mechanisms. Review personnel files to test whether security awareness
statements are current. If appropriate, call selected users, identify
yourself as security or network staff, and attempt to talk them into
revealing their password.
Control activities:
SM-4.2. Hiring, transfer, termination, and performance policies address
security.
Control techniques:
SM-4.2.1. For prospective employees, references are contacted and
background checks performed. Individuals are screened before they are
given authorization to access organizational information and
information systems.
Audit procedures:
Review hiring policies. For a selection of recent hires, inspect
personnel records and determine whether references have been contacted
and background checks have been performed.
Control activities:
SM-4.2. Hiring, transfer, termination, and performance policies address
security.
Control techniques:
SM-4.2.2. Periodic reinvestigations are performed as required by law,
and implementing regulations [at least once every 5 years], consistent
with the sensitivity of the position per criteria from the Office of
Personnel Management (OPM).
Audit procedures:
Review applicable laws, regulations and reinvestigation policies (e.g.
5CFR 731.106(a); OPM/Agency policy, regulations and guidance; FIPS 201
& NIST SP 800-73, 800-76, 800-78; and, any criteria established for the
risk designation of the assigned position.) For a selection of
sensitive positions, inspect personnel records and determine whether
background reinvestigations have been performed as required.
Control activities:
SM-4.2. Hiring, transfer, termination, and performance policies address
security.
Control techniques:
SM-4.2.3. Nondisclosure or security access agreements are required for
employees and contractors assigned to work with confidential
information.
Audit procedures:
Review policies on confidentiality or security agreements. For a
selection of such users, determine whether confidentiality or security
agreements are on file.
Control activities:
SM-4.2. Hiring, transfer, termination, and performance policies address
security.
Control techniques:
SM-4.2.4. When appropriate, regularly scheduled vacations exceeding
several days are required, and the individual’s work is temporarily
reassigned.
Audit procedures:
Review vacation policies. Inspect personnel records to identify
individuals who have not taken vacation or sick leave in the past year.
Determine who performed employee’s work during vacations.
Control activities:
SM-4.2. Hiring, transfer, termination, and performance policies address
security.
Control techniques:
SM-4.2.5. A formal sanctions process is employed for personnel failing
to comply with security policy and procedures.
Audit procedures:
Review the sanctions process. Determine how compliance with security
policies is monitored and how sanctions were administered.
Control activities:
SM-4.2. Hiring, transfer, termination, and performance policies address
security.
Control techniques:
SM-4.2.6. Where appropriate, termination and transfer procedures
include:
* exit interview procedures;
* return of property, keys, identification cards, passes, etc.;
* notification to security management of terminations and prompt
revocation of IDs and passwords;
* immediate escort of terminated employees out of the agency’s
facilities; and;
* identification of the period during which nondisclosure requirements
remain in effect.
Audit procedures:
Review pertinent policies and procedures. For a selection of terminated
or transferred employees, examine documentation showing compliance with
policies. Compare a system-generated list of users to a list of active
employees obtained from personnel to determine whether IDs and
passwords for terminated employees still exist.
Control activities:
SM-4.3. Employees have adequate training and expertise.
Control techniques:
SM-4.3.1. Skill needs are accurately identified and included in job
descriptions, and employees meet these requirements.
Audit procedures:
Review job descriptions for security management personnel and for a
selection of other personnel. For a selection of employees, compare
personnel records on education and experience with job descriptions.
Control activities:
SM-4.3. Employees have adequate training and expertise.
Control techniques:
SM-4.3.2. A security training program has been developed and includes
first-time security awareness training entitywide for all new
employees, contractors, and users before they are authorized to access
the system, and periodic refresher training thereafter; technical
training for personnel with significant system roles and
responsibilities before they are authorized access to the system; and
periodic refresher training thereafter; and documented entitywide
security training records that are monitored for all employees who have
system access and security responsibilities.
Audit procedures:
Review training program documentation. See NIST SP 800-16 and 800-50
for guidance. Coordinate with the assessment of security awareness in
SM-4.1.
Control activities:
SM-4.3. Employees have adequate training and expertise.
Control techniques:
SM-4.3.3. Employee training and professional development are documented
and monitored.
Audit procedures:
Review training records and related documentation showing whether such
records are monitored and whether employees are receiving the
appropriate training.
Source: GAO.
[End of table]
Critical Element SM-5. Monitor the effectiveness of the security
program:
An important element of risk management is ensuring that policies and
controls intended to reduce risk are effective on an ongoing basis.
Effective monitoring involves the entity performing tests of IS
controls to evaluate or determine whether they are appropriately
designed and operating effectively to achieve the entity’s control
objectives. Senior management’s awareness, support, and involvement are
essential in establishing the control environment needed to promote
compliance with the agency’s/entity’s information security program.
However, because security is not an end in itself, senior managers
should balance the emphasis on security with the larger objective of
achieving the agency’s/entity’s mission. To do this effectively, top
management should understand the agency’s/entity’s security risks and
actively support and monitor the effectiveness of its security
policies. If senior management does not monitor the security program,
it is unlikely that others in the organization will be committed to
properly implementing it. Monitoring is one of GAO’s five internal
control standards.[Footnote 50]
Over time, policies and procedures may become inadequate because of
changes in threats, changes in operations or deterioration in the
degree of compliance. Periodic assessments are an important means of
identifying areas of noncompliance, reminding employees of their
responsibilities, and demonstrating management’s commitment to the
security plan. Such assessments can be performed by entity staff or by
external reviewers engaged by management. Independent audits performed
or arranged by GAO and by agency inspectors general, while an important
check on management performance, should not be viewed as substitutes
for management evaluations of the adequacy of the agency’s security
program.
FISMA requires periodic testing and evaluation of the effectiveness of
information security policies, procedures, and practices. First,
agencies must provide management testing of every system every year,
but the level of rigor may vary depending on the risk. However, OMB in
past FISMA reporting guidance (M-03-19) has noted that annual FISMA
testing does not alter OMB’s policy requiring system reauthorization
(certification and accreditation) at least every 3 years or when
significant changes are made.51 Second, FISMA requires annual
independent evaluations of agency information security programs and
practices to determine their effectiveness. These independent
evaluations must test the effectiveness of control techniques for a
representative subset of systems.
As part of its monitoring function, management should have policies and
procedures for periodically assessing the appropriateness of security
policies and the agency’s compliance with them. At a minimum, such
policies and procedures should address the following areas:
* Frequency of periodic testing. The frequency, nature, and extent of
management’s assessment should appropriately consider information
security risks. Consequently, certain higher-risk systems may be tested
more frequently or more extensively than lower-risk systems. FISMA
requires periodic testing to be performed with a frequency depending on
risk, but no less than annually.
* Depth and breadth of testing. The depth and breadth of testing should
be based on a consideration of potential risk and magnitude of harm,
the relative comprehensiveness of prior reviews, the nature and extent
of tests performed as part of periodic risk and vulnerability
assessments, and the adequacy and successful implementation of
remediation plans.
* Common controls. To facilitate efficient periodic testing, entities
should identify common IS controls that can be tested and the results
used for multiple systems.
* Roles and responsibilities of personnel involved in testing.
Personnel assigned to perform and supervise periodic testing should
possess appropriate technical skills and have appropriate
organizational placement to reasonably assure that tests are properly
performed and results properly reported to entity management. In
addition, personnel should not perform tests of controls for which they
are responsible for implementation or operation.
* Documentation. Tests performed and the results and related analysis
of such tests should be documented to the extent necessary to support
effective supervisory review and independent evaluation.
An integrated testing plan or strategy helps to facilitate effective
and efficient periodic testing. Without such an integrated plan or
strategy, the nature and extent of periodic testing may be inadequate
or testing may be inefficient.
Such tests may include tests performed as part of periodic risk and
vulnerability assessments, continuous monitoring through scanning or
agent-based software tools, or specifically designed tests. Management
should periodically perform vulnerability assessments to help ensure
that entity information resources are adequately protected.
Vulnerability assessments involve analyzing a network to identify
potential vulnerabilities that would allow unauthorized access to
network resources, simulating what might be performed by someone trying
to obtain unauthorized access. Vulnerability assessments typically
consider both unauthorized access by outsiders as well as insiders.
Vulnerability assessments typically include the use of various tools
discussed in Table 10 below, such as scanning tools, password crackers,
and war dialing and war driving tools. Also, vulnerability assessments
may include penetration testing. Vulnerability assessments should be
performed in addition to testing individual access controls and other
control categories.
Since the methods used for unauthorized access vary greatly and are
becoming more sophisticated, the vulnerability assessment techniques
defined here are general in nature and should be supplemented with
techniques and tools specific to the specific environment.
The effectiveness of management’s security testing, including
vulnerability assessments, may affect the auditor’s judgements about
audit risk and consequently, the nature, timing, and extent of audit
testing. Factors to consider in assessing the effectiveness of
management’s testing include:
* the nature of management’s testing (the types of testing management
applied, the strength of the evidence obtained, the experience,
capabilities, and objectivity of the persons performing the testing,
and the quality of documentation of testing),
* the timing of management’s testing (the recentness of testing), and,
* extent of management’s testing (the completeness of testing).
The auditor should review management vulnerability assessments and may
independently perform their own vulnerability assessments to determine
whether management vulnerability assessments are effective.
The type of vulnerability assessments that are conducted by the auditor
affect the scope of the evaluation, methodology used, and the level of
assurance achieved. It is important that the methods chosen by the
auditor provide the least amount of disruption to the entity based on a
cost/risk analysis. Auditors may need to conduct these types of audits
without tools,[Footnote 52] because some audited entities will not want
to accept the risk of an auditor running tools in a “live” environment.
There should be an agreement between the auditor and the audited entity
on the type of testing to be conducted (intrusive or nonintrusive).
Section 2.1.9.E “Communication with Entity Management and Those Charged
With Governance” provides further guidance on communicating the nature
and extent of planned testing with the entity.
Due to the highly technical nature of such testing by the auditor, it
should be performed by persons possessing the necessary technical
skills (e.g., an IT specialist). See Appendix V for additional
information on the Knowledge, Skills, and Abilities needed to perform
IS control audits. Also, section 2.5.2 “Automated Audit Tools” provides
further guidance on the auditor’s use of testing tools. Audit testing
is discussed further in connection with AC-.1.1.
There are several different types of security testing. Some testing
techniques are predominantly manual, requiring an individual to
initiate and conduct the test. Other tests are highly automated and
require less human involvement. Testing may also be conducted from
external connections (for example, from the Internet, dial-up,
wireless), from wide area network connections, or from internal
connections. Regardless of the type of testing, staff that set up and
conduct security testing should have significant security and
networking knowledge, including significant expertise in the following
areas: network security, firewalls, intrusion detection systems,
operating systems, programming and networking protocols (such as
Transmission Control Protocol/Internet Protocol (TCP/IP) – which is a
low-level communication protocol that allows computers to send and
receive data).
Table 10 summarizes types of security testing.
Table 10. Types of Security Testing:
Test type: Network scanning;
What it does:
* Enumerates the network structure and determines the set of active
hosts and associated software;
* Identifies unauthorized hosts connected to a network;
* Identifies open ports;
* Identifies unauthorized services.
Test type: General vulnerability scanning;
What it does:
* Enumerates the network structure and determines the set of active
hosts and associated software;
* Identifies a target set of computers to focus vulnerability analysis;
* Identifies potential vulnerabilities on the target set;
* Verifies that software (e.g., operating systems and major
applications) is up-to-date with security patches and software
versions.
Test type: Penetration testing;
What it does:
* Determines how vulnerable an organization’s network is to penetration
and the level of damage that can be incurred;
* Tests IT staff’s response to perceived security incidents and their
knowledge of and implementation of the organization’s security policy
and system’s security requirements;
* Verifies potential impact of multiple security weaknesses.
Test type: Password cracking;
What it does:
* Verifies that the policy is effective in producing passwords that are
more or less difficult to break;
* Verifies that users select passwords that are compliant with the
organization’s security policy.
Test type: Log reviews;
What it does:
* Verifies that the system is operating according to policy.
Test type: Integrity checkers;
What it does:
* Detects unauthorized file modifications.
Test type: Virus detectors;
What it does:
* Detects and deletes viruses before successful installation on the
system.
Test type: War dialing;
What it does:
* Detects unauthorized modems and prevents unauthorized access to a
protected network.
Test type: War driving;
What it does:
* Detects unauthorized wireless access points and prevents unauthorized
access to a protected network.
Test type: Specialty scanning tools;
What it does:
* Detects security risks related to specific IS control areas (e.g.,
weaknesses in web pages, application code, and databases, network
sniffers[Footnote 53]).
Source: Guideline on Network Security Testing (NIST SP 800-42, October
2003).
[End of table]
Often, several of these testing techniques are used together for a more
comprehensive assessment of the overall network security posture. For
example, penetration testing usually includes network scanning and
vulnerability scanning to identify vulnerable hosts and services that
may be targeted for later penetration. Some vulnerability scanners
incorporate password cracking. None of these tests by themselves will
provide a complete picture of the network or its security posture. NIST
SP 800-42 describes these testing types in detail and summarizes the
strengths and weaknesses of each test.
However, since penetration testing requires extensive planning and
experienced staff to conduct, the auditor typically considers several
factors before deciding to perform this testing. For example,
penetration testing may be a desirable testing option when significant
changes have been made to the entity’s network (e.g., upgrades to
server, routers, switches, network software), there are no recent
penetration tests performed, or results of recent penetration testing
identified significant security weaknesses that management represented
were substantially corrected. Conversely, if recent penetration testing
disclosed few security weaknesses and the scope and level of testing is
determined by the auditor to be sufficient, then the use of other types
of testing may be more appropriate.
Other tools that may be used include specialty scanning tools (for
example, application code, Web, database, SNMP[Footnote ]54), host data
extraction tools, packet analyzers or sniffers (for example, ethereal),
and patch assessment tools. Separate patch assessment tools are more
reliable than vulnerability scanners for this purpose. Also, the
auditor is more likely to check for the presence of integrity checkers
and virus detectors than to use them in an audit. After running any
tests, certain procedures should be followed, including documenting the
test results, informing system owners of the results, and ensuring that
vulnerabilities are patched or mitigated.
When implementing system security plans for federal systems, as
required by FISMA and OMB Circular A-130, management should monitor
their implementation and adjust the plans in accordance with changing
risk factors. Management should:
* develop and document appropriate testing policies and procedures (all
levels),
* test and document security controls related to each major system at
least annually (system level),
* ensure that the frequency and scope of testing is commensurate with
risk (all levels), and,
* employ automated mechanisms to verify the correct operation of
security functions when anomalies are discovered (system and
application level).
In addition to the FISMA provisions in the E-Government Act of 2002,
Section 208 requires that agencies conduct privacy impact assessments.
A privacy impact assessment is an analysis of how information is
handled (1) to ensure handling conforms to applicable legal,
regulatory, and policy requirements regarding privacy; (2) to determine
the risks and effects of collecting, maintaining, and disseminating
information in identifiable form in an electronic information system;
and (3) to examine and evaluate protections and alternative processes
for handling information to mitigate potential privacy risks (OMB
Memorandum M-03-22). OMB combined the FISMA and privacy annual
reporting beginning in fiscal year 2005 (OMB Memorandum M-05-15).
Further, OMB has developed performance measures for federal agency
reporting and requires that agencies provide quarterly performance
metric updates. For example, one such measure requests the number of
systems for which security controls have been tested and evaluated in
the past year. Incomplete reporting on OMB’s performance measures will
be noted in OMB’s public report to Congress and will be a consideration
in OMB’s annual approval or disapproval of the agency’s security
program. NIST SP 800-55 provides additional guidance on performance
measures and compliance metrics to monitor the security process and
periodically report on the state of compliance.
In addition, NIST SP 800-100 provides information on how entities can
develop information security metrics that measure the effectiveness of
their security program, and provide data to be analyzed and used by
program managers and system owners to isolate problems, justify
investment requests, and target funds specifically to the areas in need
of improvement. It describes metric types and discusses development and
implementation approaches.
As mentioned, OMB Circular A-130 requires that federal agencies review
and test the security of their general support systems and major
applications at least once every 3 years—sooner if significant
modifications have occurred or where the risk and magnitude of harm are
high. Although not required, it would be appropriate for an agency to
describe its evaluation program, including the expected type of testing
and frequency of evaluations, in its security plan. (Security plans are
discussed in critical element SM-1.)
OMB also requires that a management official authorize in writing the
use of each general support system and major application. NIST SP 800-
37 refers to this authorization as accreditation. OMD Circular A-130
allows self-reviews of controls for general support systems, but
requires an independent review or audit of major applications. The
authorizations or accreditations are to be provided by the program or
functional managers whose missions are supported by the automated
systems; these represent the managers’ explicit acceptance of risk
based on the results of any security reviews, including those performed
as part of financial statement audits and during related risk
assessments. Additional guidance on accrediting federal automated
systems can be found in NIST SP 800-37, Guide for the Security
Certification and Accreditation of Federal Information Systems.
In addition, the Federal Managers’ Financial Integrity Act of 1982
(FMFIA) and OMB Circular A-123[Footnote 55] require agencies to
annually assess their internal controls, including computer-related
controls, and report any identified material weaknesses to the
President and the Congress. The quality of the FMFIA process is a good
indicator of management’s (1) philosophy and operating style, (2)
methods of assigning authority and responsibility, and (3) control
methods for monitoring and follow-up. Weaknesses identified during
security reviews conducted under OMB Circular A-130 are to be
considered for reporting under FMFIA and OMB Circular A-123,
particularly if the weakness involves no assignment of security
responsibility, an inadequate security plan, or missing management
authorization.
FISMA requires that each agency conduct an annual independent
evaluation to determine the effectiveness of its information security
program and practices. This evaluation must include testing of
information security policies, procedures, and practices of a
representative subset of the agency’s information systems. The head of
each agency must report the evaluation results to OMB, which summarizes
the results in a report to the Congress. GAO must also provide Congress
with its independent assessment of agency information security policies
and practices, including compliance with the annual evaluation and
reporting requirements.
SM-5 Related NIST SP-800-53 Controls:
CA-2 Security Assessments;
CA-7 Continuous Monitoring;
PL-5 Privacy Impact Assessment;
RA-5 Vulnerability Scanning.
Control Techniques and Suggested Audit Procedures for Critical Element
SM-5:
Table 11. Control Techniques and Suggested Audit Procedures for
Critical Element SM-5: Monitor the effectiveness of the security
program:
Control activities:
SM-5.1. The effectiveness of security controls are periodically
assessed.
Control techniques:
SM-5.1.1. Appropriate monitoring and testing policies and procedures
are documented.
Audit procedures:
Review testing policies and procedures. Determine if there is an
overall testing strategy or plan.
Control activities:
SM-5.1. The effectiveness of security controls are periodically
assessed.
Control techniques:
SM-5.1.2. Management routinely conducts vulnerability assessments and
promptly corrects identified control weaknesses.
Audit procedures:
Interview officials who conducted the most recent agency/entity
vulnerability assessment. Review the methodology and tools used, test
plans and results obtained, and corrective action taken. Determine if
testing is performed that complies with OMB and NIST certification and
accreditation and other testing requirements. If appropriate, perform
independent testing with the approval of management. Determine if
identified control weaknesses are promptly corrected.
Control activities:
SM-5.1. The effectiveness of security controls are periodically
assessed.
Control techniques:
SM-5.1.3. Management routinely conducts privacy impact assessments and
promptly corrects identified control weaknesses.
Audit procedures:
Review privacy impact assessments, including the methodology, a sample
of test plan, and related testing results.
Control activities:
SM-5.1. The effectiveness of security controls are periodically
assessed.
Control techniques:
SM-5.1.4. The frequency and scope of security control testing is
commensurate with risk.
Audit procedures:
Determine if control testing is based on risk.
Control activities:
SM-5.1. The effectiveness of security controls are periodically
assessed.
Control techniques:
SM-5.1.5. Performance measures and compliance metrics monitor the
security processes and report on the state of compliance in a timely
manner.
Audit procedures:
Review agency/entity performance measures and compare to OMB’s
performance measures and NIST guidance.
Control activities:
SM-5.1. The effectiveness of security controls are periodically
assessed.
Control techniques:
SM-5.1.6. An annual independent evaluation of the federal agency’s
information security program tests the effectiveness of the security
policies, procedures, and practices.
Audit procedures:
Review the results of these annual evaluations for both FISMA and
privacy reporting and any assessments of their adequacy and
effectiveness.
Control activities:
SM-5.1. The effectiveness of security controls are periodically
assessed.
Control techniques:
SM-5.1.7. Federal agencies report on the results of the annual
independent evaluations to appropriate oversight bodies. Under OMB
guidance, the head of each agency must submit security and privacy
reports to OMB, which consolidates the information for a report to
Congress. The Comptroller General must also periodically evaluate and
report to Congress on the adequacy and effectiveness of agency
information security policies and practices.
Audit procedures:
Evaluate the reporting process and identify any significant
discrepancies between reports at each level and whether the reports
agree with independent audit evaluations. Note that OMB has annual
requirements for FISMA and privacy reporting.
Source: GAO.
[End of table]
Critical Element SM-6. Effectively Remediate Information Security
Weaknesses:
When weaknesses are identified, the related risks should be reassessed,
appropriate corrective or remediation actions taken, and follow-up
monitoring performed to make certain that corrective actions are
effective. Procedures should be established to reasonably assure that
all IS control weaknesses, regardless of how or by whom they are
identified, are included in the entity’s remediation processes. For
each identified IS control weakness, the entity should develop and
implement appropriate action plans and milestones. Action plans and
milestones should be developed based on findings from security control
assessments, security impact analyses, continuous monitoring of
activities, audit reports, and other sources. When considering
appropriate corrective actions to be taken, the entity should, to the
extent possible, consider the potential implications throughout the
entity and design appropriate corrective actions to systemically
address the deficiency. Limiting corrective action only to identified
deficiencies would not necessarily address similar weaknesses in other
systems or applications or result in the most effective and efficient
corrective action.
In addition to developing action plans and modifying written policies
to correct identified problems, entities should test the implementation
of the corrective actions to determine whether they are effective in
addressing the related problems. Management should continue to
periodically review and test such corrective actions to determine if
they remain effective on a continuing basis. This is an important
aspect of managers’ risk management responsibilities.
FISMA specifically requires that agencywide information security
programs include a “process for planning, implementing, evaluating, and
documenting remedial action to address any deficiencies in the
information security policies, procedures, and practices of the
agency.” Further, agencies must report on the adequacy and
effectiveness of the information security program and practices in
annual reports to OMB, Congress, and GAO and in annual budget and
management plans and reports. The latter include reporting a FISMA
“significant deficiency” in information security as a material
weakness. Government Performance and Results Act performance plans must
describe time periods and resources needed to effectuate a risk-based
program.
SM-6 Related NIST SP-800-53 Controls:
CA-5 Plan of Action and Milestones.
Control Techniques and Suggested Audit Procedures for Critical Element
SM-6:
Table 12. Control Techniques and Suggested Audit Procedures for
Critical Element SM-6: Effectively remediate information ssecurity
weaknesses:
Control activities:
SM-6.1. Information security weaknesses are effectively remediated.
Control techniques:
SM-6.1.1. Management initiates prompt action to correct deficiencies.
Action plans and milestones are documented.
Audit procedures:
Review recent POA&Ms, FMFIA reports and prior year audit reports and
determine the status of corrective actions. The objective of this
procedure in an IS controls audit being performed as part of a
financial audit or data reliability assessment is generally limited to
understanding management’s POAM process and related controls to ensure
the accuracy of the information in the POA&Ms, determining whether IS
control weaknesses identified by the IS controls audit are included in
the POA&Ms, and, if not, determining the cause.
Control activities:
SM-6.1. Information security weaknesses are effectively remediated.
Control techniques:
SM-6.1.2. Deficiencies are analyzed in relation to the entire
agency/entity, and appropriate corrective actions are applied
entitywide.
Audit procedures:
Evaluate the scope and appropriateness of corrective actions.
Control activities:
SM-6.1. Information security weaknesses are effectively remediated.
Control techniques:
SM-6.1.3. Corrective actions are tested and are monitored after they
have been implemented and monitored on a continuing basis.
Audit procedures:
Determine if implemented corrective actions have been tested and
monitored periodically.
Source: GAO.
[End of table]
Critical Element SM-7. Ensure that activities performed by external
third parties are adequately secure:
Appropriate policies and procedures should be developed, implemented,
and monitored to ensure that the activities performed by external third
parties (for example, service bureaus, contractors, other service
providers such as system development, network management, and security
management) are documented, agreed to, implemented, and monitored for
compliance. These should include provisions for (1) security clearances
(where appropriate and required), (2) background checks, (3) required
expertise, (4) confidentiality/nondisclosure agreements, (5) security
roles and responsibilities, (6) connectivity agreements, (7) individual
accountability (for example, expectations, remedies), (8) audit access
and reporting, (9) termination procedures, and (10) security awareness
training. In addition, checks should be performed to periodically
ensure that the procedures are being correctly applied and consistently
followed, including the security of relevant contractor systems.
Appropriate controls also need to be applied to outsourced software
development.
FISMA information security requirements apply not only to information
systems used or operated by an agency but also to information systems
used or operated by a contractor of an agency or other agency on behalf
of an agency. In addition, the Federal Acquisition Regulation (FAR)
requires that federal agencies prescribe procedures for ensuring that
agency planners on information technology acquisitions comply with the
information technology security requirements of FISMA, OMB’s
implementing policies including Appendix III of OMB Circular A-130, and
guidance and standards from NIST.[Footnote 56] For example, NIST SP 800-
35 Guide to Information Technology Security Services provides guidance
pertaining to the acquisition or outsourcing of dedicated information
system security services such that (1) incident monitoring, analysis,
and response; (2) operation of information system security devices (for
example, firewalls); and (3) key management services are supported by a
risk assessment and approved by the appropriate, designated agency
official. Acquisition or outsourcing of information system services
explicitly addresses government, service provider, and end-user
security roles and responsibilities. Governmental and private entities
face a range of risks from contractors and other users with privileged
access to their systems, applications and data. Contractors that
provide systems and services or other users with privileged access to
agency/entity systems, applications, and data can introduce risks to
their information and systems; for example, contractors often provide
unsupervised remote maintenance and monitoring of agency/entity
systems. Contractor risks to people, processes, and technology are
summarized in table 13.
Table 13. Examples of Agency-Identified Risks to Federal Systems and
Data Resulting from Reliance on Contractors:
Category: People;
Risk description: Unauthorized personnel having physical access to
agency IT resources (including systems, applications, facilities, and
data).
Category: People;
Risk description: Unauthorized personnel having electronic access to
agency IT resources (including systems, applications, and data).
Category: People;
Risk description: Increased use of foreign nationals.
Category: People;
Risk description: Contractor or privileged users of federal data and
systems who may not receive appropriate, periodic background
investigations.
Category: People;
Risk description: Inadequate segregation of duties (for example,
software developer is the same individual who puts the software into
production).
Category: Processes;
Risk description: Failure by contractor or privileged users of federal
data and systems to follow agency IT security requirements.
Category: Processes;
Risk description: Possible disclosure of agency-sensitive information
to unauthorized individuals or entities.
Category: Processes;
Risk description: Lack of effective compliance monitoring of
contractors performing work off-site or privileged users of federal
data and systems.
Category: Processes;
Risk description: Contractor or privileged users of federal data and
systems may have ineffective patch management processes.
Category: Technology;
Risk description: Incorporation of unauthorized features in customized
application software. For example, a third-party software developer has
the potential to incorporate “back doors,” spyware, or malicious code
into customized application software that could expose agency IT
resources to unauthorized loss, damage, modification, or disclosure of
data.
Category: Technology;
Risk description: Encryption technology may not meet federal standards.
Category: Technology;
Risk description: Intentional or unintentional introduction of viruses
and worms.
Source: Improving Oversight of Access to Federal Systems and Data by
Contractors Can Reduce Risk (GAO-05-362, April 2005).
Note: The various risks identified could represent multiple risks
(i.e., risks in one or more of the identified categories of people,
processes, and technology).
[End of table]
In addition to the risks identified in the table, there are specific
risks from contractor software development activities and off-site
operations. These risks include a poor patch management process that
could impact entity operations (for example, entity Web sites), a
hosting infrastructure that may not separate customer and company data,
and inadequate oversight at an off-site facility.
SM-7 Related NIST SP-800-53 Controls:
AC-20 Use of External Information Systems;
MA-4 Remote Maintenance;
PS-7 Third-Party Personnel Security;
SA-9 External Information System Services.
Control Techniques and Suggested Audit Procedures for Critical Element
SM-7:
Table 14. Control Techniques and Suggested Audit Procedures for
Critical Element SM-7: Ensure that activities performed by external
third parties are adequately secure:
Control activities:
SM-7.1. External third party activities are secure, documented, and
monitored.
Control techniques:
SM-7.1. External third party activities are secure, documented, and
monitored. SM-7.1.1. Appropriate policies and procedures concerning
activities of external third parties (for example, service bureaus,
contractors, other service providers such as system development,
network management, security management) are documented, agreed to,
implemented, and monitored for compliance and include provisions for:
* clearances,
* background checks,
* required expertise,
* confidentiality agreements,
* security roles and responsibilities,
* connectivity agreements,
* expectations,
* remedies,
* audit access/audit reporting,
* termination procedures, and,
* security awareness training.
Audit procedures:
Review policies and procedures pertaining to external third parties for
the entitywide, system, and application levels. Identify use of
external third parties and review activities including compliance with
FISMA, and applicable policies and procedures. See NIST SP 800-35 for
guidance on IT security services. Determine how security risks are
assessed and managed for systems operated by a third party. Determine
whether external third party services that relate to the technology are
adequately controlled. Coordinate assessment of security awareness
training with SM-4.
Control activities:
SM-7.1. External third party activities are secure, documented, and
monitored.
Control techniques:
SM-7.1.2. Security requirements are included in the information system
acquisition contracts based on an assessment of risk.
Audit procedures:
Review security provisions of selected contracts and determine that
requirements are implemented. See FAR requirements for acquisition
plans (48 CFR 7.1, 7.103 (u).
Source: GAO.
[End of table]
3.2. Access Controls (AC):
Access controls limit or detect inappropriate access to computer
resources (data, equipment, and facilities), thereby protecting them
from unauthorized modification, loss, and disclosure. Such controls
include both logical and physical controls. Logical access controls
require users[Footnote 57] to authenticate themselves (through the use
of secret passwords or other identifiers) and limit the files and other
resources that authenticated users can access and the actions that they
can execute. Physical access controls involve restricting physical
access to computer resources and protecting them from intentional or
unintentional loss or impairment. Without adequate access controls,
unauthorized individuals, including outside intruders and former
employees, can surreptitiously read and copy sensitive data and make
undetected changes or deletions for malicious purposes or personal
gain. In addition, authorized users can intentionally or
unintentionally read, add, delete, or modify data or execute changes
that are outside their span of authority.
Access control policies and procedures should be formally developed,
documented, disseminated, and periodically updated. Policies should
address purpose, scope, roles, responsibility, and compliance issues;
procedures should facilitate the implementation of the policy and
associated access controls. NIST SP 800-12 provides guidance on
security policies and procedures. It is fundamental that control
techniques for both logical and physical access controls be risk-based.
Access control policies and procedures and risk assessments are covered
in section 3.1 of the manual.
For access controls to be effective, they should be properly
authorized, implemented, and maintained. First, an entity should
analyze the responsibilities of individual computer users to determine
what type of access (for example, read, modify, delete) users need to
fulfill their responsibilities. Then, specific control techniques, such
as specialized access control software, should be implemented to
restrict access to these authorized functions alone. Such software can
be used to limit a user’s activities associated with specific systems
or files and keep records of individual users’ actions on the computer.
Finally, access authorizations and related controls should be
monitored, maintained, and adjusted on an ongoing basis to accommodate
new and departing employees and changes in users’ responsibilities and
related access needs.
Inadequate access controls diminish the reliability of computerized
data and increase the risk of destruction or inappropriate disclosure
of data. The following examples illustrate the potential consequences
of such vulnerabilities.
* By obtaining direct logical access to data files, an individual could
make unauthorized changes for personal gain or obtain sensitive
information. For example, a person could (1) alter the address of a
payee and thereby direct a disbursement to himself or herself, (2)
alter inventory quantities to conceal a theft of assets, (3) alter
critical data needed to make a strategic policy decision, or (4) obtain
confidential personal, commercial, and governmental information.
* By obtaining logical access to business process applications
[Footnote 58] used to process transactions, an individual could grant
unauthorized access to the application, make unauthorized changes to
these programs, or introduce malicious programs, which, in turn, could
be used to access data files, resulting in situations similar to those
just described, or the processing of unauthorized transactions. For
example, a person could alter a payroll or payables program to
inappropriately generate a check for him/herself.
* By obtaining access to system-level resources, an individual could
circumvent security controls to read, add, delete, or modify critical
or sensitive business information or programs. Further, authorized
users could gain unauthorized privileges to conduct unauthorized
actions or to circumvent edits and other controls built into the
application programs.
* By obtaining physical access to computer facilities and equipment, an
individual could (1) obtain access to terminals or telecommunications
equipment that provide input into the computer, (2) obtain access to
confidential or sensitive information on magnetic or printed media, (3)
substitute unauthorized data or programs, or (4) steal or inflict
malicious damage on computer equipment and software.
The objectives of limiting access are to ensure that:
* outsiders (for example, hackers) cannot gain unauthorized access to
the agency’s systems or data;
* authorized users have only the access needed to perform their duties;
* access to very sensitive resources, such as operating systems and
security software programs, are limited to very few individuals;
* employees/contractors are restricted from performing incompatible
functions or functions beyond their responsibility. (Segregation of
duties is discussed in greater detail in section 3.4.)
If these objectives are met, the risk of inappropriate modification or
disclosure of data can be reduced without interfering with users’
practical needs. However, establishing the appropriate balance between
user needs and security requires a careful analysis of the criticality
and sensitivity of information resources available and the tasks
performed by users. Access controls also apply to alternate work sites
(for example, employee residence or contractor facility).
Implementing adequate access controls involves first determining what
level and type of protection is appropriate for individual resources
based on a risk assessment and on who needs access to these resources.
These tasks should be performed by the resource owners. For example,
program managers should determine how valuable their program data
resources are and what access is appropriate for personnel who must use
an automated system to carry out, assess, and report on program
operations. Similarly, managers in charge of systems development and
modification should determine the sensitivity of hardware and software
resources under their control and the access needs of systems analysts
and programmers, and system administration officials should determine
the access needs of their personnel. Levels of access granted to
information resources should be consistent with FIPS 199 risk levels.
This section defines a set of critical elements that should be
considered when conducting a comprehensive assessment of access
controls. Today’s networks and control environments are highly diverse,
complex, and interconnected. Devices that are interconnected develop
control dependencies (discussed in Chapter 2), directly and indirectly,
on other devices such as routers, firewalls, switches, domain name
servers, Web servers, network management stations, e-mail systems, and
browser software. Audit objectives that are limited to targeted
assessments such as a UNIX or Windows audit may not fully recognize the
control dependencies on these systems.
Unfortunately, there are no simple solutions to controlling logical
access. Each entity decides what combination of technologies to deploy
and to what degree, based on business needs and priorities, risk
management, and other factors. For instance, an entity may decide not
to require users to periodically change passwords for e-mail because
initial entry to the system relies on a two-factor token-based
authentication system. Other entities may rely less on boundary
protection but place more emphasis on audit and monitoring.
Accordingly, the collection of controls used will vary from entity to
entity.
The six critical elements for access controls are described here.
* Boundary Protection. Boundary protection pertains to the protection
of a logical or physical boundary around a set of information resources
and implementing measures to prevent unauthorized information exchange
across the boundary in either direction. Firewall devices represent the
most common boundary protection technology at the network level.
* Identification and authentication. If logical connectivity is
allowed, then the users, processes acting on behalf of users, services,
and specific devices are identified and authenticated by the
information system. For example, users’ identities may be authenticated
through something they know (a traditional password), something they
have (such as a smart card), or something about them that identifies
them uniquely (such as a fingerprint).
* Authorization. If authentication is successful, authorization
determines what users can do; i.e., it grants or restricts user,
service, or device access to various network and computer resources
based on the identity of the user, service, or device.
* Sensitive system resources. Controls over sensitive system resources
are designed to ensure the confidentiality, integrity, and availability
of system data such as passwords and keys during transmission and
storage. Technologies used to control sensitive data include
encryption, certificate management, hashing, checksums, and
steganography.[Footnote 59]
* Audit and monitoring. Audit and monitoring control involves the
collection, review, and analysis of auditable events for indications of
inappropriate or unusual activity. These controls should be used to
routinely assess the effectiveness of information security controls,
perform investigations during and after an attack, and recognize an
ongoing attack.
* Physical security. Physical security controls restrict physical
access or harm to computer resources and protect these resources from
intentional or unintentional loss or impairment. Such controls include
guards, gates, and locks, and also environmental controls such as smoke
detectors, fire alarms and extinguishers, and uninterruptible power
supplies.
Although the primary relevance of these concepts is to access controls,
they are also relevant to other areas, such as security management and
configuration management. For example, configuration management
assurance controls help ensure that network devices are configured and
are operating as intended. This would include verifying operational
patch levels, disabling unnecessary and dangerous services, correcting
poorly configured services, and protecting against viruses and worms.
Also, these concepts are relevant to activities such as periodic self-
assessment programs (covered in Section 3.1, Security Management).
Assessing access controls involves evaluating the agency’s success in
performing each of the critical elements listed in Table 15. When
evaluating control techniques and performing audit procedures for
access controls, the auditor considers access to networks, access to
operating systems, and access to infrastructure applications.[Footnote
60]
Table 15. Critical Elements for Access Control:
Number:AC-1.
Description: Adequately protect information system boundaries.
Number:AC-2.
Description: Implement effective identification and authentication
mechanisms.
Number:AC-3.
Description: Implement effective authorization controls.
Number:AC-4.
Description: Adequately protect sensitive system resources.
Number:AC-5.
Description: Implement an effective audit and monitoring capability.
Number:AC-6.
Description: Establish adequate physical security controls.
Source: GAO.
[End of table]
Critical Element AC-1. Adequately protect information system
boundaries:
Boundary protection controls logical connectivity into and out of
networks and controls connectivity to and from network connected
devices. At the entitywide level, access control policy is developed
and promulgated through procedures, manuals, and other guidance. At the
system level, any connections to the Internet, or to other external and
internal networks or information systems, should occur through
controlled interfaces (for example, proxies, gateways, routers and
switches, firewalls, and concentrators). At the host or device level,
logical boundaries can be controlled through inbound and outbound
filtering provided by access control lists and personal firewalls. At
the application level, logical boundaries to business process
applications may be controlled by access control lists in security
software or within the applications.
Implementing multiple layers of security to protect information system
internal and external boundaries provides Defense-in-Depth(described
earlier in Additional IS Risk Factors). According to security experts,
a best practice for protecting systems against cyber attacks is for
entities to build successive layers of defense mechanisms at strategic
points in their information technology infrastructures. By using the
strategy of Defense-in-Depth, entities can reduce the risk of a
successful cyber attack. For example, multiple firewalls could be
deployed to prevent both outsiders and trusted insiders from gaining
unauthorized access to systems: one firewall could be deployed at the
network’s Internet connection to control access to and from the
Internet, while another firewall could be deployed between wide area
networks and local area networks to limit employees’ access.
In addition to deploying a series of security technologies at multiple
layers, deploying diverse technologies at different layers also
mitigates the risk of successful cyber attacks. If several different
technologies are deployed between the adversary and the targeted
system, the adversary must overcome the unique obstacle presented by
each of the technologies. For example, firewalls and intrusion
detection technologies can be deployed to defend against attacks from
the Internet, and antivirus software can be used to provide integrity
protection for data transmitted over the network. Thus, Defense-in-
Depth can be effectively implemented through multiple security measures
among hosts, local area networks and wide area networks, and the
Internet.
Defense-in-Depth also entails implementing an appropriate network
configuration, which can, in turn, affect the selection and
implementation of cybersecurity technologies. For example, configuring
the agency’s network to channel Internet access through a limited
number of connections improves security by reducing the number of
points that can be attacked from the Internet. At the same time, the
entity can focus technology solutions and attention on protecting and
monitoring the limited number of connections for unauthorized access
attempts. Figure 4 depicts how applying a layered approach to security
through deploying both similar and diverse cybersecurity technologies
at multiple layers can deflect different types of attacks.
Figure 4. Layered Approach to Network Security:
[See PDF for image]
This figure is an illustration of a layered approach to network
security, as follows:
Internet:
Virus:
through firewall;
through Intrusion detection system;
through Wide area network;
through firewall;
through Local area network;
stopped at PC by Antivirus software.
Remote user:
through firewall;
through Intrusion detection system;
through Wide area network;
through firewall;
through Local area network;
through to PC.
Hacker:
through firewall;
stopped by Intrusion detection system.
Source: GAP analysis and Corel Draw.
Note: Excerpt from GAO, Technologies to Secure Federal Systems, GAO-04-
467 (Washington, D.C.: March 2004). AC-1.1.
[End of table]
Appropriately control connectivity to system resources:
Users obtain access to data files and software programs through one or
more access paths through the networks and computer hardware and
software. Accordingly, to implement an appropriate level of security,
it is important that the entity, to the extent possible, identify,
document, and control all access paths. Further, connectivity between
systems should be approved only when appropriate by entity management.
Consideration should be given to the risk and corresponding safeguards
needed to protect sensitive data. NIST SP 800-47 provides guidance on
interconnecting information systems.
Networks should be appropriately configured to adequately protect
access paths between systems and consider the existing technologies.
For standalone computers, identifying access paths may be relatively
simple. However, in a networked environment, careful analysis is needed
to identify all of the system’s entry points and paths to sensitive
files. Networked systems typically consist of multiple personal
computers that are connected to each other and to larger computers,
such as file servers or mainframe processors. Many allow remote access
(for example, dial-up, wireless, Internet) to the information systems
from virtually any remote location. As a result, the entry points to
the system can be numerous. Also, once the system has been entered, the
programs available may provide multiple paths to various data resources
and sensitive applications. Consequently, it is very important that all
access paths be appropriately controlled and protected based on risk.
It is critical that access paths are identified as part of a risk
analysis and documented in an access path diagram or similar network
schematic. Such a diagram or schematic identifies the users of the
system, the type of device from which they can access the system, the
software used to access the system, the resources they may access, the
system on which these resources reside, and the modes of operation and
telecommunications paths. The goal in identifying access paths is to
assist in identifying the points from which system resources could be
accessed and the data stored—points that, therefore, must be
controlled. Specific attention should be given to “backdoor” methods of
accessing data by operators and programmers. As with other aspects of
risk analysis, the access path diagram should be reviewed and updated
whenever any changes are made to the system or to the nature of the
program and program files maintained by the system.
If entry points and access paths are not identified, they may not be
adequately controlled and may be exploited by unauthorized users to
bypass existing controls to gain access to sensitive data, programs, or
password files. Should this happen, managers will have an incomplete
understanding of the risks associated with their systems and,
therefore, may make erroneous risk management decisions.
Connecting to the Internet presents a multitude of vulnerabilities for
an entity due to the Internet’s potential access to billions of people
worldwide. Some Internet users are motivated to try to penetrate
connected systems and have sophisticated software tools as aids, such
as to repeatedly attempt access using different passwords. A variety of
specialized software and hardware is available to limit access by
outside systems or individuals through telecommunications networks.
Examples of network components that can be used to limit access include
secure gateways (firewalls) that restrict access between networks (an
important tool to help reduce the risk associated with the Internet);
teleprocessing monitors, which are programs incorporated into the
computer’s operating system that can be designed to limit access; and
communications port protection devices, such as a security modem that
requires a password from a dial-in terminal before establishing a
network connection. Also available is the smart card, a device about
the size of a credit card that contains a microprocessor, which can be
used to control remote access to a computer with authenticating
information generated by the microprocessor and communicated to the
computer. Encryption is often used to protect the confidentiality of
remote access sessions and is extremely important to protecting
wireless access to information systems.
Information systems may identify and authenticate specific devices
before establishing a connection. Device authentication typically uses
either shared known information (for example, media access control or
transmission control program/Internet protocol addresses) or an
organizational authentication solution to identify and authenticate
devices on local and wide area networks. Thus, it is important for the
auditor to identify the controls over devices that provide this type of
protection.
Emerging threats from the Internet (for example, spam and spyware)
require new and updated protection mechanisms. The entity should employ
spam and spyware protection mechanisms at critical information system
entry points (for example, firewalls, electronic mail servers, remote
access servers) and at workstations, servers, or mobile computing
devices on the network. Consideration should be given to using spam and
software protection products from multiple vendors (for example, using
one vendor for boundary devices and another vendor for workstations) to
provide additional layers of defense. It is also important to centrally
manage spam and software protection mechanisms and to have the system
automatically update these mechanisms.
Depending on how access control techniques and devices are implemented,
they can be used to:
* verify terminal identifications to restrict access through specific
terminals,
* verify IDs and passwords for access to specific applications,
* control access between telecommunications systems and terminals,
* restrict an application’s use of network facilities,
* automatically disconnect at the end of a session,
* provide network activity logs that can be used to monitor network use
and configuration,
* allow authorized users to shut down network components,
* monitor dial-in access to the system by monitoring the source of
calls or by disconnecting and then dialing back users at preauthorized
phone numbers,
* restrict in-house access to communications software,
* control changes to communications software, and,
* restrict and monitor access to telecommunications hardware or
facilities.
As with other access controls, to be effective, remote access controls
should be properly implemented in accordance with authorizations that
have been granted. In addition, tables or lists used to define security
limitations should be protected from unauthorized modification, and in-
house access to communications security software should likewise be
protected from unauthorized access and modification. Dial-in phone
numbers should not be published, and should be changed periodically.
An understanding of the system and network configurations and the
control techniques that have been implemented is necessary to assess
the risks associated with external access through telecommunications
networks and the effectiveness of related controls. This is likely to
require assistance from an auditor with special expertise in
communications-related controls.
Connectivity should only be approved when appropriate to perform
assigned official duties. Significant threats are posed by portable and
mobile devices and personally owned information systems. Portable and
mobile devices (for example, notebook computers, workstations, personal
digital assistants) should not be allowed access to entity networks
without first complying with security policies and procedures. Security
policies and procedures might include activities such as scanning the
devices for malicious code, updating virus protection software,
scanning for critical software updates and patches, conducting primary
operating system (and possibly other resident software) integrity
checks, and disabling unnecessary hardware (for example, wireless).
Security controls include:
* usage restrictions and implementation guidance,
* authorization by appropriate organizational officials, and,
* documentation and monitoring of device access to entity networks.
The entity should also establish strict terms and conditions for the
use of personally-owned information systems. The terms and conditions
should address, at a minimum: (1) the types of applications that can be
accessed from personally-owned information systems; (2) the maximum
FIPS 199 security category of information that can be processed,
stored, and transmitted; (3) how other users of the personally-owned
information system will be prevented from accessing federal
information; (4) the use of virtual private networking and firewall
technologies; (5) the use of and protection against the vulnerabilities
of wireless technologies; (6) the maintenance of adequate physical
security controls; (7) the use of virus and spyware protection
software; and (8) how often the security capabilities of installed
software are to be updated (for example, operating system and other
software security patches, virus definitions, firewall version updates,
spyware definitions).
AC-1.2. Appropriately control network sessions:
It is desirable that information systems prevent further access to the
system by initiating a session lock that remains in effect until the
user reestablishes access using appropriate identification and
authentication procedures. Users should be able to directly initiate
session-lock mechanisms. The information system may also activate
session-lock mechanisms automatically after a specified period of
inactivity defined by the entity. A session lock is not, however, a
substitute for logging out of the information system. When connectivity
is not continual, network connections should automatically disconnect
at the end of a session. OMB Memorandum M-06-16[Footnote 61] requires
that all federal agencies use a “time-out” function for remote access
and mobile devices requiring user re-authentication after 30 minutes
inactivity.
In addition to technical controls, the initial screen viewed by an
individual accessing an agency’s systems through a telecommunications
network should provide a warning banner to discourage unauthorized
users from attempting access, and make it clear that unauthorized
browsing will not be tolerated. For example, an opening warning screen
should state that the system is for authorized users only and that
activity will be monitored. The information system should also display
the agency’s privacy policy before granting access. Previous logon
notification is another control that can identify unauthorized access.
The information system notifies the user on successful logon, of the
date and time of the last logon, the location of the last logon, and
the number of unsuccessful logon attempts since the last successful
logon.
AC-1 Related NIST SP-800-53 Controls:
AC-4 Information Flow Enforcement;
AC-8 System use Notification;
AC-9 Previous Logon Notification;
AC-11 Session Lock;
AC-12 Session Termination;
AC-17 Remote Access;
AC-18 Wireless Access Restrictions;
AC-19 Access Control for Portable and Mobile Devices;
CA-3 Information System Connections;
SC-7 Boundary Protection;
SC-10 Network Disconnect.
Control Techniques and Suggested Audit Procedures for Critical Element
AC-1:
Table 16. Control Techniques and Suggested Audit Procedures for
Critical Element AC-1: Adequately protect information system
boundaries:
Control activity:
AC-1.1. Appropriately control connectivity to system resources.
Control techniques:
AC-1.1.1. Connectivity, including access paths and control technologies
between systems and to internal system resources, is documented,
approved by appropriate entity management, and consistent with risk.
Audit procedures:
Review access paths in network schematics, interface agreements,
systems documentation, and in consultation with IT management and
security personnel identify control points; determine whether the
access paths and related system documentation is up-to-date, properly
approved by management, and consistent with risk assessments.
Control activity:
AC-1.1. Appropriately control connectivity to system resources.
Control techniques:
AC-1.1.2. Networks are appropriately configured to adequately protect
access paths within and between systems, using appropriate
technological controls (e.g. routers, firewalls, etc.).
Audit procedures:
Interview the network administrator; determine how the flow of
information is controlled and how access paths are protected. Identify
key devices, configuration settings, and how they work together.
Perform security testing by attempting to access and browse computer
resources including critical files, security software, and the
operating system. These tests may be performed as (1) an “outsider”
with no information about the agency’s computer systems, (2) an
“outsider” with prior knowledge about the systems—for example, an ex-
insider, and (3) an “insider” with and without specific information
about the agency’s computer systems and with access to the agency’s
facilities. Note: Due to the highly technical nature of such testing,
it should be performed by persons possessing the necessary technical
skills (e.g., an IT specialist). See Appendix V for additional
information on the Knowledge, Skills, and Abilities needed to perform
IS control audits. When performing insider tests, use an ID with no
special privileges to attempt to gain access to computer resources
beyond those available to the account. Also, try to access the agency’s
computer resources using default/generic IDs with easily guessed
passwords. See NIST SP 800-42 for more details. When performing
outsider tests, test the controls over external access to computer
resources, including networks, dial-up, wireless, local area network,
wide area network, and the Internet. See NIST SP 800-42 for more
details.
Control activity:
AC-1.1. Appropriately control connectivity to system resources.
Control techniques:
AC-1.1.3. The information system identifies and authenticates specific
network devices before establishing a connection. (for example, Media
Access Control (MAC) or TCP/IP addresses).
Audit procedures:
When performing outsider tests, test the controls over external access
to computer resources, including networks, dial-up, wireless, local
area network, wide area network, and the Internet. See NIST SP 800-42
for more details.
Control activity:
AC-1.1. Appropriately control connectivity to system resources.
Control techniques:
AC-1.1.4. Remote dial-up access is appropriately controlled and
protected.
Audit procedures:
Interview network administrator and users; determine how remote dial-up
access is controlled and protected (for example, monitor the source of
calls and dial back mechanism); identify all dial-up lines through
automatic dialer software routines and compare with known dial-up
access; discuss discrepancies with management.
Control activity:
AC-1.1. Appropriately control connectivity to system resources.
Control techniques:
AC-1.1.5. Remote Internet access is appropriately controlled and
protected.
Audit procedures:
Interview network administrator and users; determine how connectivity
is controlled and protected. Determine if federal agency policies,
procedures, and practices comply with NIST SP 800-63 guidance on remote
electronic authentication. Supplement with appropriate assessments in
NIST 800-53A.
Control activity:
AC-1.1. Appropriately control connectivity to system resources.
Control techniques:
AC-1.1.6. Remote wireless access is appropriately controlled and
protected.
Audit procedures:
Interview network administrator and users; determine how connectivity
is controlled and protected. Refer to NIST SP 800-97 Establishing
Wireless Robust Security Networks: A guide to IEEE.802.11i for
additional security assessment guidance. Test and validate entity
controls: (1) use a wireless sniffer to capture data (for example,
service set IDs (SSID), (2) if an SSID is obtained, associate the SSID
to the access point, (3) identify what network resources are available,
(4) determine if a security protocol[Footnote 62] such as wired
equivalent privacy (WEP) is implemented, and (5) if a security protocol
is used, employ a program to test the strength of the encryption
algorithm. Test and validate entity controls to identify rogue wireless
access points. Test for rogue wireless access points.
Control activity:
AC-1.1. Appropriately control connectivity to system resources.
Control techniques:
AC-1.1.7. Connectivity is approved only when appropriate to perform
assigned official duties. This includes portable and mobile devices,
and personally-owned information systems.
Audit procedures:
Interview network administrator and users; review justifications for a
sample of connections. Determine if these systems use appropriate
safeguards such as automatic updates for virus protection and up-to-
date patch protection, etc.
Control activity:
AC-1.2. Appropriately control network sessions.
Control techniques:
AC-1.2.1. The information system prevents further access to the system
by initiating a session lock, after a specified period of inactivity
that remains in effect until the user reestablishes access using
identification and authentication procedures.
Audit procedures:
Observe whether the system automatically initiates a session lock
during a period of inactivity, and how the user can directly initiate a
session lock, and then unlock the session.
Control activity:
AC-1.2. Appropriately control network sessions.
Control techniques:
AC-1.2.2 Where connectivity is not continual, network connection
automatically disconnects at the end of a session.
Audit procedures:
Interview network administrator and users; observe whether the control
is implemented.
Control activity:
AC-1.2. Appropriately control network sessions.
Control techniques:
AC-1.2.3. Appropriate warning banners are displayed before logging onto
a system:
* system use notification (for example, U.S. Government system, consent
to monitoring, penalties for unauthorized use, privacy notices);
* previous logon notification (for example, date and time of last logon
and unsuccessful logons).
Audit procedures:
Interview network administrator and users; observe whether the control
is fully implemented and complies with NIST guidance.
Source: GAO.
[End of table]
Critical Element AC-2. Implement effective identification and
authentication mechanisms:
Users (or processes on behalf of users), and devices should be
appropriately identified and authenticated through the implementation
of adequate logical access controls. User authentication establishes
the validity of a user’s claimed identity, typically during access to a
system or application (for example, login). Users can be authenticated
using mechanisms such as requiring them to provide something they have
(such as a smart card); something they alone know (such as a password
or personal identification number); or something that physically
identifies them uniquely (such as a biometric fingerprint or retina
scan). Logical controls should be designed to restrict legitimate users
to the specific systems, programs, and files that they need, and
prevent others, such as hackers, from entering the system at all.
At the entitywide level, information systems accounts need to be
managed to effectively control user accounts and identify and
authenticate users. Account management includes the identification of
account types (i.e., individual, group, system), establishment of
conditions for group membership, and assignment of associated
authorizations. Resource owners should identify authorized users of the
information system and specify access rights. Access to the information
system should be granted based on a valid need to know that is
determined by assigned official duties and should also consider proper
segregation of duties. The entity should require proper identification
for requests to establish information system accounts and approve all
such requests. The entity should also specifically authorize and
monitor the use of guest/anonymous accounts and remove, disable, or
otherwise secure unnecessary accounts. Finally, the entity should
ensure that account managers are notified when information system users
are terminated or transferred and associated accounts are removed,
disabled, or otherwise secured.
AC-2.1. Users are appropriately identified and authenticated:
Identification and authentication is unique to each user (or processes
acting on behalf of users). Account policies (for example, password
policies, account lock out policies) should be formally established and
enforced based on risk. Passwords, tokens, or other devices are used to
identify and authenticate users. Identification is the process of
distinguishing one user from all others, usually through user IDs.
These are important because they are the means by which specific access
privileges are assigned and recognized by the computer. However, the
confidentiality of user IDs is typically not protected. For this
reason, other means of authenticating users—that is, determining
whether individuals are who they say they are—are typically implemented
(for example, passwords, security tokens, etc.). In addition, the
information system should limit the number of concurrent sessions for
any user.
An entity may allow limited user activity without identification and
authentication for publicly available information systems and Web
sites. However, for actions without identification and authentication,
management should consider the risk and only allow such actions to the
extent necessary to accomplish mission objectives.
The most widely used means of authentication is through the use of
passwords. However, passwords are not conclusive identifiers of
specific individuals since they may be guessed, copied, overheard, or
recorded and played back. Typical controls for protecting the
confidentiality of passwords include the following:
* Individual users are uniquely identified rather than having users
within a group share the same ID or password; generic user IDs and
passwords should not be used.
* Passwords are not the same as user IDs.
* Password selection is controlled by the assigned user and not subject
to disclosure.
* Passwords are changed periodically, about every 30 to 90 days. The
more sensitive the data or the function, the more frequently passwords
should be changed.
* Passwords are not displayed when they are entered.
* Passwords contain alphanumeric and special characters and do not use
names or words that can be easily guessed or identified using a
password-cracking mechanism.
* A minimum character length, at least 8 characters, is set for
passwords so that they cannot be easily guessed.
* Use of old passwords (for example, within six generations) is
prohibited.
* Vendor-supplied passwords such as SYSTEM, DEFAULT, USER, DEMO, and
TEST, are replaced immediately on implementation of a new system.
To help ensure that passwords cannot be guessed, attempts to logon to
the system with invalid passwords should be limited. Typically,
potential users are allowed 3 to 7 attempts to log on. This, in
conjunction with the use of pass phrases or other complex passwords,
reduces the risk that an unauthorized user could gain access to a
system by using a computer to try thousands of words or names until
they found a password that provided access. NIST SP 800-63 provides
guidance on password selection and content.
Another technique for reducing the risk of password disclosure is
encrypting the password file. Encryption may be used to transform
passwords into a form readable only by using the appropriate key, held
only by authorized parties. Access to this file should be restricted to
only a few people; encryption further reduces the risk that passwords
could be accessed and read by unauthorized individuals. Passwords
transmitted on the network may likewise be encrypted to prevent
disclosure. Cryptographic controls and related audit procedures are
covered in section AC-4.3.
In addition to passwords, identification devices such as ID cards,
access cards, tokens, and keys may be used. Factors affecting the
effectiveness of such devices include (1) the frequency that possession
by authorized users is checked and (2) users’ understanding that they
should not allow others to use their identification devices and should
report the loss of such devices immediately. Procedures should also be
implemented to handle lost or compromised passwords, access cards, or
tokens. OMB Memorandum M-06-16 requires that federal agencies allow
remote access to personally identifiable information and other
sensitive information only with two-factor authentication where one of
the factors is provided by a device separate from the computer gaining
access. Also see AC-4.2.
A less common means of authentication is based on biometrics, an
automated method of verifying or recognizing the identity of a person
based on physiological or behavioral characteristics. Biometrics
devices include fingerprints, retina patterns, hand geometry, speech
patterns, and keystroke dynamics. Tests of biometric techniques include
reviewing the devices, observing the operations, and taking whatever
other steps may be necessary to evaluate their effectiveness, including
obtaining the assistance of a specialist.
To further increase security, identification and authentication may be
accomplished using any combination of multiple mechanisms such as a
token ID in conjunction with a number, or a biometric reader in
conjunction with a password (also known as multifactor identification).
Management should implement effective procedures to determine
compliance with authentication policies. Whatever technique is used,
the implementation cost versus the risk and potential loss to the
agency’s operations from a breach in security should be taken into
consideration.
Electronic signatures such as digital signatures and public key
infrastructure (PKI) are used to identify the sender of information and
ensure the integrity of critical information received from the sender.
Several technologies such as personal identification numbers, smart
cards, biometrics, or digital signatures (an encrypted set of bits that
identify the user) can be used to create electronic signatures. The
most common electronic signature in use today is the digital signature,
which is unique to each individual and to each message. Digital
signatures are used in conjunction with certificate authorities and
other PKI encryption hardware, software, policies, and people to verify
that the individuals on each end of a communication are who they claim
to be and to authenticate that nothing in the message has been changed.
A digital certificate or shared secret may also be used to authenticate
the identity of a device or devices involved in system communications,
as opposed to the users.
In addition, appropriate session-level identification and
authentication controls should be implemented, such as those related to
name/address resolution service and the authenticity of communication
sessions.
AC-2 Related NIST SP-800-53 Controls:
AC-7 Unsuccessful Login Attempts;
AC-10 Concurrent Session Control;
AC-14 Permitted Actions Without Identification or Authentication;
AU-10 Non-Repudiation;
IA-2 User Identification and Authentication;
IA-3 Device Identification and Authentication;
IA-4 Identifier Management;
IA-5 Authenticator Management;
IA-6 Authenticator Feedback;
SC-17 Public Key Infrastructure Certificates;
SC-20 Secure Name/Address Resolution Service (Authoritative Source);
SC-21 Secure Name/Address Resolution Service (Recursive or Caching
Resolver);
SC-22 Architecture and Provisioning for Names/Address Resolution
Service;
SC-23 Session Authenticity.
Control Techniques and Suggested Audit Procedures for Critical Element
AC-2:
Table 17. Control Techniques and Suggested Audit Procedures for
Critical Element AC-2: Implement effective identification and
authentication mechanisms:
Control activity:
AC-2.1. Users are appropriately identified and authenticated.
Control techniques:
AC-2.1.1. Identification and authentication is unique to each user (or
processes acting on behalf of users), except in specially approved
instances (for example, public Web sites or other publicly available
information systems).
Audit procedures:
Review pertinent policies and procedures and NIST guidance pertaining
to the authentication of user identities; interview users; review
security software authentication parameters.
Control activity:
AC-2.1. Users are appropriately identified and authenticated.
Control techniques:
AC-2.1.2. Account policies (including authentication policies and
lockout policies) are appropriate given the risk, and enforced.
Audit procedures:
Review account policies and determine if they are based on risk and
seem reasonable, based on interviews with system administrator and
users. Determine how they are enforced, and test selected policies.
Control activity:
AC-2.1. Users are appropriately identified and authenticated.
Control techniques:
AC-2.1.3. Effective procedures are implemented to determine compliance
with authentication policies.
Audit procedures:
Review adequacy of procedures for monitoring compliance with
authentication policies; selectively test compliance with key policies.
Control activity:
AC-2.1. Users are appropriately identified and authenticated.
Control techniques:
AC-2.1.4. Selection of authentication methods (for example, passwords,
tokens, biometrics, key cards, PKI certificates, or a combination
therein) are appropriate, based on risk.
Audit procedures:
Determine whether authentication methods used are appropriate, based on
risk.
Control activity:
AC-2.1. Users are appropriately identified and authenticated.
Control techniques:
AC-2.1.5. Authenticators are unique for specific individuals, not
groups;
* are adequately controlled by the assigned user and not subject to
disclosure; and;
* cannot be easily guessed or duplicated.
Additional considerations for passwords are described below.
Audit procedures:
Review pertinent entity policies and procedures; assess procedures for
generating and communicating authenticators to users; interview users;
review related security software parameters. Observe users using
authenticators; attempt to logon without a valid authenticator. Assess
compliance with NIST guidance on authenticator selection, content, and
usage.
Control activity:
AC-2.1. Users are appropriately identified and authenticated.
Control techniques:
AC-2.1.6. Password-based authenticators:
* are not displayed when entered;
* are changed periodically (e.g., every 30 to 90 days);
* contain alphanumeric and special characters;
* are sufficiently long (e.g., at least 8 characters in length);
* have an appropriate minimum life (automatically expire);
* are prohibited from reuse for a specified period of time (e.g., at
least 6 generations); and;
* are not the same as the user ID.
Audit procedures:
Review pertinent entity policies and procedures; assess procedures for
generating and communicating passwords to users; interview users;
review security software password parameters. Observe users keying in
passwords; attempt to logon without a valid password; make repeated
attempts to guess passwords. Assess entity compliance with NIST SP 800-
63, which provides guidance on password selection and content.
Control activity:
AC-2.1. Users are appropriately identified and authenticated.
Control techniques:
AC-2.1.7. Attempts to log on with invalid passwords are limited (e.g.,
3–7 attempts).
Audit procedures:
Examine security parameters for failed log-on attempts; review security
logs to determine whether attempts to gain access are logged and
reviewed by entity security personnel; if appropriate, repeatedly
attempt to logon using invalid passwords.
Control activity:
AC-2.1. Users are appropriately identified and authenticated.
Control techniques:
AC-2.1.8. Use of easily guessed passwords (such as names or words) are
prohibited.
Audit procedures:
Review a system-generated list of current passwords; search password
file using audit software to identify use of easily guessed passwords.
Control activity:
AC-2.1. Users are appropriately identified and authenticated.
Control techniques:
AC-2.1.9. Generic user IDs and passwords are not used.
Audit procedures:
Interview users and security managers; review a list of IDs and
passwords to identify generic IDs and passwords in use.
Control activity:
AC-2.1. Users are appropriately identified and authenticated.
Control techniques:
AC-2.1.10. Vendor-supplied default passwords are replaced during
installation.
Audit procedures:
Attempt to log on using common vendor-supplied passwords; search
password file using audit software.
Control activity:
AC-2.1. Users are appropriately identified and authenticated.
Control techniques:
AC-2.1.11. Passwords embedded in programs are prohibited. (Note: An
embedded password is a password that is included into the source code
of an application or utility. Applications often need to communication
with other applications and systems and this requires an
“authentication” process which is sometimes accomplished through the
use of embedded passwords).
Audit procedures:
Determine if passwords are embedded in programs and if this practice is
explicitly prohibited.
Control activity:
AC-2.1. Users are appropriately identified and authenticated.
Control techniques:
AC-2.1.12. Use of and access to authenticators is controlled (e.g.,
their use is not shared with other users).
Audit procedures:
Interview users. To evaluate biometrics or other technically
sophisticated authentication techniques, the auditor may need to obtain
the assistance of a specialist.
Control activity:
AC-2.1. Users are appropriately identified and authenticated.
Control techniques:
AC-2.1.13. Effective procedures are implemented to handle lost,
compromised, or damaged authenticators (e.g., tokens, PKI certificates,
biometrics, passwords, and key cards).
Audit procedures:
Identify procedures for handling lost or compromised authenticators;
interview users and selectively test compliance with procedures.
Control activity:
AC-2.1. Users are appropriately identified and authenticated.
Control techniques:
AC-2.1.14. Concurrent sessions are appropriately controlled.
Audit procedures:
Review procedures for controlling and auditing concurrent logons from
different workstations.
Control activity:
AC-2.1. Users are appropriately identified and authenticated.
Control techniques:
AC-2.1.15. Where appropriate, digital signatures, PKI, and electronic
signatures are effectively implemented.
Audit procedures:
Determine how nonrepudiation is assured and if PKI and
electronic/digital signatures are effectively implemented.
Control activity:
AC-2.1. Users are appropriately identified and authenticated.
Control techniques:
AC-2.1.16. PKI-based authentication:
* validates certificates by constructing a certification path to an
accepted trust anchor;
* establishes user control of the corresponding private key; and;
* maps the authenticated identity to the user account.
Audit procedures:
Review pertinent entity policies and procedures; assess procedures for
generating and communicating certificates to users; interview users;
review security software certificate parameters; obtain the help of
experts if needed.
Control activity:
AC-2.1. Users are appropriately identified and authenticated.
Control techniques:
AC-2.1.17. Authentication information is obscured (e.g., password is
not displayed).
Audit procedures:
Review procedures for controlling the display of authentication
information.
Control activity:
AC-2.1. Users are appropriately identified and authenticated.
Control techniques:
AC-2.1.18. Appropriate session-level controls are implemented (e.g.,
name/address resolution service, session authenticity).
Audit procedures:
Assess the adequacy of session-level controls.
Source: GAO.
[End of table]
Critical Element AC-3. Implement effective authorization controls:
Once a user is authenticated, authorization[Footnote 63] is used to
allow or prevent actions by that user based on predefined rules.
Authorization includes the principles of legitimate use, least
privilege, and separation of duties (discussed in section 3.4).
Operating systems have some built-in authorization features such as
user rights and privileges, groups of users, and permissions for files
and folders. Network devices, such as routers, may have access control
lists that can be used to authorize users who can access and perform
certain actions on the device.
Access rights and privileges are used to implement security policies
that determine what a user can do after being allowed into the system.
Access rights, also known as permissions, allow the user to look, read,
or write to a certain file or directory. Privileges are a set of access
rights permitted by the access control system. In a Microsoft Windows™
system, rights are what give the user or members of a group the access
needed to perform management tasks or simply to access a system.
Information system access permissions are a Unix term that describe the
kind of access to files a user is granted. A set of permissions is
associated with every file and directory that determines who can read
it, write to it, or execute it. Only the owner of the file (or the
super user[Footnote 64]) can change these permissions. Maintaining
access rights, permissions, and privileges is one of the most important
aspects of administering system security.
AC-3.1. User accounts are appropriately controlled:
In order to adequately control user accounts, an entity should
institute policies and procedures for authorizing logical access to
information resources and document such authorizations. These policies
and procedures should cover user access needed for routine operations,
emergency access, and the sharing and disposition of data with
individuals or groups outside the entity. Further, logical access
controls should enforce segregation of duties.
The computer resource owner should identify the specific user or class
of users authorized to obtain direct access to each resource for which
they are responsible. Access should be limited to individuals with a
valid business purpose (least privilege). Unnecessary accounts
(default, guest accounts) should be removed, disabled, or otherwise
secured. This process can be simplified by developing standard
profiles, which describe access needs for groups of users with similar
duties, such as accounts payable clerks.
The owner should also identify the nature and extent of access to each
resource that is available to each user. This is referred to as the
user’s profile. In general, users may be assigned one or more of the
following types of access to specific computer resources:
* read access—the ability to look at and copy data or a software
program;
* update access—the ability to change data or a software program;
* delete access—the ability to erase or remove data or programs;
* merge access—the ability to combine data from two separate sources;
* execute access—the ability to execute a software program.
Access may be permitted at the file, record, or field level. Files are
composed of records, typically one for each item or transaction.
Individual records are composed of fields that contain specific data
elements relating to each record.
Owners should periodically review access authorization listings and
determine whether they remain appropriate. Access authorizations should
be documented on standard forms and maintained on file. Listings of
authorized users and their specific access needs and any modifications
should be approved by an appropriate senior manager and directly
communicated in writing by the resource owner to the security
management function. A formal process for transmitting these
authorizations, including the use of standardized access request forms,
should be established to reduce the risk of mishandling, alterations,
and misunderstandings.
Security managers should review access authorizations for new or
modified access privileges and discuss any questionable authorizations
with the resource owners (authorizing officials).
Approved authorizations should be maintained on file. Compliance with
access authorizations should be monitored by periodically comparing
authorizations to actual access activity. Access control software
typically provides a means of reporting user access authorizations and
access activity. All changes to security access authorizations should
be automatically logged and periodically reviewed by management
independent of the security function. Unusual activity should then be
investigated.
Broad or special access privileges, such as those associated with
operating system software that allow normal controls to be overridden,
are only appropriate for a small number of users who perform system
maintenance or manage emergency situations. Such special privileges may
be granted on a permanent or temporary basis. However, any such access
should also be approved by a senior security manager, written
justifications should be kept on file, and the use of highly sensitive
files or access privileges should be routinely reviewed by management.
Special access privileges, access to sensitive files, and related audit
procedures are covered in section AC-4.1.
For systems that can be accessed through public telecommunications
lines, some users may be granted dial-up access. This means that these
individuals can use a modem to access and use the system from a remote
location, such as their home or a field office. Because such access can
significantly increase the risk of unauthorized access, it should be
limited and the associated risks weighed against the benefits. To help
manage the risk of dial-up access, justification for such access should
be documented and approved by owners. (See section AC-1 for controls to
help manage the risks of dial-up access, such as dial-back procedures
to preauthorized phone numbers or the use of security modems, tokens,
or smart cards to authenticate a valid user.)
Inactive accounts and accounts for terminated individuals should be
disabled or removed in a timely manner. It is important to notify the
security function immediately when an employee is terminated or, for
some other reason, is no longer authorized access to information
resources.
Notification may be provided by the human resources department or by
others, but policies should exist that clearly assign responsibility
for such notification. Terminated employees who continue to have access
to critical or sensitive resources pose a major threat, as do
individuals who may have left under acrimonious circumstances.
Owners should determine disposition and sharing of data. A mechanism
should be established so that the owners of data files and programs
determine whether and when these resources are to be maintained,
archived, or deleted. Standard disposition forms can be used and
maintained on file to document the users’ approvals. In addition,
resource owners should determine if, with whom, and by what means
information resources can be shared. When files are shared with other
entities, it is important that (1) data owners understand the related
risks and approve such sharing and (2) receiving entities understand
the sensitivity of the data involved and safeguard the data
accordingly. This should require a written agreement before sensitive
information is shared.
Required access to shared file systems should be restricted to the
extent possible (for example, only to particular hosts, and only for
the level of access required). Many scientific agencies, such as the
National Aeronautics and Space Administration (NASA) and the National
Institutes of Health (NIH) use file sharing networks. File sharing
facilitates connections between persons who are looking for certain
types of files. A type of file sharing known as peer-to-peer (P2P)
refers to any software or system allowing individual users of the
Internet to connect directly to each other and trade files. While there
are many appropriate uses of this technology, several studies show that
the vast majority of files traded on P2P networks are copyrighted music
files and pornography. Data also suggest that P2P is a common avenue
for the spread of computer viruses within IT systems. As required by
FISMA, agencies are to use existing NIST standards and guidance to
complete system risk and impact assessments in developing security
plans and authorizing systems for operation. Operational controls
detailing procedures for handling and distributing information and
management controls outlining rules of behavior for users should ensure
that proper controls are in place to prevent and detect improper file
sharing.[Footnote 65]
Emergency and temporary access authorization needs to be controlled.
Occasionally, there will be a need to grant temporary access privileges
to an individual who is not usually authorized access. Such a need may
arise during emergency situations, when an individual is temporarily
assigned duties that require access to critical or sensitive resources,
or for service or maintenance personnel. In addition, contractor
personnel may require temporary access while involved in systems
development or other work. As with normal access authorizations,
temporary access should be approved and documented and the related
documentation maintained on file. Temporary user identifications and
authentication devices, such as passwords, should be designed to
automatically expire after a designated date. Also, management should
periodically review emergency and temporary access accounts to
determine that they are still necessary.
AC-3.2. Processes and services are adequately controlled:
Only authorized processes and services should be permitted in
information systems and they should be limited to what is essential to
effectively perform an agency’s mission and business functions. In an
information system, processes are systematic sequences of operations to
produce a specified result. This includes all functions performed
within a computer such as editing, calculating, summarizing,
categorizing, and updating. Services refer to “customer or product-
related business functions” such as file transfer protocol (FTP),
hypertext transfer protocol (HTTP), and mainframe supervisor calls.
Each system provides a set of services. For example, a computer network
allows its users to send packets to specified destinations; a database
system responds to queries; and a processor performs a number of
different instructions.
Controls related to processes and services include all of the
technological and managerial safeguards established and applied to an
information system to protect hardware, software, and data from
accidental or malicious modification, destruction, or disclosure.
When evaluating an agency’s processes and services, it is important to
consider the following:
* available processes and services should be minimized,
* the functions and purposes of processes and services should be
documented and approved by management, and,
* information available to unauthorized users should be restricted.
Proper control of information system processes and services is critical
to ensuring the confidentiality, integrity, and availability of user
data and, ultimately, the accomplishment of an agency’s mission. Access
control policies and enforcement mechanisms are employed by entities to
control access between users (or processes acting on behalf of users)
and objects (for example, segments, devices, files, records, fields,
processes, programs) in the information system. Access control policies
can be identity-based, role-based, or rule-based. [Footnote 66]
Associated enforcement mechanisms include access control lists, access
control matrices, and cryptography. Where encryption of stored
information is used as an access enforcement mechanism, the
cryptography used should be in compliance with applicable standards.
Configuring systems only for necessary capabilities minimizes processes
and services. First, only required services should be installed.
Second, the number of individuals with access to such services should
be restricted based on the concept of least privilege; this means that
users should have the least amount of privileges (access to services)
necessary to perform their duties. Third, the use of information
services needs to be monitored. Fourth, it is important to maintain
current service versions. According to NIST guidance, the information
system should be periodically reviewed to identify and eliminate
unnecessary services (for example, FTP, HTTP, mainframe supervisor
calls) and protocols that would introduce an unacceptable level of risk
should be disabled.[Footnote 67] The information system that supports
the server functionality should be, as much as possible, dedicated to
that purpose. In addition, the function and purpose of processes and
services should be documented and approved by appropriate entity
officials.
According to NIST SP 800-53, additional process and service controls
should be implemented to:
* prohibit remote activation of collaborative computing mechanisms
(e.g. video and audio devices),
* ensure that lower priority process do not interfere with higher
priority processes, and,
* ensure proprietary information and applications is protected from
processes and systems available to the public.
AC-3 Related NIST SP-800-53 Controls:
AC-2 Account Management;
AC-3 Access Enforcement;
AC-6 Least Privilege;
CM-7 Least Functionality;
SC-6 Resource Priority;
SC-14 Public Access Protections;
SC-15 Collaborative Computing.
Control Techniques and Suggested Audit Procedures for Critical Element
AC-3:
Table 18. Control Techniques and Suggested Audit Procedures for
Critical Element AC-3: Implement effective authorization controls:
Control activity:
AC-3.1. User accounts are appropriately controlled.
Control techniques:
AC-3.1.1. Resource owners have identified authorized users and the
access they are authorized to have.
Audit procedures:
These audit procedures should be coordinated with section 3.4
(segregation of duties) to ensure that users do not have access to
incompatible functions. Review written policies and procedures; for a
selection of users (both application and information security
personnel), review access authorization documentation and applicable
rights and privileges in the information system.
Control activity:
AC-3.1. User accounts are appropriately controlled.
Control techniques:
AC-3.1.2. Security administration personnel set parameters of security
software to provide access as authorized and restrict access that has
not been authorized. This includes access to data files, load and
source code libraries (if applicable), security files, and operating
system files. Standard naming conventions are established and used
effectively as a basis for controlling access to data, and programs.
Audit procedures:
Determine directory names for sensitive or critical files and obtain
security reports of related access rules. Using these reports,
determine who has access to sensitive files and whether the access
matches the level and type of access authorized. Determine whether
standard naming conventions are established and used effectively.
Control activity:
AC-3.1. User accounts are appropriately controlled.
Control techniques:
AC-3.1.3. Security managers review access authorizations and discuss
any questionable authorizations with resource owners.
Audit procedures:
Interview security managers and review documentation provided to them.
Control activity:
AC-3.1. User accounts are appropriately controlled.
Control techniques:
AC-3.1.4. All changes to security access authorizations are
automatically logged and periodically reviewed by management
independent of the security function; unusual activity is investigated.
Audit procedures:
Review a selection of recent changes to security access authorizations
and related logs for evidence of management review and unusual
activity; determine if unusual activity is being/has been investigated.
Control activity:
AC-3.1. User accounts are appropriately controlled.
Control techniques:
AC-3.1.5. Resource owners periodically review access authorizations for
continuing appropriateness.
Audit procedures:
Interview owners and review supporting documentation; determine whether
inappropriate access rights are removed in a timely manner.
Control activity:
AC-3.1. User accounts are appropriately controlled.
Control techniques:
AC-3.1.6. Access is limited to individuals with a valid business
purpose (least privilege).
Audit procedures:
Identify who has access to user accounts and sensitive system resources
and the business purpose for this access.
Control activity:
AC-3.1. User accounts are appropriately controlled.
Control techniques:
AC-3.1.7. Unnecessary accounts (default, guest accounts) are removed,
disabled, or otherwise secured.
Audit procedures:
Verify that unnecessary accounts are removed, disabled, or secured.
Control activity:
AC-3.1. User accounts are appropriately controlled.
Control techniques:
AC-3.1.8. Inactive accounts and accounts for terminated individuals are
disabled or removed in a timely manner.
Audit procedures:
Review security software parameters; review system-generated list of
inactive logon IDs, and determine why access for these users has not
been terminated. Obtain a list of recently terminated employees from
Personnel and, for a selection, determine whether system access was
promptly terminated.
Control activity:
AC-3.1. User accounts are appropriately controlled.
Control techniques:
AC-3.1.9. Access to shared file systems are restricted to the extent
possible (for example, only to particular hosts, and only for the level
of access required).
Audit procedures:
Determine how access to shared file systems is restricted and verify
that it works effectively.
Control activity:
AC-3.1. User accounts are appropriately controlled.
Control techniques:
AC-3.1.10. Emergency or temporary access is appropriately controlled,
including:
* documented and maintained,
* approved by appropriate managers,
* securely communicated to the security function,
* automatically terminated after a predetermined period, and,
* all activity is logged.
Audit procedures:
Review pertinent policies and procedures; compare a selection of both
expired and active temporary and emergency authorizations (obtained
from authorizing parties) with a system-generated list of authorized
users. Determine the appropriateness of access documentation and
approvals and the timeliness of terminating access authorization when
no longer needed.
Control activity:
AC-3.2. Processes and services are adequately controlled.
Control techniques:
AC-3.2.1. Available processes and services are minimized, such as
through:
* installing only required processes and services based on least
functionality,
* restricting the number of individuals with access to such services
based on least privilege,
* monitoring the use of such services, and,
* maintaining current service versions.
Audit procedures:
Review procedures for minimizing processes and services; interview
system administrator; identify what services are installed and
determine if they are required; determine who has access to these
services and if they need them; determine how access to these services
is monitored; and determine if the service versions are kept current.
If appropriate, scan for poorly configured, unnecessary, and dangerous
processes and services.
Control activity:
AC-3.2. Processes and services are adequately controlled.
Control techniques:
AC-3.2.2. The function and purpose of processes and services are
documented and approved by management.
Audit procedures:
Obtain documentation describing the function and purpose of processes
and services, and evidence of management approval.
Control activity:
AC-3.2. Processes and services are adequately controlled.
Control techniques:
AC-3.2.3. Information available to potential unauthorized users is
appropriately restricted.
Audit procedures:
Determine if information about available processes and services is
appropriately restricted.
Control activity:
AC-3.2. Processes and services are adequately controlled.
Control techniques:
AC-3.2.4. The information system prohibits remote activation of
collaborative computing mechanisms (for example, video and audio
conferencing) and provides an explicit indication of use to the local
users (for example, use of camera or microphone).
Audit procedures:
Determine if remote activation of collaborative computing services have
been physically disconnected.
Control activity:
AC-3.2. Processes and services are adequately controlled.
Control techniques:
AC-3.2.5. The information system limits the use of resources by
priority. (Priority protection ensures that a lower-priority process is
not able to interfere with the information system servicing any higher-
priority process.)
Audit procedures:
Interview the systems administrator and review appropriate systems
documentation.
Control activity:
AC-3.2. Processes and services are adequately controlled.
Control techniques:
AC-3.2.6. For publicly available systems, the information system
controls protect the integrity and availability of the information and
applications.
Audit procedures:
Identify controls used to protect the integrity and availability of the
information and applications on such systems and test controls to
ensure their effectiveness.
Source: GAO.
[End of table]
Critical Element AC-4. Adequately protect sensitive system resources:
Certain system resources are more sensitive than others because, if
compromised, serious security breaches could occur. Three areas related
to sensitive system resources are: (1) restricting and monitoring
access, (2) implementing adequate media controls over sensitive data,
and (3) where appropriate, implementing effective cryptographic
controls. Such sensitive system resources include system software,
system utilities, configuration management systems, file maintenance
systems, security software, data communications systems, and database
management systems. Restricting access to sensitive system resources
such as system software and related documentation is critical to
controlling the overall integrity of information systems. For example,
if system software is not adequately protected, an individual could
gain access to capabilities that would allow him or her to bypass
security features found in either operating system security software or
access controls built into application software. The individual would
then be able to read, modify, or destroy application programs, master
data files, and transaction data, and subsequently erase any electronic
audit trail of his or her activities. In addition, inadequate media
controls can result in a loss of confidentiality of sensitive data.
Further, cryptographic controls may be needed to protect sensitive
information where it is not otherwise possible or practical to
adequately restrict access through either physical or logical access
controls.
AC-4.1. Access to sensitive system resources is restricted and
monitored:
Access to sensitive system resources, such as system software and
powerful system utilities, should be appropriately restricted and
monitored. System software is a set of programs designed to operate and
control the processing activities of computer equipment. Generally, one
set of system software is used to support and control a variety of
applications that may run on the same computer hardware. System
software helps control and coordinates the input, processing, output,
and data storage associated with all of the applications that run on a
system. Some system software can change data and program code on files
without leaving an audit trail. The following are examples of system
software:
* operating system software;
* system utilities;
* configuration management systems;
* file maintenance software;
* security software;
* data communications systems;
* database management systems.
Access to sensitive system resources should be restricted to
individuals or processes that have a legitimate need for this access
for the purposes of accomplishing a valid business purpose. For
example, access to system software should be restricted to a limited
number of personnel who have job responsibilities associated with the
use of that software. Responsibilities for using system utilities
should be clearly defined and understood by systems programmers.
Application programmers and computer operators should be specifically
prohibited from accessing system software. Justification and approval
by appropriate entity officials for access to system software should be
documented and retained. Appropriate entity officials should
periodically review the use of privileged system software and utilities
to ensure that access permissions correspond with position descriptions
and job duties. Further, the use of sensitive/privileged accounts
should be adequately monitored. Responsibilities for monitoring use
should be clearly defined and understood by entity officials.
Typically, access to operating system software is restricted to a few
systems programmers whose job it is to modify the system, when needed,
and intervene when the system will not operate properly. In addition,
database administrators need access to the system’s database management
system and a designated senior-level security administrator needs
access to security software. However, application programmers and
computer operators should not have access to system software, as this
would be incompatible with their assigned responsibilities and could
allow unauthorized actions to occur. (See section 3.4 for details on
segregation of duties.)
The number of personnel authorized to access the system will vary
depending on the size and needs of the entity and, therefore, should be
determined based on an analysis of the agency’s operations. For
example, a large entity that must maintain operations on a 24-hour
basis will need more operating systems analysts and programmers than a
smaller entity that operates on a less intensive schedule. There may be
a tendency for entities to authorize access to many individuals so that
emergency operating problems can be handled promptly. However,
management should balance the need for efficiency with the need for
security.
Because of the powerful capabilities at the disposal of those who have
access to system software and related tools, use of the tools should be
adequately controlled and monitored to identify any inappropriate or
unusual behavior. Such behavior may indicate unauthorized access or an
individual who is improperly exploiting access privileges. For example,
greater than normal use of system software or use at odd hours may
indicate that an individual is using the software to search for system
weaknesses to exploit or to make unauthorized changes to system or
application software or data. For monitoring to be effective in both
detecting and deterring inappropriate use, personnel authorized to use
system software should understand which uses are appropriate and which
are not and also that their activities may be monitored. Such policies
should be documented and distributed to all personnel.
Policies and techniques should be implemented for using and monitoring
the use of system tools and utilities. Some system utilities are used
to perform system maintenance routines that are frequently required
during normal processing operations. Other utilities aid the
development and documentation of applications systems. These utilities
can aid individuals who have fraudulent or malicious intentions in
understanding how the programs or data in an application system operate
and in how to make unauthorized modifications.
Following is a listing of some utilities with their intended functions
that could be misused without proper monitoring and control:
* Flowcharters, transaction profile analyzers, execution path
analyzers, and data dictionaries can be used to understand application
systems.
* Data manipulation utilities, data comparison utilities, and query
facilities can be used to access and view data, with manipulation
utilities also allowing data modification.
* Online debugging facilities permit online changes to program object
code leaving no audit trail and can activate programs at selected start
points.
* Library copiers can copy source code from a library into a program,
text and online editors permit modification of program source code, and
online coding facilities permit programs to be coded and compiled in an
interactive mode.
To prevent or detect the misuse of systems utilities, policies should
be clearly documented regarding their use. In addition, the use of
utilities should be monitored. Generally, system software contains a
feature that provides for logging and reporting of its use. Such
reports should identify when and by whom the software was used. It is
important that this software operation work properly and that the
reports are reviewed on a regular basis.
The availability of standard usage data may assist the systems manager
in identifying unusual activity. Some systems can be designed to
compare standard usage data with actual use and report significant
variances, thus making it easier for the system manager to identify
unusual activity. When questionable activity is identified, it should
be investigated. If improper activity is determined to have occurred,
in accordance with security violation policies, the incident(s) should
be documented, appropriate disciplinary action taken, and, when
appropriate, higher-level management notified. Further, the possibility
of damage or alteration to the system software, application software,
and related data files should be investigated and corrective action
taken if needed. Such action should include notifying the resource
owner of the violation.
In addition to controlling access to sensitive system resources, it is
also important to control a number of other activities. First, default
permissions and rights to system software and network devices should be
changed during installation. Second, system libraries should be
appropriately controlled. For example, the migration of system software
from the testing environment to the production environment may be
performed, after approval, by an independent library control group.
Outdated versions of system software should be removed from the
production environment to preclude their use. Some changes may be made
specifically to correct security or integrity vulnerabilities, and
using outdated versions allows the agency’s data and systems to remain
exposed to these vulnerabilities. Third, access to authentication
services and directories should also be appropriately controlled.
Finally, access to mobile code[Footnote 68] (see next paragraph) should
be appropriately controlled due to its potential to cause damage to the
information system if used maliciously.
Mobile code refers to programs (for example, script, macro, or other
portable instruction) that can be shipped unchanged to a heterogeneous
collection of platforms and executed with identical semantics. Being
able to download files and electronic documents off the Internet is a
useful function and a common practice today. Web pages serve as an
electronic counterpart to paper documents; however, unlike paper
documents, Web pages can entail active content that is capable of
delivering digitally encoded multimedia information enlivened through
embedded computer instructions. The popularity of the World Wide Web
has spurred the trend toward active content. A dynamic weather map, a
stock ticker, and live camera views or programmed broadcasts appearing
on a Web page are common examples of the use of this technology. Like
any technology, active content can provide a useful capability, but can
also become a source of vulnerability for an attacker to exploit.
Mobile code controls should include registration, approval, and control
procedures to prevent the development, acquisition, or introduction of
unacceptable mobile code within the information system. All mobile code
or executable content employed should be registered unless otherwise
approved by the authorizing official. Uploading of mobile code or
executable content from one organizational information system to
another should also be similarly authorized.
Sensitive system resources may be further protected by partitioning
applications, isolating security functions, and establishing a trusted
communication path. First of all, through application partitioning, the
information system physically or logically separates user interface
services (for example, public Web pages) from information storage and
management services (for example, database management). Separation may
be accomplished through the use of different computers, different
central processing units, different instances of the operating system,
different network addresses, combinations of these methods, or other
methods as appropriate. Secondly, it is desirable for the information
system to isolate security functions from nonsecurity functions by
means of partitions, domains, etc., including control of access to and
integrity of the hardware, software, and firmware that perform those
security functions. The information system maintains a separate
execution domain (for example, address space) for each executing
process. Thirdly, the information system should establish a trusted
communication path between the user and the security functionality of
the system. Technical experts may be needed to examine and test these
controls. Finally, as appropriate, controls should be in place over
information leakage through electromagnetic signals emanations.
AC-4.2. Adequate media controls have been implemented:
Media controls should be implemented to control unauthorized physical
access to digital and printed media removed from the information system
and during pick up, transport, and delivery to authorized users. Media
should also be properly labeled to identify its sensitivity and
distribution limitations. Finally, all sensitive information should be
removed from media before its disposal or transfer to another use.
As discussed in NIST SP 800-53, information system media includes both
digital media (e.g., diskettes, magnetic tapes, external/removable hard
drives, flash/thumb drives, compact disks, digital video disks) and non-
digital media (e.g., paper, microfilm). Media controls also apply to
portable and mobile computing and communications devices with
information storage capability (e.g., notebook computers, personal
digital assistants, cellular telephones).
NIST SP 800-53 also states that an organizational assessment of risk
guides the selection of media and associated information contained on
that media requiring restricted access. Organizations document in
policy and procedures, the media requiring restricted access,
individuals authorized to access the media, and the specific measures
taken to restrict access. The rigor with which this control is applied
is commensurate with the FIPS 199 security categorization of the
information contained on the media. For example, fewer protection
measures are needed for media containing information determined by the
organization to be in the public domain, to be publicly releasable, or
to have limited or no adverse impact on the organization or individuals
if accessed by other than authorized personnel. In these situations, it
is assumed that the physical access controls where the media resides
provide adequate protection.
One sensitive area is the storage of personally identifiable
information on portable media. The ability to store and transport
substantial volumes of data on portable devices creates an additional
exposure to information confidentiality. The entity should have
adequate controls in place over such portable media. OMB Memorandum M-
06-16 recommends federal agencies encrypt all data on mobile
computers/devices which carry agency data unless the data is determined
to be non-sensitive, in writing, by the agency’s Deputy Secretary or an
individual they may designate in writing.
In addition, as part of the risk assessment process, entities should
identify information that is sensitive, including personally
identifiable information. Entities should implement controls to
adequately protect the confidentiality of such information, including
any copies of such data. OMB Memorandum M-06-16 recommends federal
agencies to log all computer-readable data extracts from databases
holding sensitive information and verify each extract including
sensitive data has been erased within 90 days or its use is still
required. This OMB Memorandum provides additional guidance on controls
over personally identifiable and other sensitive information. Also see
AC-1.2 and AC-2.1. Automated marking and labeling of information helps
to enforce information security access policy. Information system
outputs should be marked using standard naming conventions to identify
any special dissemination, handling, or distribution instructions.
Similarly, information in storage, in process, and transmission should
be appropriately labeled. Further, a means should be provided for the
information system to ensure that the labels a user associates with
information provided to the system are consistent with the information
that the user is allowed to access. It is important that security
parameters are exchanged between systems to authenticate services
requested by another system. Security parameters include, for example,
security labels and markings. Security parameters may be explicitly or
implicitly associated with the information contained within the
information system.
The entity should have policies and procedures in place to remove
sensitive information[Footnote 69] and software from computers, disks,
and other equipment or media when they are disposed of or transferred
to another use. Further, approved equipment and techniques should be
used and periodically tested to ensure correct performance. If
sensitive information is not fully cleared, it may be recovered and
inappropriately used or disclosed by individuals who have access to the
discarded or transferred equipment and media. The responsibility for
clearing information should be clearly assigned. Also, standard forms
or a log should be used to document that all discarded or transferred
items are examined for sensitive information and that this information
is cleared before the items are released.
AC-4.3. Cryptographic controls are effectively used:
Where appropriate, cryptographic tools help provide access control by
rendering data unintelligible to unauthorized users and/or protecting
the integrity of transmitted or stored data. In some cases—especially
those involving telecommunications—it is not possible or practical to
adequately restrict access through either physical or logical access
controls. In these cases, cryptographic tools can be used to identify
and authenticate users and help protect the integrity and
confidentiality of data and computer programs, both while these data
and programs are “in” the computer system and while they are being
transmitted to another computer system or stored on removable media.
As discussed in FIPS Pub 140-2, cryptographic-based security systems
may be utilized in various computer and telecommunication applications
(e.g., data storage, access control and personal identification,
network communications, radio, facsimile, and video) and in various
environments (e.g., centralized computer facilities, office
environments, and hostile environments). The cryptographic services
(e.g., encryption, authentication, digital signature, and key
management) provided by a cryptographic module are based on many
factors that are specific to the application and environment. The
security level to which a cryptographic module is validated should be
chosen to provide a level of security appropriate for the security
requirements of the application and environment in which the module
will be utilized and the security services that the module will
provide. The security requirements for a particular security level
include both the security requirements specific to that level and the
security requirements that apply to all modules regardless of the
level.
Cryptography involves the use of algorithms (mathematical formulae) and
combinations of keys (strings of bits) to do any or all of the
following:
* encrypt, or electronically scramble a message or file so that it is
unintelligible to those who do not have the secret key needed to
decrypt it, thus keeping the contents of the message or file
confidential,
* provide an electronic signature that can be used to determine if any
changes have been made to the related file, thus ensuring the file’s
integrity, and,
* link a message or document to a specific individual’s or group’s key,
thus ensuring that the “signer” of the file can be identified.
Cryptographic tools are especially valuable for any application that
involves “paperless” transactions or for which the users want to avoid
relying on paper documents to substantiate data integrity and validity.
Examples include:
* electronic commerce, where purchase orders, receiving reports, and
invoices are created, approved, and transmitted electronically;
* travel administration, where travel orders and travel vouchers are
created, approved, and transmitted electronically; and;
* protection of documents or digital images, such as contracts,
personnel records, or diagrams, which are stored on electronic media.
Cryptographic tools may be linked to an individual application or
implemented so that they can be used to sign or encrypt data associated
with multiple applications. For example, the personal computers
connected to a local area network may each be fitted with hardware
and/or software that identifies and authenticates users and allows them
to encrypt, sign, and authenticate the messages and files that they
send or receive, regardless of the application that they are using.
There are a number of technical issues to consider concerning
cryptography. Some of the key considerations are listed here.
* Are the cryptographic tools implemented in software or through the
use of a hardware module? (Hardware modules are generally more secure.)
* How is the data transmitted between the computer’s memory and the
cryptographic module, and is this path protected?
* How strong, or complex, is the algorithm used to encrypt and sign
data?
* How are keys managed and distributed?
* Does the agency’s use of cryptographic tools comply with related
Federal Information Processing Standards issued by NIST?
* Has the entity chosen cryptographic techniques that are appropriate
to cost-effectively meet its defined control objectives?
If the auditor encounters cryptographic tools and determines that their
reliability is important to his or her understanding of the controls,
they should obtain the most recent guidance available from OMB, NIST,
and GAO, as well as technical assistance from an auditor experienced in
assessing cryptographic tools.
Control Techniques and Suggested Audit Procedures for Critical Element
AC-4:
AC-4 Related NIST SP-800-53 Controls:
AC-15 Automated Marking;
AC-16 Automated Labeling;
IA-7 Cryptographic Module Authentication;
MP-2 Media Access;
MP-3 Media Labeling;
MP-4 Media Storage;
MP-5 Media Transport;
MP-6 Media Sanitization and Disposal;
PE-19 Information Leakage;
SC-2 Application Partitioning;
SC-3 Security Function Isolation;
SC-4 Information Remnance;
SC-8 Transmission Integrity;
SC-9 Transmission Confidentiality;
SC-11 Trusted Path;
SC-12 Cryptographic Key Establishment and Management;
SC-13 Use of Cryptography;
SC-16 Transmission of Security Parameters;
SC-18 Mobile Code.
Table 19. Control Techniques and Suggested Audit Procedures for
Critical Element AC-4: Adequately protect sensitive system resources:
Control activity: AC-4.1. Access to sensitive system resources is
restricted and monitored.
Control techniques:
Review pertinent policies and procedures.
Audit procedures:
Interview management and systems personnel regarding access
restrictions.
Control activity: AC-4.1. Access to sensitive system resources is
restricted and monitored.
Control techniques:
AC-4.1.1. Access to sensitive/privileged accounts is restricted to
individuals or processes having a legitimate need for the purposes of
accomplishing a valid business purpose.
Audit procedures:
Identify and test who has access to sensitive/privileged accounts and
determine the reason for that access.
Control activity: AC-4.1. Access to sensitive system resources is
restricted and monitored.
Control techniques:
AC-4.1.2. Use of sensitive/privileged accounts is adequately monitored.
Audit procedures:
Determine if the use of sensitive and privileged accounts is monitored
and evaluate its effectiveness.
Control activity: AC-4.1. Access to sensitive system resources is
restricted and monitored.
Control techniques:
AC-4.1.3. Logical access to utilities and tools is adequately
controlled (for example, remote maintenance).
Audit procedures:
Determine the last time the access capabilities of system programmers
were reviewed. Review security software settings to identify types of
activity logged. Observe personnel accessing system software, such as
sensitive utilities and note the controls encountered to gain access.
Attempt to access the operating system and other system software.
Select some application programmers and determine whether they are
authorized access.
Control activity: AC-4.1. Access to sensitive system resources is
restricted and monitored.
Control techniques:
AC-4.1.4. System libraries are appropriately controlled.
Audit procedures:
Determine if access to system libraries is adequately controlled.
Control activity: AC-4.1. Access to sensitive system resources is
restricted and monitored.
Control techniques:
AC-4.1.5. Passwords/authentication services and directories are
appropriately controlled and encrypted when appropriate.
Audit procedures:
Determine if password files and authentication services are adequately
protected from unauthorized access.
Control activity: AC-4.1. Access to sensitive system resources is
restricted and monitored.
Control techniques:
AC-4.1.6. Mobile code is appropriately controlled.
Audit procedures:
Interview system administrator and determine if mobile code is
adequately controlled.
Control activity: AC-4.1. Access to sensitive system resources is
restricted and monitored.
Control techniques:
AC-4.1.7. Where appropriate, access is restricted based on time and/or
location.
Audit procedures:
Determine if access is appropriately restricted based on time and/or
location.
Control activity: AC-4.1. Access to sensitive system resources is
restricted and monitored.
Control techniques:
AC-4.1.8. The information system partitions or separates user
functionality (including user interface services) from information
system management functionality.
Audit procedures:
Interview officials and review related system documentation. Coordinate
with vulnerability analysis.
Control activity: AC-4.1. Access to sensitive system resources is
restricted and monitored.
Control techniques:
AC-4.1.9. The information system isolates security functions from
nonsecurity functions.
Audit procedures:
Interview officials and review related system documentation. Coordinate
with vulnerability analysis.
Control activity: AC-4.1. Access to sensitive system resources is
restricted and monitored.
Control techniques:
AC-4.1.10. The information system establishes a trusted communications
path between the user and the security functionality of the system.
Audit procedures:
Interview officials with system and communication responsibilities and
examine appropriate records such as developer design documents.
Control activity: AC-4.2. Adequate media controls have been
implemented.
Control techniques:
AC-4.2.1. Only authorized users have access to printed and digital
media removed from the information system.
Audit procedures:
Interview personnel and review procedures. Observe entity practices and
review selected access logs.
Control activity: AC-4.2. Adequate media controls have been
implemented.
Control techniques:
AC-4.2.2. The information system automatically identifies how
information is to be used:
* output is marked using standard naming conventions, and;
* internal data in storage, process and transmission is labeled.
Audit procedures:
Interview appropriate personnel. For output, identify standard naming
conventions and examine the system configuration. For internal data,
examine the labeling mechanism and internal data for accurate labels.
Test output and internal data for appropriate results.
Control activity: AC-4.2. Adequate media controls have been
implemented.
Control techniques:
AC-4.2.3. The organization controls the pickup, transport, and delivery
of information system media (paper and electronic) to authorized
personnel.
Audit procedures:
Interview officials and review appropriate policy and procedures.
Observe selected media transport practices and receipts.
Control activity: AC-4.2. Adequate media controls have been
implemented.
Control techniques:
AC-4.2.4. Systems media is securely stored according to its
sensitivity.
Audit procedures:
Determine if media storage practices are adequate and comply with
applicable requirements (for federal agencies, FIPS 199 security
categories).
Control activity: AC-4.2. Adequate media controls have been
implemented.
Control techniques:
AC-4.2.5. Security parameters are clearly associated with information
exchanged between information systems.
Audit procedures:
Determine if security parameters are clearly associated with
information exchanged.
Control activity: AC-4.2. Adequate media controls have been
implemented.
Control techniques:
AC-4.2.6. Approved equipment, techniques, and procedures are
implemented to clear sensitive data from digital media before its
disposal or release for reuse outside of the organization.
Audit procedures:
Review written procedures; interview personnel responsible for clearing
data from digital media. For a selection of recently discarded or
transferred items, examine documentation related to clearing of data
and disposal of software. For selected items still in the agency’s
possession, test to determine whether they have been appropriately
sanitized.
Control activity: AC-4.3. Cryptographic controls are effectively used.
Control techniques:
AC-4.3.1. Cryptographic tools have been implemented to protect the
integrity and confidentiality of sensitive and critical data and
software programs.
Audit procedures:
Determine if cryptographic tools are properly implemented. (See NIST
standards for federal agencies) To evaluate the use of cryptographic
tools, the auditor should obtain the assistance of a specialist.
Control activity: AC-4.3. Cryptographic controls are effectively used.
Control techniques:
AC-4.3.2. Encryption procedures are implemented in data communications
where appropriate based on risk.
Audit procedures:
Capture passwords transmitted over the network and determine if they
are encrypted; for federal system, determine if cryptographic
authentication complies with FIPS 140-2. To evaluate cryptographic
tools, the auditor should obtain the assistance of a specialist.
Control activity: AC-4.3. Cryptographic controls are effectively used.
Control techniques:
AC-4.3.3. For authentication to a cryptographic module, the information
system employs appropriate authentication methods.
Audit procedures:
Interview appropriate officials and review supporting documentation.
For federal agencies, compare the authentication process to FIPS 140-2
requirements.
Control activity: AC-4.3. Cryptographic controls are effectively used.
Control techniques:
AC-4.3.4. The information system employs automated mechanisms with
supporting procedures or manual procedures for cryptographic key
establishment and key management.
Audit procedures:
Compare policy and practices to appropriate guidance, such as NIST
guidance in SP 800-56 and SP 800-57 for cryptographic key establishment
and management, respectively.
Source: GAO.
[End of table]
Critical Element AC-5. Implement an effective audit and monitoring
capability:
Audit and monitoring involves the regular collection, review, and
analysis of auditable events for indications of inappropriate or
unusual activity, and the appropriate investigation and reporting of
such activity. Automated mechanisms may be used to integrate audit
monitoring, analysis, and reporting into an overall process for
investigation and response to suspicious activities. Audit and
monitoring controls can help security professionals routinely assess
computer security, perform investigations during and after an attack,
and even recognize an ongoing attack. Audit and monitoring technologies
include network and host-based intrusion detection systems, audit
logging, security event correlation tools, and computer forensics.
Network-based intrusion detection systems (IDSs) capture or “sniff” and
analyze network traffic in various parts of a network. On the other
hand, host-based IDSs analyze activity on a particular computer or
host. Both types of IDS have advantages and disadvantages.
FISMA requires that each agency implement an information security
program that includes procedures for detecting, reporting, and
responding to security incidents. Further, OMB is to ensure the
operation of a central federal information security incident center to:
* provide timely technical assistance to system operators,
* compile and analyze incident information,
* inform system operators about threats and vulnerabilities, and;
* consult with NIST, national security agencies, and other designated
agencies such as the Department of Homeland Security.
NIST issued two relevant special publications that provide additional
information:
* SP 800-94, Guide to Intrusion Detection and Prevention Systems
(IDPS), and;
* SP 800-61, Computer Security Incident Handling Guide.
SP 800-61 discusses four steps in incident handling:
* preparation,
* detection and analysis,
* containment, eradication, and recovery, and,
* post-incident activity.
An IDS detects inappropriate, incorrect, or anomalous activity aimed at
disrupting the confidentiality, integrity, or availability of a
protected network and its computer systems. An IDS collects information
on a network, analyzes the information on the basis of a preconfigured
rule set, and then responds to the analysis. A description of the
technologies, their effectiveness, and how they work is described in
Technologies to Secure Federal Systems, GAO-04-467 (Washington, D.C.:
March 2004).
AC-5.1. An effective incident response program is documented and
approved:
An effective incident response program should be implemented. Control
techniques include:
* documented policies and procedures, including an incident response
plan;
* documented testing of the incident response plan;
* a means of prompt centralized reporting;
* active monitoring of alerts and advisories;
* response team members with the necessary knowledge, skills, and
abilities;
* training on roles and responsibilities and periodic refresher
training;
* links to other relevant groups;
* protection against denial of service attacks; and;
* appropriate incident response assistance and consideration of
computer forensics.
OMB tasks NIST with coordinating activities governmentwide for agencies
sharing information concerning common vulnerabilities and threats.
Finally, Appendix III of OMB Circular A-130 directs the Department of
Justice to provide appropriate guidance on pursuing legal remedies in
the case of serious incidents.
According to NIST, the two main benefits of an incident-handling
capability are (1) containing and repairing damage from incidents and
(2) preventing future damage. Other, less obvious, benefits of an
incident-handling capability include:
* improved threat data for use in the risk assessment and control
selection process,
* enhanced internal communication and organizational preparedness, and,
* enhanced training and awareness programs by providing trainers with
better information on users’ knowledge and providing real-life
illustrations for classes.
Also, according to NIST, the characteristics of a good incident-
handling capability include:
* an understanding of the constituency being served, including computer
users and program managers;
* an educated constituency that trusts the incident-handling team;
* a means of prompt centralized reporting, such as through a hotline;
* a response team with the necessary knowledge, skills, and abilities,
including technical expertise with the computer technology used by the
agency, and the ability and willingness to respond when and where
needed; and,
* links to other groups—such as law enforcement agencies, response
teams, or security groups external to the agency—and to the agency’s
public relations office (in case the incident receives media
attention).
One aspect of incident response that can be especially problematic is
gathering the evidence to pursue legal action. Incident response
training and assistance is important for users of information systems
to understand the proper handling and reporting of security incidents.
Resources should be available to provide adequate computer forensics of
security incidents. To gather evidence, an entity may need to allow an
intruder or violator to continue his or her inappropriate activities—a
situation that puts the system and data at continued risk. However,
fear of detection and prosecution can serve as a deterrent to future
violations.
The United States Computer Emergency Readiness Team (US–CERT) was
established in September 2003 to provide a national incident response
capability. US–CERT is a partnership of the Department of Homeland
Security and the public and private sectors. Established to protect the
nation’s Internet infrastructure, US-CERT coordinates defense against
and responses to cyber attacks across the nation. Specifically, it is
responsible for analyzing and reducing cyber threats and
vulnerabilities, disseminating cyber threat warning information, and
coordinating incident response activities.
As the nation’s focal point for preventing, protecting against, and
responding to cyber security vulnerabilities, US–CERT interacts with
all federal agencies, private industry, the research community, state
and local governments, and others on a 24X7 basis to disseminate
reasoned and actionable cyber security information. To provide security
information to the public, US–CERT:
* integrates content contributed by numerous organizations from both
the public and private sectors,
* aggregates and analyzes the various types of data provided by
contributing organizations,
* serves as the focal point for promoting common and comprehensive
analysis of security trends and risks, and,
* maintains quality control standards and works to ensure technical
accuracy as well as timeliness.
Worldwide, there are more than 250 organizations that use the name CERT
or a similar name and deal with cyber security response. US–CERT and
the CERT Coordination Center at Carnegie Mellon University work jointly
on cyber security activities. When a cyber security problem warrants,
US-CERT coordinates a response by working with computer security
experts from public and private state and local incident response
teams. See [hyperlink, http://www.us-cert.gov/aboutus.html].
In addition, the incident response program is affected by and should be
responsive to the configuration of the entity’s networks. For example,
it can affect the placement of intrusion detection systems.
Also, the network and related access controls can be designed to aid in
containment of security breaches to limited areas of the network. Also,
the incident response program should appropriately consider treatment
of privacy information. Specifically, federal entities should comply
with applicable statutes and the following OMB Memoranda:
* M-06-15, Safeguarding Personally Identifiable Information (5/22/06);
* M-06-16, Protection of Sensitive Agency Information (6/23/06);
* M-06-19, Reporting Incidents Involving Personally Identifiable
Information and Incorporating the Cost for Security in Agency
Information Technology Investments (7/12/06);
* OMB Reporting Instructions for the Federal Information Security
Management Act and Agency Privacy Management (generally annual OMB
memorandums);
* Recommendations for Identity Theft Related Data Breach Notifications
(9/20/06);
* M-07-04, Use of Commercial Credit Monitoring Services Blanket
Purchase Agreements (12/22/06).
AC-5.2. Incidents are effectively identified and logged:
Entity policies and procedures should establish criteria for the
identification of significant system events that should be logged.
Based on such criteria, the entity should identify significant system
events. At a minimum, all such significant events,[Footnote 70]
including access to and modification of sensitive or critical system
resources, should be logged. However, to be effective:
* this feature should be activated to log critical activity, maintain
critical audit trails, and report unauthorized or unusual activity;
* access to audit logs should be adequately controlled; and;
* managers should review logs for unusual or suspicious activity and
take appropriate action.
Access control software should be used to maintain an audit trail of
security access containing appropriate information for effective review
to determine how, when, and by whom specific actions were taken. For
example, time stamps of audit records should be generated using
internal information system clocks that are synchronized systemwide.
Such information is critical to monitoring compliance with security
policies and when investigating security incidents. The settings of the
access control software control the nature and extent of audit trail
information provided. Typically, audit trails may include user ID,
resource accessed, date, time, terminal location, and specific data
modified. The information system should have the capability to
determine whether or not a given individual took a particular action
(non-repudiation).
The completeness and value of the audit trails maintained will only be
as good as the agency’s ability to thoroughly identify the critical
processes and the related information that may be needed. Procedures
for maintaining such audit trails should be based on:
* the value or sensitivity of data and other resources affected;
* the processing environment, for example, systems development,
testing, or production;
* technical feasibility; and;
* legal and regulatory requirements.
Audit trails, including automated logs, need to be retained for an
appropriate period of time. Therefore, the entity needs to allocate
sufficient audit record storage capacity and configure auditing to
prevent the storage capacity from being exceeded. The information
system should provide a warning when storage capacity reaches a certain
level. If storage capacity is reached, the system should alert
appropriate officials and take appropriate, predefined actions such as
saving the oldest data offline, shutting down the system, overwriting
the oldest audit records, or stop generating audit records.
An effective intrusion detection system (IDS) should be implemented,
including appropriate placement of intrusion-detection sensors and
setting of incident thresholds. IDS security software generally
provides a means of determining the source of a transaction or an
attempted transaction and of monitoring users’ activities (audit
trail).
AC-5.3. Incidents are properly analyzed and appropriate actions taken:
Because all of the audit trail and log information maintained is likely
to be too voluminous to review on a routine basis, the IDS security
software should be implemented to selectively identify unauthorized,
unusual, and sensitive access activity, such as:
* attempted unauthorized logical and physical access;
* access trends and deviations from those trends;
* access to sensitive data and resources;
* highly-sensitive privileged access, such as the ability to override
security controls;
* access modifications made by security personnel; and;
* unsuccessful attempts to logon to a system.
Modern information systems may have an audit-reduction and report-
generation capability to automatically process audit records for events
of interest based on selectable event criteria. The security software
should be designed to report such activity and, in some cases, respond
by actions such as:
* disabling passwords,
* terminating repeated failed attempts to access sensitive resources,
* terminating processing,
* shutting down terminals,
* issuing warning or error messages, and,
* writing audit trail records that would not normally be maintained.
Once unauthorized, unusual, or sensitive access activity is identified,
it should be reviewed and apparent or suspected violations
investigated. If it is determined that a security violation has
occurred, appropriate action should be taken to identify and remedy the
control weaknesses that allowed the violation to occur, repair any
damage that has been done, and determine and discipline the
perpetrator. It is important that an entity have formal written
procedures for reporting security violations or suspected violations to
a central security management office so that multiple related incidents
can be identified, other employees can be alerted to potential threats,
and appropriate investigations can be performed. Such incidents might
include multiple attacks by a common hacker or repeated infections with
the same computer virus.
Without prompt and appropriate responses to security incidents,
violations could continue to occur and cause damage to an agency’s
resources indefinitely. Further, violators will not be deterred from
continuing inappropriate access activity, which could cause
embarrassment to the entity and result in disclosure of confidential
information and financial losses.
An entity should have documented procedures in place for responding to
security violations. These should include procedures and criteria for:
* incident containment, eradication, and recovery,
* documenting offenses,
* determining the seriousness of violations,
* reporting violations to higher levels of management,
* investigating violations,
* imposing disciplinary action for specific types of violations,
* notifying the resource owner of the violation,
* sharing incident and threat information with owners of connected
systems, and,
* reporting suspected criminal activity to law enforcement officials.
Further, access control policies and techniques should be modified when
violations, incidents, and related risk assessments indicate that such
changes are appropriate.
In addition, the frequency and magnitude of security violations and the
corrective actions that have been taken should periodically be
summarized and reported to senior management. Such a report can assist
management in its overall management of risk by identifying the most
attractive targets, trends in types of violations, cost of securing the
agency’s operations, and any need for additional controls.
Finally, since even the best incident response program may not catch
increasingly sophisticated system intrusions, critical system resources
should be periodically reviewed for integrity. For example, an
organization may employ integrity verification applications on the
information system to automatically look for evidence of information
tampering, errors, and omissions.
AC-5 Related NIST SP-800-53 Controls:
AC-13 Supervision and Review—Access Control;
AT-5 Contacts with Security Groups and Associations;
AU-2 Auditable Events;
AU-3 Content of Audit Records;
AU-4 Audit Storage Capacity;
AU-5 Response to Audit Processing Failures;
AU-6 Audit Monitoring, Analysis, and Reporting;
AU-7 Audit Reduction and Report Generation;
AU-8 Time Stamps;
AU-9 Protection of Audit Information;
AU-11 Audit Record Retention;
IR-1 Incident Response Policy and Procedures;
IR-2 Incident Response Training;
IR-3 Incident Response Testing and Exercises;
IR-4 Incident Handling;
IR-5 Incident Monitoring;
IR-6 Incident Reporting;
IR-7 Incident Response Assistance;
SC-5 Denial Of Service Protection;
SI-4 Information System Monitoring Tools and Techniques;
SI-6 Security Functionality Verification.
Control Techniques and Suggested Audit Procedures for Critical Element
AC-5:
Table 20. Control Techniques and Suggested Audit Procedures for
Critical Element AC-5: Implement an effective audit and monitoring
capability:
Control activity:
AC-5.1. An effective incident response program is documented and
approved.
Control techniques:
AC-5.1.1. An effective incident-response program has been implemented
and include:
* documented policies, procedures, and plans;
* documented testing of the incident response plan and follow-up on
findings;
* a means of prompt centralized reporting;
* active monitoring of alerts/advisories;
* response team members with the necessary knowledge, skills, and
abilities;
* training on roles and responsibilities and periodic refresher
training;
* links to other relevant groups;
* protection against denial-of-service attacks (see [hyperlink,
http://icat.nist.gov]);
* appropriate incident-response assistance; and;
* consideration of computer forensics.
Audit procedures:
Interview security manager, response team members, and system users;
review documentation supporting incident handling activities; compare
practices to policies, procedures, and related guidance such as NIST SP
800-61 that provides guidance on incident-handling and reporting.
Determine qualifications of response team members; review training
records; identify training in incident response roles and
responsibilities. Identify the extent to which computer forensics is
used and compare to applicable guidelines and industry best practices.
Control activity:
AC-5.2. Incidents are effectively identified and logged.
Control techniques:
AC-5.2.1. An effective intrusion detection system has been implemented,
including appropriate placement of intrusion-detection sensors and
incident thresholds.
Audit procedures:
Obtain the design and justification for the intrusion detection system;
determine if the placement of sensors and incident thresholds is
appropriate based on cost and risk.
Control activity:
AC-5.2. Incidents are effectively identified and logged.
Control techniques:
AC-5.2.2. An effective process has been established based on a risk
assessment, to identify auditable events that will be logged.
Audit procedures:
Interview the security manager to determine the process for determining
what actions are logged. Determine if security event correlation tools
are used to identify anomalous network activity.
Control activity:
AC-5.2. Incidents are effectively identified and logged.
Control techniques:
AC-5.2.3. All auditable events, including access to and modifications
of sensitive or critical system resources, are logged.
Audit procedures:
Review security software settings to identify types of activity logged;
compare to NIST guidance on auditable events.
Control activity:
AC-5.2. Incidents are effectively identified and logged.
Control techniques:
AC-5.2.4. Audit records contain appropriate information for effective
review including sufficient information to establish what events
occurred, when the events occurred (for example, time stamps), the
source of the events, and the outcome of the events.
Audit procedures:
Determine if audit records/logs are reviewed and whether they contain
appropriate information; see appropriate NIST guidance.
Control activity:
AC-5.2. Incidents are effectively identified and logged.
Control techniques:
AC-5.2.5. Audit record storage capacity is adequate and configured to
prevent such capacity from being exceeded. In the event of an audit
failure or audit storage capacity being reached, the information system
alerts officials and appropriate action is taken.
Audit procedures:
Determine the retention period for audit records and logs and whether
it complies with applicable guidance. Determine if audit capacity is
sufficient and what happens should it be exceeded.
Control activity:
AC-5.2. Incidents are effectively identified and logged.
Control techniques:
AC-5.2.6. Audit records and tools are protected from unauthorized
access, modification, and deletion. Audit records are effectively
reviewed for unusual or suspicious activity or violations.
Audit procedures:
Determine how access to audit records/logs is controlled; review logs
for suspicious activity and evidence of entity follow-up and
appropriate corrective action.
Control activity:
AC-5.2. Incidents are effectively identified and logged.
Control techniques:
AC-5.2.7. Audit records are retained long enough to provide support for
after-the-fact investigations of security incidents and to meet
regulatory and organizational information retention requirements.
Audit procedures:
Determine if audit record retention (for example, logs etc.) meet legal
requirements and entity policy for computer forensics.
Control activity:
AC-5.3. Incidents are properly analyzed and appropriate actions taken.
Control techniques:
AC-5.3.1. Security violations and activities, including failed logon
attempts, other failed access attempts, and sensitive activity, are
reported and investigated.
Audit procedures:
Review pertinent policies and procedures; review security violation
reports; examine documentation showing reviews of questionable
activities.
Control activity:
AC-5.3. Incidents are properly analyzed and appropriate actions taken.
Control techniques:
AC-5.3.2. Security managers investigate security violations and
suspicious activities and report results to appropriate supervisory and
management personnel.
Audit procedures:
Test a selection of security violations to verify that follow-up
investigations were performed and reported to appropriate supervisory
and management personnel.
Control activity:
AC-5.3. Incidents are properly analyzed and appropriate actions taken.
Control techniques:
AC-5.3.3. Appropriate disciplinary actions are taken.
Audit procedures:
For the sample in AC-5.3.2, determine what action was taken against the
perpetrator.
Control activity:
AC-5.3. Incidents are properly analyzed and appropriate actions taken.
Control techniques:
AC-5.3.4. Violations and incidents are analyzed, summarized, and
reported to senior management and appropriate government authorities.
Interview senior management and personnel responsible for summarizing
violations; review any supporting documentation.
Audit procedures:
Determine if automated tools are used to analyze network activity and
whether it complies with security policy.
Control activity:
AC-5.3. Incidents are properly analyzed and appropriate actions taken.
Control techniques:
AC-5.3.5. Alerts and advisories are issued to personnel when
appropriate.
Audit procedures:
Identify recent alerts and advisories and determine if they are up-to-
date; interview entity personnel to determine what actions were taken.
Control activity:
AC-5.3. Incidents are properly analyzed and appropriate actions taken.
Control techniques:
AC-5.3.6 Incident and threat information is shared with owners of
connected systems.
Audit procedures:
Determine if incident and threat data are shared with owners of
connected systems; follow up with owners of connected systems to see if
they received this information in a timely manner.
Control activity:
AC-5.3. Incidents are properly analyzed and appropriate actions taken.
Control techniques:
AC-5.3.7. Access control policies and techniques are modified when
violations, incidents, and related risk assessments indicate that such
changes are appropriate.
Audit procedures:
Review policies and procedures and interview appropriate personnel;
review any supporting documentation.
Control activity:
AC-5.3. Incidents are properly analyzed and appropriate actions taken.
Control techniques:
AC-5.3.8. Critical system resources are periodically reviewed for
integrity.
Audit procedures:
Determine how frequently alterations to critical system files are
monitored (for example, integrity checkers, etc.).
Control activity:
AC-5.3. Incidents are properly analyzed and appropriate actions taken.
Control techniques:
AC-5.3.9. Appropriate processes are applied to gather forensic evidence
in support of investigations.
Audit procedures:
Review entity processes to gather forensic information and determine
whether they are adequate. Discuss with appropriate entity management.
Source: GAO.
[End of table]
Critical Element AC-6. Establish adequate physical security controls:
Adequate physical security controls should be established that are
commensurate with the risks of physical damage or access. In evaluating
the effectiveness of physical security controls, the auditor should
consider the effectiveness of the agency’s policies and practices
pertaining to both the overall facility and areas housing sensitive
information technology components. Consequently, an entity should
implement physical security controls in the following areas:
* security planning and management (security management),
* securing the perimeter of the facility (perimeter security),
* controlling access into a facility (entry security),
* controlling access within a facility (interior security), and,
* protection from emerging physical security threats (emerging
threats).
Physical security controls restrict physical access to computer
resources and protect them from intentional or unintentional loss or
impairment. Computer resources to be protected include:
* primary computer facilities,
* cooling system facilities,
* network devices such as routers and firewalls,
* terminals used to access a computer,
* microcomputers and mobile or portable systems,
* devices that display or output information,
* access to network connectivity, such as through “live” network jacks,
* computer file storage areas, and ? telecommunications equipment and
transmission lines.
In June 1995, the Department of Justice (DOJ) published minimum-
security standards for the protection of federal facilities. It
identified and evaluated the various types of security measures that
could be used to counter potential vulnerabilities. The standards cover
perimeter security, entry security, interior security, and security
planning. Because of the considerable differences among facilities and
their security needs, physical holdings are divided into five security
levels to determine which minimum standards are appropriate for which
security levels.[Footnote 71] For federal agency facilities,
appropriate criteria for physical safeguards in place for the overall
facility are Justice standards unless the facility has adopted
different standards. To illustrate, information technology resources
may be housed in a facility that has been designated a national
critical asset in accordance with Homeland Security Presidential
Directive 7[Footnote 72] and therefore require physical security
measures above those required by DOJ standards. For non-federal
entities, appropriate criteria are equivalent guidance or the federal
standards.
Physical controls also include environmental controls, such as smoke
detectors, fire alarms, extinguishers, and uninterruptible power
supplies (see section 3.5, service continuity).
In an IS controls audit being performed as part of a financial audit or
data reliability assessment, the auditor should tailor the
identification of control techniques and audit procedures related to
the entity’s physical security management program to the extent
necessary to achieve the audit objectives, considering the IS controls
identified by the auditor as significant to the audit objectives (e.g.,
internal control over financial reporting). Generally, this would
include consideration of the overall design of the entity’s physical
security program at relevant facilities.
AC-6.1. Establish a physical security management program based on risk:
Risk management is the foundation of an effective physical security
program. The approach to good security is fundamentally similar,
regardless of the assets being protected—information systems,
buildings, or critical infrastructure. Risk management principles for
an effective security program are discussed in section 3.1. In
addition, the testimonies Technologies to Secure Federal Buildings (GAO-
02-687T) and Key Elements of a Risk Management Approach (GAO-02-150T)
elaborate on specific risk management steps that may be applied to the
protection of any critical asset.
The effectiveness of physical security controls depends on the
effectiveness of the agency’s policies and practices pertaining to the
overall facility and to areas housing sensitive information technology
components, including:
* granting and discontinuing access authorizations,
* controlling badges, ID cards, smartcards, passkeys, and other entry
devices,
* controlling entry during and after normal business hours,
* controlling the entry and removal of computer resources (for example,
equipment and storage media) from the facility,
* managing emergencies,
* controlling reentry after emergencies,
* establishing compensatory controls when restricting physical access
is not feasible, as is often the case with telecommunications lines,
and;
* storing computer assets such as equipment and sensitive documents.
In some instances an entity may not be able to fully control their
physical security posture. For example, leased space in a building
managed by another organization. In this case, the entity should
consider compensating controls and ensure that contingency planning
adequately considers their lack of control over physical security.
As with any type of business activity, physical security should be
monitored to ensure that controls are accomplishing their intended
purpose. FISMA specifically requires that federal agencies periodically
test and evaluate information security controls and techniques to
ensure that they are effectively implemented.
Visitors should be controlled. On occasion, persons other than
regularly authorized personnel may be granted access to sensitive areas
or facilities, such as employees from another facility, maintenance
personnel, contractors, and the infrequent or unexpected visitor. None
of these visitors should be granted unrestricted access.[Footnote 73]
Controls should include:
* preplanned appointments,
* identification checks,
* controlling the reception area,
* logging in visitors,
* escorting visitors while in sensitive areas, and,
* periodically changing entry codes to prevent reentry by previous
visitors who might have knowledge of the code.
AC-6.2. Establish adequate perimeter security based on risk:
Perimeter security is the first line of defense against threats that
can cause catastrophic damages to facilities and internal computer
resources. Considerations for perimeter security include:
* controlling vehicle and pedestrian traffic around the facility,
* controlling employee and visitor parking,
* monitoring the perimeter with closed circuit TV (CCTV),
* providing emergency backup power supply, and,
* extending perimeter barriers to prevent unauthorized access and
reduce exposure to explosions.
Perimeter security includes protective controls such as fencing around
sensitive buildings, concrete and earthen and other barriers,
appropriate gates and locks, exterior lighting, guard posts, security
patrols, and detection and monitoring systems.
AC-6.3. Establish adequate security at entrances and exits based on
risk:
Access to facilities should be limited to personnel having a legitimate
need for access to perform their duties. Management should regularly
review the list of persons authorized to have physical access to
sensitive facilities, including contractors and other third parties. In
addition, procedures should be implemented to terminate access
privileges for terminated or separated employees or contractors.
Physical security controls at entrances and exits vary, but may
include:
* manual door or cipher key locks,
* magnetic door locks that require the use of electronic keycards,
* biometrics authentication,
* security guards,
* photo IDs,
* entry logs, and,
* electronic and visual surveillance systems.
Unissued keys or other entry devices should be secure. Issued keys or
other entry devices should be regularly inventoried.
AC-6.4. Establish adequate interior security based on risk:
The effectiveness of physical security controls over sensitive and
critical IT resources within a facility include consideration of
whether the entity has:
* identified all sensitive areas—such as individual rooms or equipment,
software and tape libraries, or telecommunication closets and
lines—that are susceptible to physical access, loss, or impairment;
* identified all physical access points and threats to the sensitive
areas; and;
* developed cost-effective security controls over all physical access
points and addressed all significant threats to sensitive areas.
In addition, the entity should have controls to prevent or detect
surreptitious entry into sensitive areas. For example, could
unauthorized persons gain entry by:
* observing lock combinations entered by authorized personnel?
* obtaining unsecured keycards?
* going over the top of a partition that stops at the underside of a
suspended ceiling when the partition serves as a wall for a sensitive
facility?
* cutting a hole in a plasterboard wall in a location hidden by
furniture?
Many of the control techniques for interior security are similar to
those for perimeter and entry security (for example, locks,
surveillance systems, as well as using and controlling badges, ID
cards, smartcards, passkey, and other entry devices). Additional
considerations include:
* logs and authorization for removal and return of tapes and other
storage media to the library,
* computer terminal locks,
* controlled access to powerful consoles in data centers, and,
* segregation of duties (discussed in section 3.4).
AC-6.5. Adequately protect against emerging threats based on risk:
In addition to traditional physical security considerations, it may be
important to protect building environments from new threats such as
airborne chemical, biological, and radiological (CBR) attacks. Such
protective measures may include the installation of early warning
sensors, the location and securing of air intakes, and plans and
procedures to mitigate the effect of a CBR release. The decisions
concerning which protective measures should be implemented for any
building should be based on several factors, including the perceived
risk associated with the building and its tenants, engineering and
architectural feasibility, and cost.
Appropriate audit procedures related to emerging threats include:
* Interview appropriate officials to identify the level of physical
security controls needed for the facility.
* Review the facility risk and independent assessments (for example,
internal audit, internal office of physical security, outside
consultants) to identify their assessment of risk and the adequacy of
controls in place.
* Observe and document the controls in place. Assess the organization’s
preparations based on what the organization has stated it needs based
on risk, including an evacuation plan for a possible CBR attack.
* Identify any planned projects to enhance physical security controls
in this area through discussions with physical security and building
management/operations staff.
Control Techniques and Suggested Audit Procedures for Critical Element
AC-6:
AC-6 Related NIST SP-800-53 Controls:
PE-2 Physical Access Authorizations;
PE-3 Physical Access Control;
PE-4 Access Control for Transmission Medium;
PE-5 Access Control Policy for Display Medium;
PE-6 Monitoring Physical Access;
PE-7 Visitor Control;
PE-8 Access Records.
Table 21. Control Techniques and Suggested Audit Procedures for
Critical Element AC-6: Establish adequate physical security controls:
Control activity:
AC-6.1. Establish an effective physical security management program
based on risk.
Audit procedures:
Coordinate with sections SM-2 (assess and validate risks), SM-3
(policies and procedures), SD-1 (segregation of duties), and CP-2
(environmental controls).
Control activity:
AC-6.1. Establish an effective physical security management program
based on risk.
Control techniques:
AC-6.1.1. Use a risk management approach to identify the level of
physical security needed for the facility and implement measures
commensurate with the risks of physical damage or access.
Audit procedures:
Interview entity officials to discuss how their physical security
program is organized and whether they use a risk management approach.
Obtain and review any facility risk assessments performed by the entity
or by independent entities.
Control activity:
AC-6.1. Establish an effective physical security management program
based on risk.
Control techniques:
AC-6.1.2. Facilities and areas housing sensitive and critical resources
have been identified. The following generally constitute sensitive
areas: computer rooms, tape libraries, telecommunication closets,
mechanical/electrical rooms, cooling facilities and data transmission
and power lines.
Audit procedures:
Review diagram of physical layout of the computer network,
telecommunications, and cooling system facilities (for example, HVAC);
Inspect these areas for physical access control weaknesses.
Control activity:
AC-6.1. Establish an effective physical security management program
based on risk.
Control techniques:
AC-6.1.3. All significant threats to the physical well-being of these
resources have been identified and related risks determined. Interview
agency officials.
Audit procedures:
Review risk analysis to ensure that it includes physical threats to
employees and assets. Review any recent audit reports or other
evaluations of the facility’s physical security.
Control activity:
AC-6.1. Establish an effective physical security management program
based on risk.
Control techniques:
AC-6.1.4. Establish law enforcement security liaisons that facilitate
the accurate flow of timely security information between appropriate
government agencies, provide procedures for the timely receipt and
dissemination of threat information, and implement a standardized
security/threat classifications and descriptions (for example, alert
levels).
Audit procedures:
Check if the organization has established law enforcement security
liaisons that facilitate the accurate flow of timely security
information between appropriate government agencies. Review how the
organization receives and disseminates security alerts. [Identify
governmental agencies involved in the flow of security information and
interview appropriate officials. Review procedures and nomenclature for
threat information.]
Control activity:
AC-6.1. Establish an effective physical security management program
based on risk.
Control techniques:
AC-6.1.5. Conduct annual employee physical security awareness training.
Coordinate this step with SM-4.
Audit procedures:
Review information (for example, individual training records, training
program content) on security awareness training and its frequency.
Control activity:
AC-6.1. Establish an effective physical security management program
based on risk.
Control techniques:
AC-6.1.6. Security control procedures (for example, trusted
vendors/suppliers, background checks, etc.) are established for non-
employees (contractors, custodial personnel).
Audit procedures:
Review security control procedures for scope and adequacy.
Control activity:
AC-6.1. Establish an effective physical security management program
based on risk.
Control techniques:
AC-6.1.7. Periodic monitoring and independent evaluations of the
physical security program are conducted. Physical security incidents
are effectively monitored and appropriate countermeasures are
implemented.
Audit procedures:
Check if the agency evaluates its physical security program and
controls. Obtain and review the agency’s most recent self assessments
and compliance review report. Determine if security incidents are
recorded, effectively analyzed, and result in appropriate
countermeasures. Coordinate with SM-5: Monitor the effectiveness of the
security program, and AC-5: Implement an effective audit and monitoring
capability.
Control activity:
AC-6.1. Establish an effective physical security management program
based on risk.
Control techniques:
AC-6.1.8. When possible, do not co-locate high risk operations with non-
essential support organizations (for example, cafeteria, day care,
banks, news media). If not possible, place appropriate security between
such support organizations and critical facilities.
Audit procedures:
Identify co-located operations and their respective risk levels.
Determine if the agency co-locates high risk operations with support
operations and assess the security impact.
Control activity:
AC-6.1. Establish an effective physical security management program
based on risk.
Control techniques:
AC-6.1.9. Visitors, contractors, and maintenance personnel are
authenticated through the use of preplanned appointments and
identification checks.
Audit procedures:
Review appointment and verification procedures for visitors,
contractors, and maintenance personnel. Compare actual practices to
procedures.
Control activity:
AC-6.2. Establish adequate perimeter security based on risk.
Control techniques:
AC-6.2.1. Control/restrict vehicle and pedestrian traffic around the
facility based on the facility’s risk level. Specific measures include
fences, gates, locks, guard posts, perimeter patrols and inspections.
Audit procedures:
Determine if vehicle and pedestrian traffic around the facility is
adequately controlled for the risk level. Inspect the perimeter for
physical security and access control weaknesses. Assess the
effectiveness of perimeter guard procedures and practices for
controlling access to facility grounds.
Control activity:
AC-6.2. Establish adequate perimeter security based on risk.
Control techniques:
AC-6.2.2. Control employee and visitor parking. For example, restrict
access to facility parking and parking adjacent to the facility
(including leases), use ID systems and procedures for authorized
parking (for example, placard, decal, card key), have signs and
arrangements for towing of unauthorized vehicles and adequate lighting
for parking areas.
Audit procedures:
Observe parking area and related controls. Check if identification
systems and procedures for authorized parking are in place. Determine
what is done about unauthorized vehicles (e.g. towing).
Control activity:
AC-6.2. Establish adequate perimeter security based on risk.
Control techniques:
AC-6.2.3. Monitor the perimeter with closed circuit television (CCTV)
including cameras with time lapse video recording and warning signs
advising of 24 hour video surveillance.
Audit procedures:
Inspect the facility surveillance camera system to assess its capacity
and ability to assist in protecting the facility’s perimeter.
Control activity:
AC-6.2. Establish adequate perimeter security based on risk.
Control techniques:
AC-6.2.4. Lighting is adequate for effective surveillance and
evacuation operations. Emergency power backup exists for lighting (as
well as for alarm and monitoring systems).
Audit procedures:
Observe perimeter and exterior building lighting to determine its
adequacy. Also, determine if emergency power is available for security
systems. Request test results.
Control activity:
AC-6.2. Establish adequate perimeter security based on risk.
Control techniques:
AC-6.2.5. Extend perimeter barriers (for example, concrete, steel) and
parking barriers, as needed, to prevent unauthorized access and reduce
exposure to explosions.
Audit procedures:
Determine if perimeter barriers are used and extended if appropriate.
AC-6.3. Establish adequate security at entrances and exits based on
risk.
Control activity:
AC-6.2. Establish adequate perimeter security based on risk.
Control techniques:
AC-6.3.1. All employee access is authorized and credentials (for
example, badges, identification cards, smart cards) are issued to allow
access.
Audit procedures:
Observe and document all access control devices used to secure the
facility.
Control activity:
AC-6.2. Establish adequate perimeter security based on risk.
Control techniques:
AC-6.3.2. Access is limited to those individuals who routinely need
access through the use of guards, identification badges, or entry
devices such as key cards.
Audit procedures:
Observe entries to and exits from facilities during and after normal
business hours. Obtain a list of employees and contractors with badged
access and check the justification for such access. Check whether
terminated employees/contractors have turned in their badge.
Control activity:
AC-6.2. Establish adequate perimeter security based on risk.
Control techniques:
AC-6.3.3. Management conducts regular reviews of individuals with
physical access to sensitive facilities to ensure such access is
appropriate.
Audit procedures:
Review procedures used by management to ensure that individuals
accessing sensitive facilities are adequately restricted. Evaluate
support for physical access authorizations and determine
appropriateness.
Control activity:
AC-6.2. Establish adequate perimeter security based on risk.
Control techniques:
AC-6.3.4. Intrusion detection systems with central monitoring
capability are used to control access outside of normal working hours
(for example, nights and weekends).
Audit procedures:
Determine if an intrusion detection system is used and test its use for
appropriate exterior and interior apertures.
Control activity:
AC-6.2. Establish adequate perimeter security based on risk.
Control techniques:
AC-6.3.5. Visitor access logs are maintained and reviewed.
Audit procedures:
Compare entries in the log to a list of personnel authorized access.
Control activity:
AC-6.2. Establish adequate perimeter security based on risk.
Control techniques:
AC-6.3.6. X-ray and magnetometer equipment is used to screen people,
possessions, and packages.
Audit procedures:
Observe how this equipment is used and test its effectiveness.
Control activity:
AC-6.2. Establish adequate perimeter security based on risk.
Control techniques:
AC-6.3.7. The entity controls information system-related items (i.e.,
hardware, firmware, software) entering and exiting the facility and
maintains appropriate records of those items.
Audit procedures:
Review procedures and interview officials. Attempt to enter and exit
the facility with information systems items at various entry points and
times.
Control activity:
AC-6.2. Establish adequate perimeter security based on risk.
Control techniques:
AC-6.3.8. Entry and exit points are monitored by using CCTV capability.
Also, high security locks and alarm systems are required for all doors
that are not guarded.
Audit procedures:
Observe use of these devices and test as appropriate. Inspect the
building(s) for physical access control weaknesses.
Control activity:
AC-6.2. Establish adequate perimeter security based on risk.
Control techniques:
AC-6.3.9. Emergency exit and re-entry procedures ensure that only
authorized personnel are allowed to reenter the facility after fire
drills, etc.
Audit procedures:
Review written emergency procedures. Examine documentation supporting
prior fire drills. Observe a fire drill.
Control activity:
AC-6.4. Establish adequate interior security based on risk.
Control techniques:
AC-6.4.1. An ID badge should generally be displayed at all times. [All
individuals must display an ID at all times.]
Audit procedures:
Observe use of employee and visitor IDs. See what happens if you do not
display your own ID.
Control activity:
AC-6.4. Establish adequate interior security based on risk.
Control techniques:
AC-6.4.2. Visitors such as vendors, contractors, and service personnel
who need access to sensitive areas are prescreened, formally signed in,
badged and escorted. Review visitor entry logs.
Audit procedures:
Observe entries to and exits from sensitive areas during and after
normal business hours. Interview guards at facility entry.
Control activity:
AC-6.4. Establish adequate interior security based on risk.
Control techniques:
AC-6.4.3. Sensitive information technology and infrastructure resources
are adequately secured (for example, using keys, alarm systems,
security software and other access control devices), including:
* the badging system,
* computer room, master consoles, and tape libraries,
* display and output devices,
* data transmission lines,
* power equipment and power cabling,
* mobile or portable systems, and,
* utility and mechanical areas (HVAC, elevator, water).
Audit procedures:
Interview officials. Walk through facilities and observe potential
vulnerabilities and security controls [measures] used to protect
sensitive information technology resources. Observe entries to and
exits from sensitive areas during and after normal business hours.
Review security software features and settings. Evaluate the badging
system: who has access to the badging system and how it is protected;
how is physical control is maintained over unissued and visitor badges.
Test the controls.
Control activity:
AC-6.4. Establish adequate interior security based on risk.
Control techniques:
AC-6.4.4. Management conducts regular reviews of individuals with
physical access to sensitive areas to ensure such access is
appropriate.
Audit procedures:
Review procedures used by management to ensure that individuals
accessing sensitive areas are adequately restricted. Determine if there
is a periodic (e.g. annual) auditing and reconciliation of ID cards.
Evaluate support for physical access authorizations and determine
appropriateness.
Control activity:
AC-6.4. Establish adequate interior security based on risk.
Control techniques:
AC-6.4.5. As appropriate, physical access logs to sensitive areas are
maintained and routinely reviewed.
Audit procedures:
Compare entries in the logs to a list of personnel authorized access.
Control activity:
AC-6.4. Establish adequate interior security based on risk.
Control techniques:
AC-6.4.6. Unissued keys, badges, or other entry devices are secured.
Issued keys or other entry devices are regularly inventoried.
Audit procedures:
Observe practices for safeguarding keys, badges, and other devices.
Control activity:
AC-6.4. Establish adequate interior security based on risk.
Control techniques:
AC-6.4.7. Entry codes are changed periodically.
Audit procedures:
Review documentation of entry code changes.
Control activity:
AC-6.4. Establish adequate interior security based on risk.
Control techniques:
AC-6.4.8. All deposits and withdrawals of storage media from the
library are authorized and logged.
Audit procedures:
Review procedures for the removal and return of storage media to and
from the library. Select from the log some returns and withdrawals,
verify the physical existence of the tape or other media, and determine
whether proper authorization was obtained for the movement.
Control activity:
AC-6.4. Establish adequate interior security based on risk.
Control techniques:
AC-6.4.9. Documents/equipment are appropriately stored and are subject
to maintenance and accountability procedures.
Audit procedures:
Examine and verify maintenance and accountability procedures for
storage of documents and equipment.
Control activity:
AC-6.4. Establish adequate interior security based on risk.
Control techniques:
AC-6.4.10. Critical systems have emergency power supplies (for example,
all alarm systems, monitoring devices, entry control systems, exit
lighting, communication systems).
Audit procedures:
Verify that critical systems, (e.g., alarm systems, monitoring devices,
entry control systems, exit lighting, and communication systems) have
emergency power supplies. Identify back up systems and procedures and
determine the frequency of testing. Review testing results.
Control activity:
AC-6.5. Adequately protect against emerging threats, based on risk.
Control techniques:
AC-6.5.1. Appropriate plans have been developed and controls
implemented based on a risk assessment such as a shelter in place plan
and/or evacuation plan for a potential CBR attack. [A plan is in place
and tested to respond to emerging threats such as a CBR attack (e.g. an
appropriate shelter in place and/or evacuation plan.)
Audit procedures:
Interview officials, review planning documents, and related test
results. Observe and document the controls