IS Auidt and Infrastructure MGT
IS Auidt and Infrastructure MGT
Information systems are the lifeblood of any large business. As in years past, computer systems do not
merely record business transactions, but actually drive the key business processes of the enterprise. In
such a scenario, senior management and business managers do have concerns about information
systems. The purpose of IS audit is to review and provide feedback, assurances and suggestions.
These concerns can be grouped under three broad heads:
1. Availability: Will the information systems on which the business is heavily dependent be
available for the business at all times when required? Are the systems well protected against all
types of losses and disasters?
2. Confidentiality: Will the information in the systems be disclosed only to those who have a
need to see and use it and not to anyone else?
3. Integrity: Will the information provided by the systems always be accurate, reliable and
timely? What ensures that no unauthorized modification can be made to the data or the software in the
systems?
Elements of IS Audit
An information system is not just a computer. Today’s information systems are complex and have many
components that piece together to make a business solution. Assurances about an information system can
be obtained only if all the components are evaluated and secured. The proverbial weakest link is the total
strength of the chain. The major elements of IS audit can be broadly classified:
1. Physical and environmental review—This includes physical security, power supply, air
conditioning, humidity control and other environmental factors.
2. System administration review—This includes security review of the operating systems, database
management systems, all system administration procedures and compliance.
3. Application software review—The business application could be payroll, invoicing, a web-
based customer order processing system or an enterprise resource planning system that actually runs
the business. Review of such application software includes access control and authorizations,
validations, error and exception handling, business process flows within the application software and
complementary manual controls and procedures. Additionally, a review of the system development
lifecycle should be completed.
4. Network security review—Review of internal and external connections to the system,
perimeter security, firewall review, router access control lists, port scanning and intrusion detection
are some typical areas of coverage.
5. Business continuity review—This includes existence and maintenance of fault tolerant and
redundant hardware, backup procedures and storage, and documented and tested disaster
recovery/business continuity plan.
6. Data integrity review—The purpose of this is scrutiny of live data to verify adequacy of
controls and impact of weaknesses, as noticed from any of the above reviews. Such substantive testing
can be done using generalized audit software (e.g., computer assisted audit techniques).
All these elements need to be addressed to present to management a clear assessment of the system.
For example, application software may be well designed and implemented with all the security
features, but the default super- user password in the operating system used on the server may not have
been changed, thereby allowing someone to access the data files directly. Such a situation negates
whatever security is built into the application. Likewise, firewalls and technical system security may
have been implemented very well, but the role definitions and access controls within the application
software may have been so poorly designed and implemented that by using their user IDs, employees
may get to see critical and sensitive information far beyond their roles.
It is important to understand that each audit may consist of these elements in varying measures; some
audits may scrutinize only one of these elements or drop some of these elements. While the fact
remains that it is necessary to do all of them, it is not mandatory to do all of them in one assignment.
The skill sets required for each of these are different. The results of each audit need to be seen in
relation to the other. This will enable the auditor and management to get the total view of the issues
and problems. This overview is critical.
Risk-based Approach
Every organization uses a number of information systems. There may be different applications for
different functions and activities and there may be a number of computer installations at different
geographical locations.
The auditor is faced with the questions of what to audit, when and how frequently. The answer to this
is to adopt a risk-based approach.
While there are risks inherent to information systems, these risks impact different systems in different
ways. The risk of nonavailability even for an hour can be serious for a billing system at a busy retail
store. The risk of unauthorized modification can be a source of frauds and potential losses to an
online banking system. A batch processing system or a data consolidation system may be relatively
less vulnerable to some of these risks. The technical environments on which the systems run also may
affect the risk associated with the systems.
The steps that can be followed for a risk-based approach to making an audit plan are:
1. Inventory the information systems in use in the organization and categorize them.
2. Determine which of the systems impact critical functions or assets, such as money,
materials, customers, decision making, and how close to real time they operate.
3. Assess what risks affect these systems and the severity of impact on the business.
4. Rank the systems based on the above assessment and decide the audit priority,
resources, schedule and frequency.
The auditor then can draw up a yearly audit plan that lists the audits that will be performed during the
year, as per a schedule, as well as the resources required.
It always is a good practice to have a formal audit commencement meeting with the senior
management responsible for the area under audit to finalize the scope, understand the special
concerns, if any, schedule the
dates and explain the methodology for the audit. Such meetings get senior management involved, allow
people to
meet each other, clarify issues and underlying business concerns, and help the audit to be conducted
smoothly.
Similarly, after the audit scrutiny is completed, it is better to communicate the audit findings and
suggestions for corrective action to senior management in a formal meeting using a presentation. This
will ensure better understanding and increase buy-in of audit recommendations. It also gives auditees
an opportunity to express their viewpoints on the issues raised. Writing a report after such a meeting
where agreements are reached on all audit issues can greatly enhance audit effectiveness.
Key Challenge
IS audit often involves finding and recording observations that are highly technical. Such technical
depth is required to perform effective IS audits. At the same time it is necessary to translate audit
findings into vulnerabilities and businesses impacts to which operating managers and senior management
can relate. Therein lies a main challenge of IS audit.
The term infrastructure describes the structures required for the operation of a
physical facility or business operation
to operate, manage and maintain an end-to-end ICT infrastructure that facilitates the delivery of
the ICT services to the business, and that meets all its agreed requirements and targets
to ensure that the ICT infrastructure is reliable, robust, secure, consistent and facilitates the
efficient and effective business processes of the organization.
DELIVERABLES
To improve system availability, first identify all the system components that work together to enable a
user's application to run. A chain is only as strong as its weakest link. If your system has one component
that is prone to failure, your entire system is prone to failure
• Host or server—. This is the portion of the system where most data is stored or processed. The server
fulfills transaction requests sent to it and sends the results to the requestor of the transaction. For
example, in a bank Automated Teller Machine (ATM) system, the host is usually the bank mainframe
system, or large server, that manages client bank accounts and transactions.
• Client—. This is the component that makes a request from the server. In our ATM example, the client
is the ATM machine.
• Network—. This is the component that allows the client to communicate with the server, and vice
versa. In our ATM example, the network is typically a combination of a private network, the public
telephone network and all associated communication equipment.
For each of these areas, examine all components: hardware, software, environment, processes and
procedures, and personnel.
Hardware is the physical equipment making up the system. It includes, but is not limited to, the
following:
• Central processing unit—. The device that controls the operation of the computer system or other
intelligent equipment
• Storage devices—. Data repositories, whether permanent or volatile media, such as memory and hard
disks
• Input devices—. Components for receiving commands or data from users or other equipment, for
example, keyboards, mice, and serial ports
• Output devices—. Components for presenting data to the user, such as monitors, speakers, and printers
• Cables—. Often neglected but crucial to the reliability of any computer system
Software consists of the programs running in the system that enable it to perform its functions,
including:
• Firmware—. Software embedded in hardware, acting as the interface between hardware resources and
the operating system. In PCs, this software is also called the Basic Input/Output System (BIOS).
• Operating system—. Core programs that allow applications to run on a computer without directly
interfacing with the computer's hardware components. Common operating systems include Windows
95/98, Windows 2000, UNIX, Linux, OS/400 and OS/390.
• Utilities—. Software that performs housekeeping and system control functions. Normally, system
administrators or maintenance staffers use these programs.
• Programming software—. Software that supports the creation of applications, including languages
such as C++, Java and COBOL, and development tools such as Microsoft Visual Studio.
• Applications—. Programs designed to perform user-specified tasks or operations. These programs may
be written by the company (in-house applications) or purchased from a software vendor (off- the-shelf or
shrink-wrapped software).
• Power—. Including automatic voltage regulators, uninterruptible power supplies, generators, surge
suppressors, and lightning arrestors
2. Processes and procedures are the operational activities needed to run the system. These include, but
are not limited to:
• Activation—. Including power up, system initialization, application startup, and verification of system
activation
• Operation—. Including resource management, input/output control, job control, and network
management
• System support staff—. Including operators, system administrators, programmers, technical support
professionals, and others
Several approaches are available for reducing the risks associated with these critical components:
• Reduce outage frequency—. Look for ways to prevent outages from happening to that critical
component, thereby increasing its reliability.
• Minimize outage duration—. If outages cannot be entirely avoided, find ways to recover immediately
from them, thereby improving recoverability. If recovery is impossible, ensure that the component can
be immediately repaired. In other words, improve serviceability.
• Minimize outage scope—. Minimize the parts of a system that are impacted by an outage.
• Prevent future outages—. Reduce the potential for users and other external factors to affect system
availability, and make it easier to maintain the system's health by addressing its manageability.
• Reliability—. The ability to perform under stated conditions for a stated period of time
• Recoverability—. The ability to easily bypass and recover from a component failure
• Serviceability—. The ability to perform effective problem determination, diagnosis, and repair
• Manageability—. The ability to create and maintain an environment that limits the negative impact
people may have on the system.
To devise an effective plan to address system availability, you must first understand the entire system,
and how each component affects overall system availability
Infrastructure Management is the combination of processes, data, tools, and organization needed to
manage a system efficiently and effectively. Processes deal with how to perform the task. Data refers to
the information required to perform the process. Tools are the equipment needed to perform the
processes. Organization refers to the people that support the process and how they are set up to do so.
Infrastructure management is not merely a set of procedures for running a system, rather, it integrates all
four elements mentioned above. We have seen too many IT organizations come up with exhaustively
detailed procedures, yet fail because they have not tackled all four key elements. To illustrate, let us
review examples of implementations that lacked one or more of these elements:
• Process element ignored—. Many help desks have no escalation procedures. Obviously, this leads to
many complaints by users (and their management), when severe problems do not receive appropriate
attention and support. To add insult to injury, in many cases, IT management only becomes aware of
these problems when users complain.
• Data element ignored—. Often, help desks fail to adequately identify the data they need to gather from
users. One help desk had more-than-adequate staffing, and clear procedures for handling calls. However,
nobody quite knew what information to request, and there was no standard form for recording details.
Whenever the caller's problem was passed to technical support, the support person usually had to call the
user again for more information. Problem resolution was delayed, productivity suffered, and users were
dissatisfied. Eventually, users decided that calling the centralized help desk was a waste of time, and
began calling support specialists directly.
• Tool element ignored—. This is the most common systems management mistake IT organizations
make— they erroneously believe you can simply throw bodies at the problem. One organization's help
desk was in total disarray because the help desk staff was demoralized. We discovered they had no
computerized means of recording and tracking calls — they were simply using a paper-based logbook.
When management asked for weekly reports, the help desk staff needed a whole day simply to sort and
filter their call records. Adding staff simply led to more paper shuffling, and even more lost call
information.
• Organization element ignored—. Many IT organizations seem to think that you can have an effective
help desk simply by seating people in front of a phone to answer user calls. They fail to recognize that it
is also important to organize the people making up the help desk. Organizing a help desk includes
identifying the appropriate staffing and skills requirements, creating clear reporting lines within the help
desk organization, and distributing responsibilities efficiently amongst the help desk staff.
Infrastructure Management
Infrastructure Management covers all aspects of an IT operation, from design and procurement of IT
equipment to its implementation, problem resolution, security, and much more. No matter how small the
computing resource, you need some form of infrastructure management discipline in order to preserve
system availability and maximize IT's value to your business.
To deploy the optimal systems management infrastructure, you must first thoroughly understand the
system you intend to manage. Knowing the technical aspects of your system is not enough. To design a
cost-effective, practical systems management infrastructure, consider the following points:
• How critical the system is to the business—. Greater criticality requires better systems management.
Consider how much of the business will be affected if the system is not available, in terms of lost
productivity, increased expenses, lost business opportunities, and erosion of customer satisfaction.
• Size of the system to manage—. Expect your systems management infrastructure to be increasingly
complex as system size increases. Size can be gauged in terms of the amount of resources (hardware,
software, people, etc.) being utilized, the amount of data being processed, or the number of users being
served.
• Complexity of the system—. The more complex a system, the more difficult it is to manage.
Complexity is a measure of the number of different resources interacting and working with each other. A
system can be complex for many reasons. For example, it may be complex because multiple operating
systems are in use, or because many types of users are sharing the same set of applications (e.g.,
customers, suppliers, managers, and staff). When multiple components are shared, there is greater risk of
dysfunction or reduced performance due to competition for scarce resources.
• Security requirements—. Systems and information assets that must be protected introduce new
complexities, such as access control and authentication, making them more difficult to manage.
• Skill sets—. When devising a systems management infrastructure, consider not only the skills of the IT
organization, but also those of users. As systems become increasingly distributed, management
responsibilities may also be distributed, and everyone involved is likely to need new skills and training.
• New technologies—. Consider forthcoming technologies and your organization's long term IT goals, so
the systems management infrastructure you design will not be made obsolete by rapid change.
• Standards—. You cannot deploy the right tools without considering corporate hardware and software
The traditional formula for effective Infrastructure management of any system, process, or activity
comprises five phases
This is the first and most important phase is setting objectives. Here, we determine the requirements of
the business and end users. Without properly determining what needs to be achieved, it is nearly
impossible to execute the other phases effectively. You must understand user objectives, so your plans
and activities support them.
In mature IT organizations, setting objectives often takes the form of defining Service Level Agreements
— enumerating the different services to be provided to the users, and corresponding attributes such as
performance, availability, and features.
Phase 2: Planning
In the planning phase, based on the objectives determined above, you define a plan to meet those
objectives. This plan usually covers the resources to be deployed, the activities to be done, the
measurements to be tracked, the tools to be used, and how the people are to be organized. Again, we
cannot overemphasize the need to address the four elements of systems management: process, data,
tools, and organization.
Phase 3: Execution In the execution phase, we actually perform the steps that were planned in Phase 2.
Phase 4: Measurement
In this phase, we record relevant data regarding the execution of the plan. Many different measures can
be tracked, falling into categories such as performance (speed of execution of a task), capacity (number
of concurrent tasks executed), failures (number of problems, frequency of problems, areas affected by
problems, number of repeat problems, number of detected problems, etc.), and recovery (problem
resolution time).
Phase 5: Control
The control phase gives the manager a means to correct the first four phases on an ongoing basis. In this
phase, you can verify whether the measurements meet your objectives. Here, you can reexamine and
refine your plans to more effectively support achievement of your objectives, and eliminate execution
problems. You can review how you execute your plans, to ensure that the execution has not, itself,
caused availability problems. Finally, you can reevaluate your objectives to determine whether they
should be upgraded or downgraded, to more effectively balance user requirements against what can
actually be achieved. Phase 5 never ends. Rather, it circles back to Phase 1, giving the manager
necessary information for revisiting phases one through four, and creating a closed-loop process. If you
skip any of these phases, your management system is likely to become obsolete quickly. The control
phase is crucial to ensuring that the system is consistently managed well. Many IT shops develop
excellent plans and objectives, and perform extremely well when they first implement their plans. Since
they fail to check on what is happening, however, changing technology, environment, and user
requirements leave their management systems behind.
Benefits
improved management and control of all ICT infrastructure events, alerts and alarms
faster detection, response and resolution of incidents and problems, with clear definition of
responsibilities
more resilient infrastructure with improved service availability with prevention of incident and
problem recurrences
a framework for financial management and long-term cost reduction
help with the provision and maintenance of quality IT services
clear definition of the roles and responsibilities of individuals within Operations
a systematic approach to the assessment of staff performance and promotion
a platform for the development of automation in Operations and the use of an operational bridge,
offering productivity and service quality improvements
improved supplier relationships
generation of a professional environment where the performance of everybody can rise to the
level of the best.