Loading presentation...

Present Remotely

Send the link below via email or IM


Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.


IT Audit training

No description

Nora Dha

on 4 January 2014

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of IT Audit training

Using something that you are as method of authentication. This usually refer to biometric. The popular biometric employed are
IT Audit training
Course Structure
Technical Skills
Process of Information System Audit
Governance and Management of IT
Information Systems Acquisition, Development, and Implementation
Information Systems Operations, Maintenance and Support
Protection of Information Assets

Soft Skills
Interview and Negotiations
Preparing reports and presenting to management
Process of Information System Audit
Content of this chapter includes the following key questions
Why do we need IS audit ?
What are risk and controls ?
What are the activities in IS audit ?

Governance and Management of IT
Information Systems Acquisition, Development, and Implementation
This is also refer as change management

The objective of this auditing area is to ensure that change which we are about to introduce to the production environment
satisfied the requester
minimal interruption
to the system.
Information Systems Operations, Maintenance and Support
Protection of Information asset
The objective of this domain is to ensure that the 3 critical factor for the information asset which are
Confidentiality (C)
Integrity (I)
Availability (A)
through infrastructure, environmental and process or procedures
Practice Question for chapter 5
15 minutes to complete 10 questions

Policy, Procedures and Guideline
ญ้ัญ้Physical security
Ensuring the security of our Information Asset
These are used for setting the tone of how we would like to be enforced, employed and perceived the security of our organization.
A statement which design to provide recommendation to complete a process or satisfied with the particular requirement
A document which written to support the compliance of the policy.
A Procedure is designed to describe Who, What, Where, When, and Why.

Usually "How"
are includes in the policy but could also be separated in another document such as "Work Instruction"
A statement of intent of management on a certain topic. The policy is used for supporting the company's strategy.

Since it is used for supporting the strategy hence the
employee are required to comply with it.
By definition, following a guideline is never mandatory. Guidelines are not binding and are not enforced.
Example of policies
IT Policy
IT Security Policy

Environmental Controls
How to prevent unauthorized person from walking to the servers
Control mechanisms
To prevent access we put locks (either electronic or mechanic) on to the door of the server rack or server room. The mechanism which we employed can be put into 3 categories
Something you know
Something you have
Something you are
Multi-factor authentication
As a specific approach for authentication may be susceptible to manipulation or attack hence to increase security level for the authentication a combination of approaches may be used.

The most typical example is the use of access card and pin code.
Something you know
You are using something that you know as a way to authenticate yourself
The most common is the pin code which is something that you remembered
Something you have
The fundamental thing used for unlock is the "key" but this could be other things such as challenge response card.
Something you are
Environment of the processing location is also a critical for effective operations
The 4 environmental elements that may affect the processing
One of the first thing that we concern when designing the data center. The processing of electronic device create heat. Level of heat would affect the performance of such device
Hot = slow performance
Cool = fast performance
Fire and Water
For Fire and water, it is obvious how it will effect the equipments and data.
Humidity do affect the processing as it contain traces of water in it.
High humidity = more likely to cause short circuit
Low humidity = more likely to create static
A good operation required stable power source
An unstable power could affect the processing where
Unusual level of voltage would create power surge which may damage the hardware or ultimately the data

Data Center's environmental controls
Temperature/ Humidity control system
Power supply
Fire / smoke detection and suppression
Water detection
Authentication mechanism can be susceptible to attack
Two side of the scale
One time pad
Why do we need IS audit ?
Considering your daily routines, which activity does not includes IT

It is clear that most of the things that you get involved with has some aspect of information technology.
What happen with this bank
A software update was applied on 19 June 2012 to RBS's CA-7 software which controls its payment processing system. It later emerged that the
update was corrupted
. Customers' wages, payments and other transactions were disrupted. Some customers were unable to withdraw cash using ATMs or to see bank account details. Others faced fines for late payment of bills because the system could not process direct debits.
Completions of new home purchases were delayed, and some people were stranded abroad. Another account holder was threatened with the discontinuation of their life support machine in a Mexican hospital, and one man was held in prison
Activities in Change Management
Identify the need for change
Prepare for Change
Develop business justification and obtain approval
Authorize the change request
Schedule, co-ordinate and implement the change
Verify and review the implemented change
Back out the change if unsuccessful
Close the change request and communicate with the affected party
Identify the need for change
Business Benefits should drive projects
Prepare for Change
Document in detail the change request.
Document the change test plan.
Document a change rollback plan, in case of change failure.
Write a step-by-step procedure that incorporates the change, the test plan, and the rollback plan.
Submit the change procedure in the form of a change request.
Develop business justification and obtain approval
Assess the impact, cost, and benefits associated with the change request.
Review and assess the risks and impacts of the change request, including regulatory impacts.
Authorize the change request
Authorize, reject, or request additional information on the change request.
Prioritize the change request with respect to others that are pending.
Schedule, co-ordinate and implement the change
Schedule and assign a change implementer.
Schedule and assign a change tester.
Test the change in a pre-production environment.
Communicate the change to stakeholders likely to be affected.
Approve the change for implementation.
Implement the change as requested.
Verify and review the implemented change
Was the change successful?
Was the change process followed?
What was the variance between the planned and implemented change?
Were internal control, operations, and regulatory compliance requirements maintained?
What were the lessons learned that can be use to improve the process?
Back out the change if unsuccessful
Even we have plan the migration well and sufficiently tested the change but risk that deployed change will be unsuccessful still exist (Although it is very low).

How will you restore your system back to normal operation ?
Close the change request and communicate with the affected party
After change has been successfully deployed we have to update the request either hard copy or electronic of the status.
Finally informed the requester or main stakeholder of the status.
The business case should provide the reasons for the project and answer the question

