A poorly defined IT organization structure can lead to confusion regarding responsibilities, causing IT support functions to be performed inefficiently or ineffectively. For example, critical functions either may be neglected or may be performed redundantly. Also, if lines of authority are not clearly established, it can lead to disagreement as to who has the ultimate ability to make a final decision. Finally, if IT duties are not segregated appropriately, it could lead to fraudulent activities and affect the integrity of the company's information and processes.
A "one size fits all" model for an IT organization doesn't exist, and the auditor can't mechanically use a checklist to determine whether his or her company's IT organization is adequate. Instead, the auditor must view the overall organization and apply judgment in determining whether it adequately addresses the most essential elements. With this in mind, we will discuss below some key areas to consider during this review.
Review IT organization charts and ensure that they clearly indicate reporting structures. The organization charts should provide an indication as to where in the company the various IT organizations meet. For example, in most companies, all IT organizations eventually report to the chief information officer (CIO) so that there is one ultimate authority that is able to set rules for the overall IT environment. Ensure that your company has IT organization reporting structures that eventually report to a single source that is "close enough" to day-to-day IT operations to allow for effective governance and direction setting. If the IT organizations report to multiple CIOs or only consolidate to a high-level executive such as the chief executive officer (CEO), additional processes likely will be needed to develop an effective method for establishing overall policies, priorities, and governance for IT at the company. Otherwise, it is likely that fiefdoms will exist within IT, preventing the establishment of true entity-level IT controls.
Review IT organization charts and charters and ensure that they clearly delineate areas of responsibility. Determine whether it is clear how responsibilities are divided between organizations, or evaluate whether there is significant opportunity for confusion and overlap. In addition to reviewing documented organization charts and charters, consider interviewing a sample of IT employees and customers to determine whether there is a consistent understanding of the division of responsibility.
Evaluate the division of responsibilities within the IT organization to ensure that duties are segregated appropriately. Following are some basic general guidelines that can be considered during the review. Again, this should not be used as a mechanical checklist, and the auditor should review for compensating controls when investigating potential exceptions. The auditor also should consider criticality in making judgments. It is more important that separation of duties be in place over critical financial systems than over systems providing support for minor convenience functions (e.g., the company's internal training system).
The specifics of which duties should be segregated from others will vary by company; however, the general idea is that the responsibilities for initiating, authorizing, inputting, processing, and checking data should be segregated so that one person does not have the ability to create a fraudulent transaction, authorize it, and hide the evidence. In other words, you're attempting to prevent one person from being able to subvert a critical process.
IT personnel should not perform data entry. Keep in mind that IT organizations differ in their composition across companies, so there may be data-entry personnel who are classified as IT in their companies. Here, we're referring to IT personnel who are performing true systems support.
Programmers and those performing run/maintain support for systems should not have the ability to directly modify production code, production data, or the job-scheduling structure. As with all these statements, in cases where there appears to be segregation-of-duties issue, the auditor should look for compensating controls before determining whether there is a true issue. Access to production data and code may not be a large risk if there are strict accountability and change-control procedures in support of that access.
Programmers and those performing run/maintain support for systems should be separate from those performing IT operations support (e.g., support for networks, data centers, operating systems, etc.).
An IT security organization should exist that is responsible for setting policies and monitoring for compliance with those policies. This IT security organization should not have any operational responsibilities outside those related to IT security.
In order to provide for long-term effectiveness, the IT organization must have some sort of strategy regarding where it plans to go, as opposed to always being in reactive mode, where day-to-day issues and crises are the only things considered. The IT organization must be aware of upcoming business needs and changes in the environment so that they can plan and react accordingly. It is important that IT priorities align with business priorities. Too many IT organizations lose sight of the fact that their only reason for existence is to support the company in meeting its business objectives. Instead, these IT organizations focus on becoming a "world-class IT shop," even in cases where this goal doesn't directly support the overall company objectives. It is critical for IT organizations to stay grounded by tying their objectives to the company's objectives.
Look for evidence of a strategic planning process within IT, and understand how that planning is performed. Determine how company strategies and priorities were used in developing the IT strategies and priorities. Review documented short- and long-term IT priorities. Evaluate processes in place for periodically monitoring for progress against those priorities and for reevaluating and updating those priorities.
IT is a rapidly changing environment, and it is important that IT organizations understand and plan for change. Otherwise, the company's IT environment runs the risk of becoming obsolete and/or not fully leveraging technology to benefit the company.
Look for evidence that long-term technical planning is being performed. For purchased applications and technologies, determine whether there is an understanding of the vendor's support roadmap for those products. The IT organization should understand when their versions of the products will cease to be supported and have plans for either upgrading or replacing the products. Determine whether there are processes in place to monitor for changes in relevant technologies, consider how those changes will impact the company, and look for opportunities to use new technologies to help the company.
The IT organization exists in order to support the business and its day-to-day operations. If minimum standards of performance are not established and measured, it is difficult for the business to determine whether the IT organization's services are being performed at an acceptable level.
Obtain a copy of any metrics being captured for the IT organization's routine activities (e.g., system uptime and response time). Determine what the goals for those metrics are, and ensure that the appropriate stakeholders have approved those goals. If actual performance is significantly inferior to goals, determine whether root-cause analyses have been performed to understand the problem and whether plans are in place to solve the problem.
Review any SLAs that have been established for supporting IT's key stakeholders. Ensure that there are processes in place for measuring actual performance against the requirements of the SLA and for correcting any deviations.
Ensure that processes are in place for establishing budgets and for holding the IT organization accountable for meeting its budget. Obtain copies of the IT budget for the current and preceding years, as well as copies of any "budget versus actual" analyses. Determine how any significant variances were reported and resolved.
Without a structured process for approving and prioritizing new IT projects, it is likely that IT resources will not be deployed efficiently. Instead, they will be assigned on an ad hoc basis to whatever potential project comes up next. Also, IT projects may commence that do not meet the needs of the business and/or that are not as important as other potential projects to which those resources could be deployed. Without a structured process whereby management and key stakeholders periodically review the project's progress, it is more likely that the project will get off track and fail to meet key goals and milestones.
Review any available documentation regarding the project proposal and approval process. Evaluate the process for potential holes that might allow a project to commence without approval. Look for evidence that proposed projects have been prioritized prior to approval and that there is some discipline and commonality within this approval process. Consider selecting a sample of active IT projects and obtaining evidence that those projects went through an appropriate process of proposal, prioritization, and approval. Review evidence that management and key stakeholders are periodically reviewing the status, schedule, and budget for active IT projects.
If standards are not in place and enforced in the IT environment, it is more likely that projects will be executed in an undisciplined fashion, quality issues will exist in developed or purchased products, and the IT environment will be unnecessarily diverse (leading to increased support costs and potential interface issues).
Determine whether there are documented standards governing areas such as the following. If so, review those standards and ensure that they are adequate.
Project management. See Chapter 12 for guidelines regarding key elements that should exist within project management standards.
Software development. Standards should exist governing the development of code, including standards for naming, revision history, comments, and calls to other programs. Without such standards, the time and effort required for one person to support and troubleshoot another person's code increase significantly. Note that depending on the size of the IT organization, it may be acceptable for programming standards to be decentralized to a degree. However, each significant development organization should have a set of standards. See Chapter 12 for guidelines regarding key elements that should exist within these standards.
System configuration. This would include standard configuration for laptops, desktops, servers, and common user software packages. Common configuration will help to ensure that the systems are supportable and that they have the appropriate security settings.
Hardware and software. Standards should exist governing the hardware and software that is approved and supported for use in the company. This should include the specific versions that are supported. Otherwise, the IT environment likely will consist of a multitude of products performing similar functions, driving up IT support costs and leading to problems with the ability of the various products to interface with each other.
Quality assurance standards. Standards should exist that ensure that the development process includes the evaluation of security risks and internal control requirements.
Look for evidence that these standards are communicated to all relevant IT employees, and determine how these standards are enforced.
Consider reviewing a sample of recent and active IT projects for evidence that the standards were followed. Consider reviewing a sample of systems for deviations from configuration, hardware, and software standards.
IT security policy sets a baseline of expectations for employees of the company. If policies don't exist or provide adequate coverage, employees are forced to make up their own rules regarding security-related decisions. The same concept extends to computer systems, which require a standard by which system security can be evaluated. If IT security policies are too lenient, they will not provide adequate protection of the company's information assets. If they are too strict, they either will be ignored or will place unnecessary overhead and costs on the business.
If the IT security policies aren't communicated to employees, then they won't be followed. Additionally, if compliance with those policies is not monitored and enforced, employees will learn quickly that the policies can be ignored with no consequence, causing the policies to become "suggestions" rather than requirements.
Verify Adequate Policy Coverage Obtain a copy of your company's IT security policies. Ensure that they adequately cover your company's IT environment. At a minimum, the policies should include coverage of the following areas:
Acceptable usage of the company's information assets by employees (e.g., whether employees can use their computers, the Internet, and e-mail for personal reasons)
Data classification, retention, and destruction
Remote connectivity (e.g., overall network security and security requirements for virtual private network (VPN), dial-up, and other forms of connection to external parties)
Server security (e.g., security requirements for Unix and Windows servers)
Client security (e.g., security requirements for desktops and laptops)
Logical access (e.g., requirements for obtaining and granting access to systems)
Review the policies for adequacy based on industry standards and the specific needs of your company. The audit steps in the other chapters of this section can be used as guidelines.
Specifically review the company's password policy. It should provide adequate guidelines dictating requirements for the composition of company passwords (e.g., minimum of eight characters, combination of letters and numbers, difficult to guess, etc.), for aging company passwords (e.g., requiring that they be changed every 90 days), for locking accounts after a certain number of unsuccessful logon attempts, for timing out login sessions after a period of inactivity, and for retaining a password history so that previous passwords cannot be reused for a certain period of time.
Specifically review the company's logical access policy. It should provide adequate guidelines dictating requirements for every user to have a unique ID, for accounts to be suspended on employee termination or job change, and for users to be granted the minimum access necessary to perform their jobs.
Verify Stakeholder Buy-in Ensure that key stakeholders were included during policy creation. Obtain a list of employees involved in the creation and approval of the IT security policies, such as IT organizations that are expected to comply with the policy. If IT security policies are created in a vacuum by the IT security organization without involving others, they are likely to be viewed as unrealistic and ignored. Involvement from those who provide the day-to-day support of the IT environment will bring an important perspective to the policies and also will ensure buy-in from those who need to enforce and comply with the policies. Ensure that the IT security policies were approved by an executive, such as the CIO or CEO. This will provide the IT organization with the authority and backing necessary to enforce the policies.
Verify Processes around the Policies Review processes for periodically reviewing and updating the policies to ensure that they keep up with the ever-changing IT environment. Look for evidence that these processes have been executed.
Review processes for periodically evaluating changes in the environment that might necessitate the development of new policies. Look for evidence that these processes have been executed.
Ensure that provisions have been made for obtaining approved exemptions from the policy. There inevitably will be occasions when people do not feel that they can comply with the policy. There should be a defined process whereby those people can formally request an exemption from the policy. They should be required to state why they need an exemption and define the compensating controls that will be put in place. The IT security organization should facilitate the exception process, including providing a recommendation and an opinion on the risk presented by the request, but usually should avoid making the final decision as to whether or not to accept the risk. Instead, it usually should be a business decision. Review the escalation policy for the exemption process and ensure that business (as opposed to IT) management is involved at some point, at least for the acceptance of significant risks. Ensure that the final decisions are documented and retained.
Look for evidence that the IT security policies are communicated adequately to all company employees. Potential vectors include referencing the policies during new-hire orientation and/or having all employees periodically sign a statement that they have read and agree to the policies.
Review processes implemented by IT security and other IT organizations for monitoring compliance with the policies. Ensure that enforcement and escalation processes are in place that result in the correction of noncompliant situations. Review a sample of recent applicable compliance-monitoring reports, and ensure that significant issues were tracked to resolution.
Ensure that a mechanism exists for employees to report security incidents or concerns and that those reports are followed up on and tracked to resolution. Review a sample of recently reported incidents, and determine whether they were resolved adequately.
Without these processes, the IT organization will be unaware of risks to the achievement of its objectives and therefore will not have the ability to consciously make decisions regarding whether to accept or mitigate those risks.
There is some overlap between this step and some of the other steps mentioned in this chapter, many of which are designed to determine how the IT organization is evaluating its own risks. It is possible that the auditor will consider this step to be covered adequately without explicitly performing it. However, the auditor should look for evidence that the IT organization is periodically considering the risks to the IT environment and making conscious decisions as to whether to accept, mitigate, or avoid those risks. Risk-assessment mechanisms could include
Monitoring internal controls in the IT environment, including internal audits and self-assessments
Performing formal threat and risk assessments of critical data centers and systems
Performing periodic reviews of the strategic IT plans and technical roadmaps and assessing risks to the achievement of those plans.
Monitoring compliance with IT security policies and other relevant IT policies
If employees in the IT organization are not qualified to perform their jobs, the quality of IT services obviously will be poor. If mechanisms are not in place for maintaining and enhancing the knowledge and skills of IT employees, their knowledge can become outdated and obsolete.
Review human resources (HR) policies and processes as they relate to IT employees. Look for mechanisms that ensure that qualified people are hired and that provide for continuous enhancements of employee skills and knowledge. Review evidence that these policies and processes are followed. For example,
Ensure that job descriptions exist for all IT positions and that the job descriptions specifically state the knowledge and skills required for each job. Review evidence that these job descriptions are referenced during the hiring process. Review processes for keeping the job descriptions up to date.
Review the IT organization's training policies and ensure that they provide the opportunity for employees to attend training classes and seminars for enhancing and updating their skills and knowledge. Look for evidence that IT employees have taken training over the past year.
Review performance-review processes. Look for evidence that IT employees are receiving regular feedback on their performance. Ensure that processes exist for identifying poor performers, coaching them, and moving them out of the organization if performance does not improve. Conversely, ensure that processes exist for identifying top performers, rewarding them, and providing them with incentives to remain at the company.
Although IT is responsible for providing the technology and mechanisms for protecting company data, there must be a framework for making decisions as to what level of protection is necessary for any given data element (based on the criticality of the data). Without such a framework, there will be inconsistency in how data are protected, likely resulting in some data being underprotected (thereby placing critical information assets at risk) or overprotected (leading to unnecessary costs). If the life cycle of data is not defined, it will lead to data being retained longer than necessary (resulting in additional storage costs and possible legal liabilities) or being destroyed prematurely (leading to potential operational, legal, or tax issues).
Review the company's data classification policy. It should have provisions for identifying owners for all critical company data. It also should provide a framework for classifying those data based on their criticality (e.g., confidential, internal data, public data). This framework should provide specific definitions of each classification level, along with specific requirements for how data at each level should be protected (e.g., encryption).
Review evidence that the data classification policy has been implemented. Look for a list of data owners and documentation indicating that those owners have classified their data. For a sample of these data, review evidence that protection has been implemented in alignment with the classification.
Determine whether life-cycle information has been created for company data. For a sample of major data elements, review documentation of the data's life-cycle requirements, including retention, archive, and destruction requirements. Ideally, requirements will be identified for how long the data should be active (e.g., online, easily accessible, modifiable if appropriate, and backed up periodically), when and for how long they should be archived (e.g., possibly offline, not necessarily easy to access, no longer modifiable, and no longer backed up periodically), and when they should be destroyed.
Review evidence that life-cycle requirements have been implemented.
If your company is found to be in violation of applicable laws and regulations, it can lead to stiff penalties and fines, a damaged reputation, lawsuits, and possibly cessation of the company. If a robust process is not in place for monitoring the regulatory environment, the company may be unaware of new laws and regulations, resulting in noncompliance.
Look for a single point of contact that is responsible for monitoring the regulatory environment and its impact on IT. This person or organization should be responsible for identifying laws and regulations that apply to the company's IT environment, ensuring that the responsibility for complying with those rules has been explicitly assigned to the appropriate organization(s), and monitoring the regulatory environment for additions and changes that will affect the company. If there is not a single person or organization responsible for this (or a small subset of people, each with a specific regulatory domain to cover), it likely will be done on an ad hoc basis, providing no assurance of full coverage. Review the processes used to monitor the regulatory environment, and evaluate their effectiveness. Obtain a list of IT-applicable regulations that have been identified, and look for evidence that responsibility for compliance with those regulations has been assigned and is being monitored. See Chapter 14 for more information on laws and regulations that may be applicable to your company.
Because the IT environment exists in order to support the company's employees in performing their jobs, it is critical that processes exist whereby those employees can provide input into the quality of service they are receiving. Otherwise, the IT organization may be misaligned with its users and not be aware of it.
Ensure that there is a help desk function that provides end users with the ability to report problems. Review and evaluate processes for capturing problems and ensuring that they are tracked to resolution. Obtain a list of recent tickets, and select a sample, ensuring that all tickets were resolved and that no tickets were closed without the consent of the user who entered the ticket.
Ensure that a process exists for obtaining end-user feedback after tickets are closed. Look for evidence that user-satisfaction metrics are kept and that management follows up on end-user feedback.
In order to ensure that the help desk does not seek customer satisfaction at the expense of security, review policies and processes for obtaining proper approvals prior to responding to user requests for having passwords reset and for obtaining system access. Review a sample of these sorts of tickets, and ensure that proper processes were followed and approvals obtained.
Review for the existence of customer steering teams to provide input and prioritization of IT projects and enhancements. For significant areas of the business, key stakeholders should be identified to provide guidance to the IT organization regarding projects and decisions that affect them. Otherwise, the IT organization will be making decisions in a vacuum and likely will work on projects or enhancements that do not provide the greatest value for the business.
Review any SLAs that have been established for supporting IT's key stakeholders. Ensure that there are processes in place for measuring actual performance against the requirements of the SLA and for correcting any deviations.
Many companies outsource some or all of their IT support process, including areas such as PC support, web server hosting, system support, programming, etc. If these vendors are not managed appropriately, it can lead to poor service and unacceptable quality in the IT environment. Depending on what portion of the IT environment has been outsourced, it could have a significant impact on the company's operations.
Review the process for selecting vendors. Ensure that the process requires soliciting multiple competitive bids, the comparison of each vendor against predefined criteria, involvement of knowledgeable procurement personnel to help negotiate the contract, and investigation of each vendor's qualifications and financial health. For a sample of recent vendor selections, review evidence that the process was followed.
Ensure that contracts with third-party service providers specifically define the roles and responsibilities of the vendor and include defined SLAs. Review a sample of contracts for evidence that expectations have been specifically defined.
Ensure that contracts include nondisclosure clauses, preventing the vendor from disclosing company information. Also ensure that contracts include right-to-audit clauses allowing you to audit vendor activities that are critical to your company. Review a sample of contracts for evidence that these clauses are in place where applicable.
Review processes for monitoring the performance and providing oversight of existing third-party service providers. For a sample of existing vendors, look for evidence that they are being monitored for compliance with SLAs and that they are performing the responsibilities defined in the contract.
Most companies employ some level of outsourcing and contract labor to supplement their internal workforce. Also, some companies allow third-party vendors to have a degree of logical access to purchased systems for troubleshooting and support purposes. Because these personnel are not employees of the company, they are less likely to have a personal investment in the company's success or an awareness of the company's policies and culture. If their access to company information assets is not governed, and if expectations regarding their use of that access are not communicated, it is more likely that company information assets will be exposed unnecessarily or misused.
Ensure that policies require approval and sponsorship from an employee prior to a nonemployee obtaining logical access to company systems. If feasible, obtain a sample of nonemployee accounts, and validate that they have appropriate approval and sponsorship.
Review and evaluate processes for communicating company policies (including IT security policies) to nonemployees prior to granting them system access. Look for evidence that this communication has taken place. For example, if all nonemployees are required to sign a statement that they have read and agree to the policies, pull a sample of nonemployees and obtain copies of these agreements.
Review and evaluate processes for removing logical access from nonemployees when they have ceased to work with your company or otherwise no longer need access. Consider obtaining a sample of current nonemployee accounts and validating that those nonemployees are still working with your company and still have a need for their current level of access.
Ensure that nondisclosure agreements (NDAs) are signed by nonemployees in order to legally protect your company from inappropriate use of company data. Pull a sample of nonemployee accounts, and obtain a copy of the NDAs for those accounts.
Ensure that consideration has been given to identifying data that should not be accessed by nonemployees and activities that should not be performed by nonemployees. For example, your company may decide that access to certain levels of financial data never should be granted to nonemployees. Or it may decide that nonemployees never should be granted system administration duties. The answer will depend on your company's industry and philosophies; however, an evaluation process should take place, and the results of that evaluation should be documented in company policy and enforced. This evaluation should be part of the data classification effort described in step 10. This evaluation should drive the restrictions on nonemployee logical access.
Using software illegally can lead to penalties, fines, and lawsuits. It is increasingly easy for company employees to download software from the Internet. If companies do not develop processes for preventing or tracking this activity (as well as tracking the use of company licenses for purchased software), they can find themselves subject to software vendor audits without the ability to properly account for the company's use of the vendor's software.
Look for evidence that the company maintains a list of enterprise software licenses (e.g., Microsoft Office, ERP application accounts, etc.) and has developed a process for monitoring use of those licenses and complying with the terms of agreement. Determine how decentralized (nonenterprise) licenses are monitored and tracked. This would include software purchased by employees and placed on their company computers, as well as software downloaded from the Internet. Test the effectiveness of the method used at your company either by performing your own scans on a sample of computers or by reviewing evidence from the company's processes.
Allowing remote access to a network basically results in that network being extended beyond its normal confines, bypassing normal perimeter controls such as firewalls. If strong controls are not implemented over this access, it can result in inappropriate access to the network and to the network being compromised.
Ensure that a user ID and strong password are required for remote access and that these credentials are transmitted over secure (e.g., encrypted) communication channels.
Determine whether approval processes are in place for granting remote access, especially for nonemployees. Pull a sample of users with remote access, and look for evidence of approval. Also evaluate processes for removing dial-up and VPN remote access accounts when employees leave the company. Pull a sample of users with remote access, and ensure that they are still active employees.
Evaluate controls for ensuring that dedicated external connections to business partners are removed when no longer needed. Pull a sample of current connections, and by means of interviews and review of documentation, determine whether they are still legitimately necessary.
Evaluate controls for ensuring that unauthorized connections cannot be made to the network and/or for detecting them if they are. Evaluate controls for ensuring that unauthorized modems or VPN connection points cannot be placed on the network and/or for detecting them if they are.
Ensure that policies provide minimum security requirements that should be met by all machines accessing the network remotely. This should include requirements for operating system patch level and antivirus protection. Look for preventive or detective controls that enforce these requirements.
Ensure that machines that are remotely accessing the network are not permitted to be dual-homed, which would bridge networks. This should be enforced technically where possible and by explicit agreement otherwise.
Hiring procedures ensure that employees are submitted to drug screens and background checks, where local laws permit, prior to beginning work within an organization. Termination procedures ensure that access to company systems and facilities is revoked before a disgruntled employee can cause damage and that company property is returned. Inadequate hiring or termination procedures would expose the company to sabotage or abuse of privileges that could result in an information security compromise.
Review HR policies and procedures for the hiring and termination of employees. Ensure that hiring procedures include background checks, drug screens, and confidentiality agreements. Ensure that termination procedures include physical and logical access revocation, return of company-owned equipment, and where appropriate, supervision while the former employee collects his or her belongings.
Asset management is the controlling, tracking, and reporting of organizational assets to facilitate accounting for the assets. Without effective asset management, the company will be subject to the increased expense of duplicate equipment in situations where equipment is available but unaccounted for. Additionally, theft of equipment that is not tracked likely would go unnoticed. In the context of this step, the assets being referred to are computer hardware, such as desktops, laptops, servers, etc.
Review and evaluate the company's asset management policies and procedures, and ensure that they encompass the following:
Asset procurement process. Ensure that this process requires appropriate approvals prior to the purchase of hardware.
Asset tracking. Ensure that the company is using asset tags and has an asset management database.
Current inventory of all equipment. Ensure that there is an inventory containing the asset number and location of all hardware. Ensure that there is an effective mechanism for keeping this inventory up to date. A sample of asset tags also should be inspected visibly and tied back to the inventory.
Asset move and disposal procedures. Ensure that unused equipment is stored in a secure manner. Also ensure that data are erased properly from equipment prior to its disposal.
Configuration change management ensures that system changes are controlled and tracked in order to reduce the risk of system outages. It includes planning, scheduling, applying, and tracking changes to systems for the purpose of reducing the risk of those changes to the environment.
Change activities can fall into two areas: hardware and software (including operating-system-level changes). Ensure that the configuration-management procedures include processes for the following:
Requesting changes (including processes for end users to request changes)
Determining the specifics of what should change
Prioritizing and approving proposed changes
Scheduling approved changes
Testing and approving changes prior to implementation
Communicating planned changes prior to implementation
Rolling back (removing) changes that don't work as expected after implementation
Also review change-control documentation to verify that changes are fully documented, approved, and tracked. Approvals should incorporate a risk assessment and typically are given by a committee made up of stakeholders. You should be able to obtain a sample of change-control requests, as well as other configuration management documentation, from IT management.
Media controls ensure that information stored on data-storage media remains confidential and is protected from premature deterioration or destruction. Inadequate media transportation, storage, reuse, and disposal policies and procedures expose organizations to possible unauthorized disclosure or destruction of critical information. One increasingly common type of security incident is the loss of backup media in transit by third-party carriers. A number of high-profile companies have fallen victim to this threat in recent years, having incurred losses owing to legal actions, reputation damage, and incident response costs.
Computer media, including, but not limited to, backup tapes, CDs and DVDs, hard disks, USB jump drives, and floppy disks, must be strictly controlled to ensure data privacy. Since backup operators, computer technicians, system administrators, third-party carriers, and even end users handle storage media, media policies and procedures should address these disparate roles. When auditing media control policies and procedures, you should look for the following:
Requirements for sensitive information to be encrypted prior to transporting it through a third-party carrier
Requirements for magnetic media to be digitally shredded or degaussed prior to reuse or disposal
Requirements for optical and paper media to be physically shredded prior to disposal
Requirements for users to be trained adequately on how to store and dispose of computer media, including jump drives
Requirements for computer media to be stored in a physically secure, temperature-controlled, and dry location to prevent damage to the media
You can obtain this information through the review IT policies, procedures, and security awareness training documents, as well as user interviews.
Anticipating and monitoring the capacity of data center facilities, computer systems, and applications are critical parts of ensuring system availability. When companies neglect these controls, they often experience system outages and data loss.
Capacity management is a core IT operations function. When auditing this area, review for the following:
Selected architecture documents to ensure that systems and facilities are designed to anticipated capacity requirements
Systems monitoring procedures, paying particular attention to capacity thresholds
System monitoring logs to determine the percentage of systems that are approaching or exceeding capacity thresholds
System availability reports to ensure that system capacity issues are not causing undue downtime.
Since capacity management is addressed most often by the groups responsible for data centers, applications, or system management, specific procedures should be addressed within these areas.
If a critical IT process at your company is centralized, it is a good candidate for being reviewed during an entity-level controls audit. By auditing it once at the company level, you will be able to rely on the results of that audit when performing audits of other IT systems and processes.
By identifying those baseline IT controls, you should be able to reduce testing during other audits and avoid repetition. For example, if your company has only one production data center, you can test the physical security and environmental controls of that data center once. Then, as you perform audits of individual systems that are housed in that data center, instead of auditing the physical security and environmental controls for each of those systems (which would be very repetitive because they're all in the same place), you can just reference your entity-level audit of those topics and move on. Also, by performing audits of centralized processes, you will have an understanding of potential compensating controls in the overall IT environment that may mitigate concerns you have with lower-level controls.
Review the topics covered in the other chapters in Part II of this book, and consider whether any of those areas are centralized at your company. Those topics are candidates for an entity-level controls review. Below are some likely candidates:
Data center physical security and environmental controls (see Chapter 4)
System monitoring (e.g., performance and availability) and incident reporting (see Chapter 4)
Disaster-recovery planning (see Chapter 4)
Backup processes (see Chapter 4)
Network security and management (see Chapter 5)
Windows system administration processes (e.g., account management, security monitoring) (see Chapter 6)
Security of baselines used for deployment of new Windows systems (see Chapter 6)
Virus protection (e.g., antivirus, patching, compliance checking) (see Chapter 6)
Unix/Linux system administration processes (e.g., account management, security monitoring, security patching) (see Chapter 7)
Security of baselines used for deployment of new Unix and Linux systems (see Chapter 7)
Software change controls for internally developed code (see Chapter 10)
Enterprise password and account management practices (see step 7 above for guidance)