- IT Organizational Structure
- Evaluating Hardware Acquisition, Installation, and Maintenance
- Evaluating Systems Software Development, Acquisition, Implementation, and Maintenance
- Evaluating Network Infrastructure Acquisition, Installation, and Maintenance
- The TCP/IP Protocol Suite
- Routers
- Internet, Intranet, and Extranet
- Evaluating IS Operational Practices
- Evaluating the Use of System Performance and Monitoring Processes, Tools, and Techniques
- Exam Prep Questions
This chapter is from the book
This chapter is from the book
This chapter is from the book
Evaluating Hardware Acquisition, Installation, and Maintenance
A significant part of the information architecture is the computing hardware. These systems include the following:
-
Processing components—The central processing unit (CPU). The CPU contains the electrical/electronic components that control or direct all operations in the computer system. A majority of devices within the information architecture are CPUs (supercomputers, mainframes, minicomputer, microcomputer, laptops, and PDAs).
-
Input/output components—The I/O components are used to pass instructions or information to the computer and to generate output from the computer. These types of devices include the keyboard, the mouse (input), and monitors/terminal displays.
Computers logically fall into categories and differ depending on the processing power and size for the organization. The following are the basic categories for computers:
-
Supercomputers—These types of computers have a large capacity of processing speed and power. They are generally used for complex mathematical calculations. Supercomputers generally perform a small number of very specific functions that require extensive processing power (decryption, modeling, and so on). Supercomputers differ from mainframes in that mainframes can use diverse concurrent programs.
-
Mainframes—Mainframes are large general-purpose computers that support large user populations simultaneously. They have a large range of capabilities that are controlled by the operating system. A mainframe environment, as opposed to a client/server environment, is generally more controlled with regard to access and authorization to programs; the entire processing function takes place centrally on the mainframe. Mainframes are multiuser, multithreading, and multiprocessing environments that can support batch and online programs.
-
Minicomputer—Minicomputers are essentially smaller mainframes. They provide similar capabilities but support a smaller user population (less processing power).
-
Microcomputer (personal computers)—Microcomputers are primarily used in the client/server environment. Examples include file/print servers, email servers, web servers, and servers that house database- management systems. Individual workstations also fall into the microcomputer category and are used for word processing, spreadsheet applications, and individual communications (email). Microcomputers are generally inexpensive because they do not have the processing power of larger minicomputers or mainframes.
-
Notebook/laptop computers—Notebook and laptop computers are portable and allow users to take the computing power, applications, and, in some cases, data with them wherever they travel. Notebooks and laptops today have as much computing power as desktop workstations and provide battery power when traditional power is not available. Because of the mobile nature of notebook and laptop computers, they are susceptible to theft. Theft of a laptop computer is certainly the loss of a physical asset, but it also can include the loss of data or unauthorized access to the organization's information resources.
-
Personal digital assistants (PDAs)—PDAs are handheld devices and generally have significantly less processing power, memory, and applications than notebook computers. These devices are battery powered and very portable (most can fit into a jacket pocket). Although the traditional use of a PDA is for individual organization, including the maintenance of tasks, contacts lists, calendars, and expense managers, PDAs are continually adding functionality. As of this writing, a significant number of PDAs provide wireless network access and have either commercial off-the-shelf software or custom software that enables users to access corporate information (sales and inventory, email, and so on). Most PDAs use pen (stylus)–based input instead of the traditional keyboard, effected by using either an onscreen keyboard or handwriting recognition. PDAs are synchronized with laptop/desktop computers through serial interfaces through the use of a cradle or wireless networking (802.11 or Bluetooth). The synchronization can be user initiated or automated, based on the needs of the user.
Earlier in this section, we discussed some of the attributes of computing systems, including multiprocessing, multitasking, and multithreading. These attributes are defined as follows:
-
Multitasking—Multitasking allows computing systems to run two or more applications concurrently. This process enables the systems to allocate a certain amount of processing power to each application. In this instance, the tasks of each application are completed so quickly that it appears to multiple users that there are no disruptions in the process.
-
Multiprocessing—Multiprocessing links more than one processor (CPU) sharing the same memory, to execute programs simultaneously. In today's environment, many servers (mail, web, and so on) contain multiple processors, allowing the operating system to speed the time for instruction execution. The operating system can break up a series of instructions and distribute them among the available processors, effecting quicker instruction execution and response.
-
Multithreading—Multithreading enables operating systems to run several processes in rapid sequence within a single program or to execute (run) different parts, or threads, of a program simultaneously. When a process is run on a computer, that process creates a number of additional tasks and subtasks. All the threads (tasks and subtasks) can run at one time and combine as a rope (entire process). Multithreading can be defined as multitasking within a single program.
Risks and Controls Relating to Hardware Platforms
In aligning the IT strategy with the organizational strategy, IT provides solutions that meet the objectives of the organization. These solutions must be identified, developed, or acquired. As an IS auditor, you will assess this process by reviewing control issues regarding the acquisition, implementation, and maintenance of hardware. Governance of the IT organization and corresponding policies will reduce the risk associated with acquisition, implementation, and maintenance. Configuration management accounts for all IT components, including software. A comprehensive configuration-management program reviews, approves, tracks, and documents all changes to the information architecture. Configuration of the communications network is often the most critical and time-intensive part of network management as a whole. Software development project management involves scheduling, resource management, and progress tracking. Problem management records and monitors incidents and documents them through resolution. The documentation created during the problem-management process can identify inefficient hardware and software, and can be used as a basis for identifying acquisition opportunities that serve the business objectives. Risk management is the process of assessing risk, taking steps to reduce risk to an acceptable level (mitigation) and maintaining that acceptable level of risk. Risk identification and management works across all areas of the organizational and IT processes.
CAUTION
A configuration-management audit should always verify software licensing for authorized use.
The COBIT framework provides hardware policy areas for IT functions. These policy areas can be used as a basis for control objectives to ensure that the acquisition process is clearly defined and meets the needs of the organization. The COBIT areas address the following questions:
Acquisition—How is hardware acquired from outside vendors?
Standards—What are the hardware compatibility standards?
Performance—How should computing capabilities be tested?
Configuration—Where should client/servers, personal computers, and others be used.
-
Service providers—Should third-party service providers be used?
One of the key challenges facing IT organizations today is the speed of new technology releases in the marketplace and detailed baseline documentation for their organizations. IT organizations need a process for documenting existing hardware and then maintaining that documentation. This documentation supports the acquisition process and ensures that new technologies that meet the business objectives can be thoroughly tested to ensure that they are compatible with the existing information architecture.
Contained within the COBIT framework regarding hardware and software acquisition, the auditor will consider the control objectives defined in Table 3.1.
Table 3.1 Acquisition Control Objectives
|
Identify Automated Solutions |
Control Objective |
|
1.1 Definition of Information Requirements |
The organization’s system development life cycle methodology should require that the business requirements for the existing system and the proposed new or modified system (software, data, and infrastructure) are clearly defined before a development, implementation, or modification project is approved. The system development life cycle methodology should specify the solution’s functional and operational requirements, including perfor-mance, safety, reliability, compatibility, security, and legislation. |
|
1.2 Formulation of Alternative Courses of Action |
The organization’s system development life cycle should stipulate that alternative courses of action should be analyzed to satisfy the business requirements established for a proposed new or modified system. |
|
1.3 Formulation of Acquisition Strategy |
Information systems acquisition, development, and maintenance should be considered in the context of the organization’s IT long- and short-range plans. The organization’s system development life cycle methodology should provide for a software acquisition strategy plan defining whether the software will be acquired off-the-shelf; developed internally, through contract, or by enhancing the existing software; or developed through a combination of these. |
|
1.4 Third-Party Service Requirements |
The organization’s system development life cycle methodology should require an evaluation of the requirements and specifications for an RFP (request for proposal) when dealing with a third-party ser-vice vendor. |
|
1.5 Technological Feasibility Study |
The organization’s system development life cycle methodology should require an examination of the technological feasibility of each alternative for satisfying the business requirements established for the development of a proposed new or modified information system project. |
|
1.6 Economic Feasibility Study |
In each proposed information systems development, implementation, and modification project, the organization’s system development life cycle methodology should require an analysis of the costs and benefits associated with each alternative being considered for satisfying the established business requirements. |
|
1.7 Information Architecture |
Management should ensure that attention is paid to the enterprise data model while solutions are being identified and analyzed for feasibility. |
|
1.8 Risk Analysis Report |
In each proposed information system development, implementation, or modification project, the organization’s system development life cycle methodology should require an analysis and documentation of the security threats, potential vulnerabilities and impacts, and the feasible security and internal control safeguards for reducing or eliminating the identified risk. This should be realized in line with the overall risk-assessment framework. |
|
1.9 Cost-Effective Security Controls |
Management should ensure that the costs and benefits of security are carefully examined in monetary and nonmonetary terms, to guarantee that the costs of controls do not exceed benefits. The decision requires formal management sign-off. All security requirements should be identified at the requirements phase of a project and should be justified, agreed to, and documented as part of the overall business case for an information system. Security requirements for business continuity management should be defined to ensure that the proposed solution supports the planned activation, fallback, and resumption processes. |
|
1.10 Audit Trails Design |
The organization’s system development life cycle methodology should state that adequate mechanisms for audit trails must be available or developed for the solution identified and selected. The mechanisms should provide the capability to protect sensitive data (for example, user IDs) against discovery and misuse. |
|
1.11 Ergonomics |
Management should ensure that the IT function adheres to a standard procedure for identifying all potential system software programs, to satisfy its operational requirements. |
|
1.13 Procurement Control |
Management should develop and implement a central procurement approach describing a common set of procedures and standards to be followed in the procurement of information technology–related hardware, software, and services. Products should be reviewed and tested before their use and the financial settlement. |
|
1.14 Software Product Acquisition |
Software product acquisition should follow the organization’s procurement policies. |
|
1.15 Third-Party Software Maintenance |
Management should require that before licensed software is acquired from third-party providers, the providers have appropriate procedures to validate, protect, and maintain the software product’s integrity rights. Consideration should be given to the support of the product in any maintenance agreement related to the delivered product. |
|
1.16 Contract Application Programming |
The organization’s system development life cycle methodology should require that the procurement of contract programming services be justified with a written request for services from a designated member of the IT function. The contract should stipulate that the software, documentation, and other deliverables are subject to testing and review before acceptance. In addition, it should require that the end products of completed contract programming services be tested and reviewed according to the related standards by the IT function’s quality assurance group and other concerned parties (such as users and project managers) before payment for the work and approval of the end product. Testing to be included in contract specifications should consist of system testing, integration testing, hardware and component testing, procedure testing, load and stress testing, tuning and performance testing, regression testing, user acceptance testing, and, finally, pilot testing of the total system, to avoid any unexpected system failure. |
|
1.17 Acceptance of Facilities |
Management should ensure that an acceptance plan for facilities to be provided is agreed upon with the supplier in the contract. This plan should define the acceptance procedures and criteria. In addition, acceptance tests should be performed to guarantee that the accommodation and environment meet the requirements specified in the contract. |
|
1.18 Acceptance of Technology |
Management should ensure that an acceptance plan for specific technology to be provided is agreed upon with the supplier in the contract. This plan should define the acceptance procedures and criteria. In addition, acceptance tests provided for in the plan should include inspection, functionality tests, and workload trials. |
The selection of computer hardware requires the organization to define specifications for outside vendors. These specifications should be used in evaluating vendor-proposed solutions. This specification is sometimes called an invitation to tender (ITT) or a request for proposal (RFP).
Per ISACA, the portion of the ITT pertaining to hardware should include the following:
-
Information-processing requirements
-
Major existing application systems and future application systems
-
Workload and performance requirements
-
Processing approaches (online/batch, client/server, real-time databases, continuous operation)
-
Hardware requirements
-
CPU speed
-
Peripheral devices (sequential devices, such as tape drives; direct-access devices, such as magnetic disk drives, printers, CD-ROM drives, and WORM drives)
-
Data-preparation/input devices that accept and convert data for machine processing
-
Direct-entry devices (terminal, point-of-sale terminals, or automated teller machines)
-
Networking capability (Ethernet connections, modems, and ISDN connections)
-
System software applications
-
Operation systems software (current version and any required upgrades)
-
Compilers
-
Program library software
-
Database-management software and programs
-
Communication software
-
Access-control software
-
Support requirements
-
System maintenance (for preventative, detective [fault reporting], or corrective purposes)
-
Training (user and technical staff)
-
Backups (daily and disaster)
-
Adaptability requirements
-
Hardware/software upgrade capabilities
-
Compatibility with existing hardware/software platforms
-
Changeover to other equipment capabilities
-
Constraints
-
Existing hardware capacity
-
Deliver dates
-
Conversion requirements
-
Test time for the hardware/software
-
System-conversion facilities
-
Cost/pricing schedule
The acquisition of hardware might be driven by requirements for a new software acquisition, the expansion of existing capabilities, or the scheduled replacement of obsolete hardware. With all these events, senior management must ensure that the acquisition is mapped directly to the strategic goals of the organization. The IT steering committee should guide information systems strategy—and, therefore, that its acquisitions—align with the organization's goals.
In addition, the senior managers of the IT steering committee should receive regular status updates on acquisition projects in progress, the cost of projects, and issues that impact the critical path of those projects. The IT steering committee is responsible for reviewing issues such as new and ongoing projects, major equipment acquisitions, and the review and approval of budget; however, the committee does not usually get involved in the day-to-day operations of the IS department.
The IT organization should have established policies for all phases of the system development life cycle (SDLC) that controls the acquisition, implementation, maintenance, and disposition of information systems. The SDLC should include computer hardware, network devices, communications systems, operating systems, application software, and data. These systems support mission-critical business functions and should maximize the organization’s return on investment. The combination of a solid governance framework and defined acquisition process creates a control infrastructure that reduces risk and ensures that IT infrastructure supports the business functions.
As an IS auditor, you will look for evidence of a structured approach to hardware acquisition, implementation, and maintenance. These include written acquisition policies and outline the process for feasibility studies, requirements gathering, and the approval process of the IT steering committee. After hardware is procured, the IT organization must have a defined project-management and change-control process to implement the hardware. All hardware acquired must fall under existing maintenance contracts and procedures, or contracts must be acquired and procedures updated to reflect the new hardware. The hardware should be tested according to written test plans before going into production, and the hardware should be assigned to the appropriate functional areas (such as systems administration) to ensure that production responsibility is clearly defined. The acquired hardware, whether a replacement or new to the IT infrastructure, should be secured (physical, logical) and added to the business continuity plan.
Change Control and Configuration Management Principles for Hardware
The change-control and configuration-management processes detail the formal documented procedures for introducing technology changes into the environment. More specifically, change control ensures that changes are documented, approved, and implemented with minimum disruption to the production environment and maximum benefits to the organization.
During the normal operation of the IT infrastructure, there will be changes to hardware and software because of normal maintenance, upgrades, security patches, and changes in network configurations. All changes within the infrastructure need to be documented and must follow change control procedures. In the planning stages the party responsible for the changes (such as end users, line managers or the network administrator) should develop a change-control request. The request should include all systems affected by the change, the length of resources required to implement the change (time and money), and a detailed plan. The plan should include what specific steps will be taken for the change and should include test plans and back-out procedures, in case the change adversely affects the infrastructure. This request should go before the change-control board that votes on the change and normally provides a maintenance window in which the change is to be implemented. When the change is complete and tested, all documentation and procedures that are affected by the change should be updated. The change-control board should maintain a copy of the change request and its review of the implementation of the change.
The change-control board provides critical oversight for any production IT infrastructure. This board ensures that all affected parties and senior management are aware of both major and minor changes within the IT infrastructure. The change-management process establishes an open line of communication among all affected parties and allows those parties and subject matter experts (SMEs) to provide input that is instrumental in the change process.
In addition to change and configuration control, the IT organization is responsible for capacity planning. A capacity plan and procedures should be developed to ensure the continued monitoring of the network and associated hardware. Capacity planning ensures that the expansion or reduction of resources takes place in parallel with the overall organizational growth or reduction. The audit procedures should include review of the following:
Hardware performance-monitoring plan—Includes a review of problem logs, processing schedules, system reports, and job accounting reports.
Problem log review—The problem log assists in identifying hardware malfunctions, operator actions, or system resets that negatively affect the performance of the IT infrastructure. The IT organization should regularly monitor the problem log to detect potential IT resource capacity issues.
-
Hardware availability and performance reports—Review and ensure that the services required by the organization (CPU utilization, storage utilization, bandwidth utilization, and system uptime) are available when needed and that maintenance procedures do not negatively impact the organization’s operations.
The IT organization should work closely with senior management to ensure that the capacity plan will meet current and future business needs, and to implement hardware-monitoring procedures to ensure that IT services, applications, and data are available. The IT organization should regularly monitor its internal maintenance, job scheduling, and network management to ensure that they are implemented in the most efficient and effective manner.