"Why should this project be undertaken"
Source of change
External environment (competitive market, stakeholders/shareholders, changing risks).
Regulatory environment.
Business objectives, goals, strategies, requirements, processes, and shifts in priorities.
Vendors (new products, upgrades, patches, and vulnerabilities).
Partners and suppliers.
Results of an audit, risk assessment, and other type of evaluation or assessment.
Operational problems.
Changes in performance or capacity requirements.
IS projects may be initiated from within any part of the organization, including the IS department.
Another half of the activities to go
Failed Change Management
Market Level
Client/customer/stakeholder level
Organizational level
Lost opportunities
Development projects are late and often over budget
Products and services do not perform as advertised or as
intended, or operate with flaws. This leads to low, unreliable
product or service quality. If customers can easily
switch to another provider, they will.
Unauthorized, untracked changes create potential exposure for fraud.
Business requirements can be misinterpreted with respect to required IT changes and thus poorly or inadequately implemented.
There is a lack of change prioritization, resulting in either working on the wrong things or working on something that is less important.
Patching systems causes large disruptions due to failed changes, resulting in outages, service impairment, rework, or unplanned work.
IT infrastructure level
An inability to track changes, report on change status and costs, and the presence of unauthorized changes.
Ad hoc, chaotic, urgent behavior requires regular intervention of technical experts/heroes; a high percentage of time is spent in “firefighting” mode on reactive tasks.
GTAG — Defining IT Change Management
Identify the need for the change.
The achievement of business benefits
should drive projects.
IS projects may be initiated from within any part of the organization, including the IS department.
Project Management
Application Development
Software Development Life Cycle (SDLC) -> AKA Waterfall technique
Phase 1
Phase 2
Temperature and Humidity Control
Temperature should be set
Function Point Analysis
Business Application
Business Application Development
Function Point Analysis
Developing a New system/ Change
Phase 3A-Design
Phase 3B-Selection
Phase 4A-Development
Phase 4B-Configuration
Phase 6-Post implementation
Phase 5-implementation
Phase 2-Requirements
Phase l-Feasibility
Phase 3A-Design
Based on the requirements defined, establish a baseline of system and subsystem specifications that describe
the parts of the system

Generally, the design also includes program and database specifications, and will address any security considerations
Phase 4A-Development
Use the design specifications to begin programming and formalizing supporting operational processes of the system

Various levels of testing also occur in this phase to verify and validate what has been developed.

This would generally include all
Unit and system testing
, as well as several iterations of
User acceptance testing
Phase 5-Implementation
Establish the actual operation of the new information system, with the final processes of user acceptance testing and user sign-off conducted in this phase.
Phase 6-Post implementation
Following the successful implementation of a new or extensively modified system, implement a formal process that assesses the adequacy of the system and projected cost-benefit or ROI measurements
Phase 1-Feasibility
Determine the strategic benefits of implementing the system either in productivity gains or in future cost avoidance
Identify and quantify the cost savings of a new system, and estimate a payback schedule for costs incurred in implementing the system
Considered and assessed intangible factors such as readiness of the business users and maturity of the business processes
Phase 2-Requirements
Define the problem or need that requires resolution and define the functional and quality requirements of the solution system.
This can be either a customized approach or vendor-supplied software package, which would entail following a defined and documented acquisition process.
Traditional Systems Development Life Cycle Approach
The user needs to be actively involved
Additionally, a formal change control process is established to prevent uncontrolled entry of new requirements into the development process.
Phase 3B-Selection
Based on the requirements defined, prepare a
request for proposal
from suppliers of purchased systems.
Functionality requirements
Operational, support and technical requirements
Suppliers' financial viability
Select the purchased system that best meets the organization's total requirements.
Phase 4B-Configuration
Configure the system, if it is a packaged system, to tailor it to the organization's requirements.
This is best done through the configuration of system control parameters, rather than changing program code.
There may be a need to build interface. programs that will
connect the acquired system with existing programs and databases .
IS project and end-user management can provide lessons learned and
or plans for addressing system deficiencies as well as recommendations for future projects regarding system development and project management processes
Advantage and possible problems of this traditional approaches
The primary advantage of the traditional approach is that it. provides a template into which
methods for the requirements
definition, design, programming, etc.)
can be placed
Unanticipated events.
Since projects rarely follow the.
sequential flow prescribed, iteration always occurred and creates
problems in implementing the approach
Unsettle Requirements
The difficulty of obtaining an explicit set of requirements from the customer/user as the approach requires
Managing requirement!s and convincing the user about the undue or unwarranted requirements in the system functionality, which may lead to conflict in the project
Constant Changes
A changing business environmental that alters or changes the customer's requirements before they are delivered
Working version of the system's programs will not be available until in end the project's life cycle.
Request For Proposal (RFP)
Product vs. system requirements
Customer references
Vendor viability/financial stability .
Availability of complete and reliable
Vendor support
Acceptance testing of the product
Number of client sites using the product
Source code availability
Number of years of experience in offering the product
A list of recent or planned enhancements to the product, with dates
Unit testing
Interface or integration testing
System testing
Recovery testing
Security testing
Load testing
Stress testing
Performance testing
Final acceptance testing
Quality assurance testing (QAT)
User acceptance testing (UAT)
Alpha and beta testing
Pilot Testing
White Box Testing
Back Box Testing
Function/ Validation Testing
Regression Testing
Parallel Testing
Sociability Testing

For example, test data generators can be used to systematically
generate random data that can be used to test programs
"The migration cannot be accomplished via a single event. In stead, a step-by-step transition of the affected services must take place"

Migration Scenario
Fallback (Rollback) Scenario
"The goal of a training plan is to ensure that the end user can become self-sufficient in the operation of the system"
Full transcript