charles mansour it auditing fundamentals
TRANSCRIPT
Audit Technology and Fraud Investigation Conference
London
IT Auditing Fundamentals
4th November 2015
Welcome!
© Charles Mansour Audit & Risk Service 2015
Me
Charles Mansour, CISA
35 Years in IT Audit & Risk
• UK Customs 1980 - 1986
• Banking and Financial Services 1986-2002
• Audit & Risk Service 2002 – 2015
• Past President of ISACA London Chapter
• Involved with COBIT® since 1993
• Member of ISACA International Membership Board 2004-
2007
© Charles Mansour Audit & Risk Service 2015
Session Objectives
• Provide you with an introduction to IT auditing concepts and fundamentals
© Charles Mansour Audit & Risk Service 2015
Agenda
• IT Audit Background
• Operating Systems and System Software
• Database
• Change Management
• Systems Development
• Networks
© Charles Mansour Audit & Risk Service 2015
IT Audit Background
© Charles Mansour Audit & Risk Service 2015
The Way Things Were
Data
Storage
Resources Processes
(and Change)
Security Authorisation Mail
Oversight
© Charles Mansour Audit & Risk Service 2015
The Way Things Are Now
Storage Business Processes
Data Mail
SECURITY
Authorisation?? Oversight??
© Charles Mansour Audit & Risk Service 2015
What’s it All About? • Your internal control framework • Assurance about its integrity • Business Processes owned by
– Business process owners (including application software & data)
– IT (including operating system / software, operations)
• IT is a service provider to business process owners
• Business process owners’ assets are under the day to day control of IT
• Additional issues (Outsourcing, the ‘Cloud’)
© Charles Mansour Audit & Risk Service 2015
What is the Biggest IT Risk?
• Arguably – The risk that IT is not strategically aligned with the direction
that the organisation is taking
– Has anyone here ever done an audit of ‘IT Strategic Alignment’?
– It’s not a technical piece of work
• Good News – The audit is more or less written down in CObIT® 4.1 under
process PO1 (‘IT Strategic Direction’), and
– COBIT5 Process EDM01 (‘ensure governance framework setting and maintenance.)
• IT Governance?
© Charles Mansour Audit & Risk Service 2015
Responsibilities
• Business Process Owners are responsible for – Process achievement of business objectives
– Identification of risks that impede achievement of business objectives (including IT related risks)
– Placement of controls that mitigate the risks
• IT Process Owners are responsible for – Ensuring that the processing of business assets under their
control is performed with • Confidentiality
• Integrity
• Availability
© Charles Mansour Audit & Risk Service 2015
Responsibilities
• IT has a ‘custodianship’ or ‘stewardship’ role over the business assets under its care – Data – Programs
• IT has a ‘duty of care’ to the process owner • IT should monitor its processes to ensure that the
controls to address risks are in place and working • IT should provide assurance to business process owners
about the mitigation of risks to their assets whilst they are under the control of IT
• IT’s Main Focus – Provision of service to its clients
© Charles Mansour Audit & Risk Service 2015
IT Processes and Business Materiality
• Important when assessing risk and control in an IT environment – often overlooked by IT – Where are the most important business assets kept
– Where are the main areas of business risk
– They’re what should be receiving most attention
• Example – In a police department processing system, there are two servers
• One holds details of police officers’ uniform measurements and police car servicing history
• One holds the local criminal / suspect database connected to the national crime database
– Should we treat them the same??
© Charles Mansour Audit & Risk Service 2015
Typical IT Dept. Organisational Chart
CIO
Production Development Networks/
Telecoms WEB / Internet
Operations
Prod’n
Support
Performance/
Capacity Mgt
Help Desk
Legacy
Systems
Maintenance
New
Systems
Development
Research Testing
Teams
Wide
Area Network
Local Area
Network Developments Support
© Charles Mansour Audit & Risk Service 2015
General Controls and Application Controls
• Application Controls – Address risks specific to a business application
• e.g. matching of purchase order, goods received note and invoice before making supplier payment
– Responsibility of the business process owner for, in the above case, the accounts payable process
• General Controls – Address risks to the computing environment
• e.g. unauthorised changes to the production environment
– Responsibility of the CIO
• BUT accountability rests with the Process Owner
© Charles Mansour Audit & Risk Service 2015
Application Controls
© Charles Mansour Audit & Risk Service 2015
IT Infrastructure/General Controls Data
Security
Physical
Security
Operating
System
Software
Access
Controls
Operations
System
Development
Methodology
Database
Administration
Telecommunications
Environmental
Protection
Disaster
Recovery
Program
Change Mgt
General
Controls
© Charles Mansour Audit & Risk Service 2015
© Charles Mansour Audit & Risk Service 2015
IT – Main Areas
• Operations – Run and store • Operating systems and utilities
• Database and database administration
• Change Control
• Development – Build • Key development stages
• Testing and migration into production
• Communications – Move • Network availability
• Confidentiality
• Integrity of traffic
© Charles Mansour Audit & Risk Service 2015
Operating Systems, Systems Software and Utilities
© Charles Mansour Audit & Risk Service 2015
Operating Systems
• An operating system (OS) is software, consisting of programs and data, that runs on computers and manages the computer hardware and provides common services for efficient execution of various application software
• Stands between the computer and the outside world
• No OS – No computing
© Charles Mansour Audit & Risk Service 2015
Operations - Operating Systems and Utilities
• An Operating System – Permits users / programs to share hardware and
data
– Schedules resources e.g. printers, memory, disk drives etc, among, users and program
– Informs users of any errors with the processor. I/O (Input / Output) or programs
– Permits recovery from system errors
– Communicates with application programs, allocating memory to processors, and freeing it when tasks are complete
© Charles Mansour Audit & Risk Service 2015
How it Works
1.Electric current passes into the
computer
2.Bootstrap ‘firmware’ (e.g. BIOS)
on a ‘hard coded’ chip ‘wakes
up’, checks components are
connected (e.g. printers, disk
drives) and looks for an
operating system
3.Once located, the operating
system takes control and starts
to load settings (parameters)
© Charles Mansour Audit & Risk Service 2015
Operating System Parameters
• Operating Systems are ‘driven’ by parameters that are set by the system programmers
– Data Management
– Resource Management
– Job Management
– Priority setting
• If not configured correctly, can result in
– Undetected errors
– Data corruption
– Unauthorised access
© Charles Mansour Audit & Risk Service 2015
Operating System (OS) Parameters
• Parameters are stored in a library (folder) used by the operating system during start-up (IPL – Initial Program Load)
– In IBM z/OS, SYS1.PARMLIB
• Library needs to be highly secure
© Charles Mansour Audit & Risk Service 2015
Privileged and User States
• Privileged (Supervisor) state – Permits complete unrestricted access to all resources – Capability to by pass security software – Many system software utility programs operate in this
state – Some application programs may operate in this state
• General (User) state – Most restricted state – User and application programs can only access
resources when they have been allocated permissions, usually by access control software rules
© Charles Mansour Audit & Risk Service 2015
System Software and Utilities (they’re all computer programs)
• System Software – The OS itself – Database Management Systems – Network OS
• Utilities – Programs used for ‘housekeeping’ – called by the
OS when needed • Sort software • Data comparison • Query software • Printer file viewing / editing • Defragmenting • Data compression
© Charles Mansour Audit & Risk Service 2015
System Software and Utilities
• Some utilities can be POWERFUL!
– Able to change / delete records
• IBM z/OS – AMASPZAP (SUPERZAP)
• ‘rm’ command in UNIX
• ‘Delete’ command in Windows Explorer
• In a lot of cases, ‘once they’re gone, they’re gone’
• Need to be kept in very well protected libraries
• Record of usage for very powerful utilities
• Useless without monitoring
• Some utilities can be POWERFUL!
– Able to change / delete records
• IBM z/OS – AMASPZAP (SUPERZAP)
• ‘rm’ command in UNIX
• ‘Delete’ command in Windows Explorer
• In a lot of cases, ‘once they’re gone, they’re gone’
• Need to be kept in very well protected libraries
• Record of usage for very powerful utilities
• Useless without monitoring
• Some utilities can be POWERFUL!
– Able to change / delete records
• IBM z/OS – AMASPZAP (SUPERZAP)
• ‘rm’ command in UNIX
• ‘Delete’ command in Windows Explorer
• In a lot of cases, ‘once they’re gone, they’re gone’
• Need to be kept in very well protected libraries
• Record of usage for very powerful utilities
• Useless without monitoring
• Some utilities can be POWERFUL!
– Able to change / delete records
• IBM z/OS – AMASPZAP (SUPERZAP)
• ‘rm’ command in UNIX
• ‘Delete’ command in Windows Explorer
• In a lot of cases, ‘once they’re gone, they’re gone’
• Need to be kept in very well protected libraries
• Record of usage for very powerful utilities
• Useless without monitoring
• Some utilities can be POWERFUL!
– Able to change / delete records
• IBM z/OS – AMASPZAP (SUPERZAP)
• ‘rm’ command in UNIX
• ‘Delete’ command in Windows Explorer
• In a lot of cases, ‘once they’re gone, they’re gone’
• Need to be kept in very well protected libraries
• Record of usage for very powerful utilities
• Useless without monitoring
• Some utilities can be POWERFUL! – Able to change / delete records
• IBM z/OS – AMASPZAP (SUPERZAP)
• ‘rm’ command in UNIX
• ‘Delete’ command in Windows Explorer
• In a lot of cases, ‘once they’re gone, they’re gone’
• Need to be kept in very well protected libraries
• Logs should record usage of very powerful utilities • Useless without monitoring
© Charles Mansour Audit & Risk Service 2015
System Software - Licensing
• Nearly all system software and utility software (and application software packages) comes from third party organisations
• Can only be used under license from the third party
• Even your desktop software is licensed from Microsoft
• If your company is found to be using unlicensed software, reputational damage can be severe
• Needs a system software utility inventory / license check
© Charles Mansour Audit & Risk Service 2015
OS and System Software Key Risks / Controls Risk Control
Failure to recover operating system and key utilities
Software back ups kept securely off site
OS software or utilities used to bypass application controls
Review of key system software usage logs by IT Management (systems programmers use separate logonid for usage of sensitive utility software)
Operating system not kept up to date Management monitoring to ensure all upgrades implemented Policy statement on staying current
Poorly configured system software leads to service disruption
Key parameters identified and settings reviewed by management
Use of unlicensed system software
Review of software inventory to ensure all third party system software is licensed
Untested modifications / patches implemented
Process for software implementation / change regularly monitored by management
Re-work arising out of Processing errors going undetected
Monitoring of batch and online processes by Computer Operations
© Charles Mansour Audit & Risk Service 2015
Operating Systems and Utilities Audit Points
• What have we got?
• Where is it / are they?
• Have we got the right resources to run / maintain it?
• What are the OS vulnerabilities
• How are they addressed?
• How secure is it?
• How is accountability established?
• How do we keep it up to date?
• How do we recover it?
© Charles Mansour Audit & Risk Service 2015
Operating System and Utilities Audit Points
• The primary audit (control) objectives include:
– Ensuring the protection of the Operating System from unauthorized access.
– Limiting who (or what) has “privileged” access and what they can do.
– Ensuring that security fixes and patches are applied on a timely basis.
– Ensuring that appropriate testing is done prior to installing new patches in the production system.
– Ensuring appropriate controls when installing new operating systems such as roll-back procedures.
© Charles Mansour Audit & Risk Service 2015
Database and Database Administration
© Charles Mansour Audit & Risk Service 2015
Information as a Business Asset Information is your most valuable business asset
Used to be Now
© Charles Mansour Audit & Risk Service 2015
IT Data Management • Process owners ‘own’ programs and data
• Programs reside in program libraries (outside the scope of this session)
• Data resides in a database
– Managed on a day to day basis by IT
– Enabled by system software components supporting
• Data definition
• Storage
• Sharing
• Processing
• File management
• Ultimate responsibility for data integrity rests with process owner
© Charles Mansour Audit & Risk Service 2015
Database
• Collection of detailed data about the organisation held on magnetic media – Customers
– Products
– Personnel
– Financials
• Reduces data redundancy – Each item of data
• Customer name and address
– Held only once
© Charles Mansour Audit & Risk Service 2015
Database Management System (DBMS)
• System Software • Organises
• Controls
• Protects
• Uses
– Data used by application programs
• Objectives
– Maximise data organisation
– Decrease access time
– Provide security
© Charles Mansour Audit & Risk Service 2015
Database
Portal into
the
Database Database
Management
System controls the portal
© Charles Mansour Audit & Risk Service 2015
Database Structures
• Main structure in use today is the Relational Database – Database consists of many ‘tables’ (files) which are a
– Collection of many ‘rows’ (records) which are a
– Collection of many ‘columns’ (fields)
• Connected by indices (common information)
• Every database entry has to be unique – i.e. there can only be one occurrence of ‘Customer No
1’ in the entire database
© Charles Mansour Audit & Risk Service 2015
Relational Database
Savings Account
Customer
Loan
Accounts
Customer 1
Customer 2
Customer 3…
Customer 9999999
Customer No 1
Surname
First Name
Date of Birth
Address Line 1
Address Line 2
Loan a/c No Many
Tables
Database
Rows
Columns
Many
© Charles Mansour Audit & Risk Service 2015
Example: Loan System Needs Customer No10059’s Contact Details
Loan Accounts Table
Loan Account No: 4220
Customer No: 10059
Balance: 22456.90
Payments: 16435.98
Customer Table
Customer 10059
Customer 10060….
Customer 9999999
Customer No 10059
Surname: Mansour
First Name: Charles
Date of Birth: 1 Jan 1990
Address Line 1: Paris Hilton
Address Line 2: Paris France
Loan a/c No: 4220
Index is ‘Customer No’
© Charles Mansour Audit & Risk Service 2015
Database Risks Risk Control
Loss of database integrity or availability
Backup of database stored off site Enforcement of Data Dictionary and Data Definition standards
Uncontrolled use of powerful system utilities
Detective controls over the use of database tools
Conflict with other duties Segregation of duties (DBA shouldn’t be responsible for computer operations or have access to application programs)
Unauthorised activities by Database Administrator
Management review of logs and activities. User ‘sign off’ of any changes to their data. Supervisory review of DBA activities
Unauthorised access to database
Logical access controls to ensure that only authorised programs / utilities can access data in the database
Poor database performance Use if reporting tools to monitor and maintain database efficiency
Inconsistent use of database resources
Policies and Procedures govern use of the database by application programs or system utilities
© Charles Mansour Audit & Risk Service 2015
Database Audit Points
• How many databases?
• Where?
• How many DBA’s
• Does the DBA have any conflicting duties?
• Powerful database utility software
– Where is it stored?
– How is its use accounted for?
© Charles Mansour Audit & Risk Service 2015
Database General Control Audit Points
• Do all distributed databases have the same security settings?
• Are DBMS, application, and data change control procedures documented and followed?
• Can database become a single point of failure?
• Are user authorisation procedures documented and followed?
• Are application authorisation procedures documented and followed?
• Are audit records created? Are they reviewed?
© Charles Mansour Audit & Risk Service 2015
Database Application Control Audit Points
• Have the business rules, triggers, stored procedures and referencing applications been verified and tested?
• Which users have views into the database? How often is this verified?
• What are the authorized applications? How often is this verified?
• What are the synchronization schedules?
© Charles Mansour Audit & Risk Service 2015
• Do applications working against the database have the same security settings as the database?
• What are the change controls for data, rules, triggers, stored procedures?
• Are appropriate audit records created? Are they reviewed?
Database Application Control Audit Points
© Charles Mansour Audit & Risk Service 2015
Change Management
© Charles Mansour Audit & Risk Service 2015
Why do we Need Change Management?
• Once implemented, business processes will change • (80% of a system’s cost is incurred after it has been
implemented)
• Process Owners’ requirements of IT for changes involving information assets – Respond to business requirements – Alignment with business strategy – Elimination / reduction of defects – Elimination / reduction of re-work
• Prevention of Business Disruption • Prevention of Fraud • Prevention of Intrusion
47
© Charles Mansour Audit & Risk Service 2015
Business Rationale for Change Management
• Process Owners need to be sure
• All changes to software and data under their control can only be made with their – Knowledge
– Approval
• Informs the amount of reliance that Process Owners can place the – Security
– Integrity
– Availability
– Of their information assets whilst in the custody of IT © Charles Mansour Audit & Risk Service 2015
Business Rationale for Change Management Ideal Situation
Production Environment
Portal into
the Production
Environment
Process Owner controls the portal
THEORY
The only changes to the
Process Owner‘s
software / data are those
instances when the
Process Owner decides
to lower the drawbridge
to allow them through
the portal into the
Production environment
© Charles Mansour Audit & Risk Service 2015
Are There any Holes in the Wall?
© Charles Mansour Audit & Risk Service 2012 © Charles Mansour Audit & Risk Service 2015
Scope of Change Management Process • Applies to changes to
– Application Programs •In house developed
•Purchased
•Run by outsourcing companies
– System software
– Hardware
– Data
– Any third party carrying out business on behalf of the Process Owner (includes Cloud Service Providers)
– Should apply to any unscheduled jobs that are run in the production environment
© Charles Mansour Audit & Risk Service 2015
Change Management Process
© Charles Mansour Audit & Risk Service 2012
Change Request and
Analysis
Change Prioritisation
Change Development
Change Migration and Quality Check
Change Register
Change Policy
Process Owner
Authorises
change
Users / IT staff
analyse change
with Business
Impact Analysis
CIO or IT Steering
Committee
authorise and
sign off change
Work instruction
issued to
programmer
Programmer
‘Checks out’ module
for
‘Code ‘walkthrough’
Compile into
Executable module
Link Edit
Migrate to QA
Library (Change
staff perform QA)
© Charles Mansour Audit & Risk Service 2015
Change Management Process
53
User Testing
Operability Testing &
Change Implementation
Post Implementation
Review
Change Policy
Change Register
Change code migrated to
system test library
Users develop test scripts
and test for compliance
with requirements Regression testing for fixing
problems
Process Owner authorises
move to Operability library
Operability testing
Operations notes and
documentation updated and
tested
Process Owner authorises
implementation prior to
migration to production
libraries
Change migrated into
production environment
Process Owner verifies that
change complies with
request and is delivering
specified business benefit
Final sign off of change
© Charles Mansour Audit & Risk Service 2015
Unauthorised Changes
• Can be from
– Use of powerful systems utilities
– Emergency fixes
– Developers active in production environment
– Unintended default access privileges
– Hackers
– Social Engineering
– Viruses
© Charles Mansour Audit & Risk Service 2015
Emergency Changes
• Can be one of two types
• ‘Fast Track’ changes
– Known problem
– Needs to be implemented quickly
– Change passes through change management steps, but more quickly
– Still need to be tested prior to implementation
© Charles Mansour Audit & Risk Service 2015
Emergency Changes
• Unexpected Problem – 3am - fix to get things working – Need to fix problem properly next day – Two approaches
•‘backward migration’ Not recommended! –Leave changed production code in place –Make all other copies of program reflect the emergency change –Retrospective user sign off
•Apply change through ‘fast track’ change management –Back out production code changes and start change process –Business Impact analysis –Testing –User signoff
© Charles Mansour Audit & Risk Service 2015
Key Risks
© Charles Mansour Audit & Risk Service 2012 57
Risk Control
Uncoordinated changes Existence of a change management policy and underlying processes Monitoring by management to ensure compliance with process
Changes fail to meet business need User sign off of change request Testing by users prior to change being implemented
Unauthorised changes Single point for migration of authorised changes Running software to ensure that code in production libraries matches code in development libraries All changes ‘frozen’ unless released from configuration database
Users become frustrated waiting for changes and begin to develop their own solutions
Monitoring of user satisfaction e.g. by use of response forms at the end of every change IT / User relationship management
Unable to back out changes in the event of problems after implementation
Strict use of version control over all changes (configuration management enforces version control)
© Charles Mansour Audit & Risk Service 2015
Key Risks
Risk Control
Emergency changes introduce inconsistencies between development and production versions of program code
Process to ensure that all emergency changes are regressed back to the start of the change process All emergency changes performed under a dedicated logonid which is logged and reviewed by IT management
Changes not made according to business importance
Prioritisation of change requests by IT Steering Committee or CIO
Changes made in QA or testing environments by development staff
Access controls to prevent developer access to any libraries other than development
© Charles Mansour Audit & Risk Service 2015
Auditing Change Management
Control Objectives
Change Standards & Procedures
Test for existence and compliance
Business Impact Assessment and Change Prioritisation
Inspect documentation
Emergency Changes
Check list of emergency fixes put into production
© Charles Mansour Audit & Risk Service 2015
Auditing Change Management
Change status tracking and reporting
Pick a selection of implemented changes and verify back through process to change request
Change closure and documentation
Verify that Process Owner is satisfied that change
•Complies with business requirements
•Has delivered business benefits
© Charles Mansour Audit & Risk Service 2015
Systems Development
© Charles Mansour Audit & Risk Service 2015
Engaging with Development Projects
• Audit has two roles – Assurance that the systems development process
has all the key development risks identified and addressed by controls
– Assisting the Process Owner to •Identify risks to the process that will be delivered
•Prioritising the risks –Key risks
–Non Key risks
–Trivial risks
•Decide on the risk mitigation mechanisms (Controls) to be built as part of the development process
62
© Charles Mansour Audit & Risk Service 2015
Development Projects and Programmes • Development Project
– A single piece of work to produce a deliverable that will result in business benefit, or better compliance with regulations
– Project Manager is accountable for the building process
• Programme – As above but consisting of a group of projects
closely linked together e.g. •Development of current account and savings account using the same software package
– Programme Manager is accountable
63
© Charles Mansour Audit & Risk Service 2015
Development Approaches
• Build
– Construct business solution ‘in house’
• Buy
– Acquire software solution from a third party
• Enhance Existing Process
– ‘Re-engineer’ existing process to take changes into account
© Charles Mansour Audit & Risk Service 2015
Project Governance Senior
Management (Project
Champion)
Project Sponsor
Process Owner
Project Manager
Project
Steering
Committee
Systems Development Project team
User Project Team
Technical Infrastructure
Team
Subject Matter Experts
Finance, Security etc.
© Charles Mansour Audit & Risk Service 2015
Big Risk!
66
• Are systems development projects under managed?
• Are system developments under governed?
• No!
• So how do they manage to lose $600 billion per year in failed or dropped development projects
• The Standish Group reports that around 30% of IT projects (worldwide) will be cancelled. Around 52% of projects will cost 189% of their original estimates. Only 16% are completed on-time and on-budget. In larger companies, the news is even worse: only 9% of their projects come in on-time and on-budget.
© Charles Mansour Audit & Risk Service 2015
67
Importance of Getting it Right
•Critically important that new business solutions
work as expected
•80% of the cost of an application system is
incurred after implementation
•Re work accounts for up to 40% of most IT
departments’ costs
•Reputational damage is immense when new
systems fail (UK NHS, Heathrow Terminal 5)
•Unspecified costs increase further along the
development life cycle
© Charles Mansour Audit & Risk Service 2015
Relationship Between Project and Process Owner
©
• Analogous to a Shipbuilder and a Shipowner
Project Team = Shipbuilder
They build the ship according to
The client’s business specification
Client = Shipowner
Accepts the ship from the
Shipyard when happy that it has
been built to specification and
fully trialled (otherwise it
might sink!). Responsible for the
safety and profitability of the
ship throughout its working life
© Charles Mansour Audit & Risk Service 2015
Development & Production Environments
©
NOTHING moves from
HERE to HERE
Unless tested and
approved by Process
Owner that it is fit for
purpose
Production
Environment
‘Live’ running.
Where the systems are
used to help achieve
corporate objectives (profit
in a commercial company)
Development
Environment Where systems are
designed, built and
tested
© Charles Mansour Audit & Risk Service 2015
System Development Life Cycle
70
Development
(Inc. Procedures)
Proof of Concept
Planning
Requirements
Analysis
Design
Initiation
Integration and Test
Implementation
Operation and
Maintenance
√
√
√
√
X
√
√ = Process Owner sign off
Key Control
Point
© Charles Mansour Audit & Risk Service 2015
How Much Does a Line of Cobol Code Cost?
Time
Cost
$10 per Cobol
Line $1 per Cobol
Line
$100 per Cobol
Line
Design Build Implementation
© Charles Mansour Audit & Risk Service 2015
© Charles Mansour Audit & Risk Service 2015
Audit Approach to Product & Project Risk
• Product Risks – Specific to the product that is being designed and
delivered
– Audit can work on a ‘per project’ basis with the Process Owner to
•Identify that the risks that impact achievement of the application’s business objectives are identified and prioritised
•Controls are devised to address the significant risks identified
•Produce a Risk Profile document at implementation
•Ensure that the control mechanisms are designed, built, tested and delivered prior to implementation into production
73
© Charles Mansour Audit & Risk Service 2015
Audit Approach to Product & Project Risk
• Project Risk – Process of systems development
– Responsibility of CIO
– Will be separately audited in depth as a business process as part of the audit plan (usually every year)
– Auditors assigned to projects may focus on project risks at expense of product risks
•Recommendations to address weaknesses often overtaken by pace of development
•Can lead to duplication and confusion
© Charles Mansour Audit & Risk Service 2015
Audit Approach to Product & Project Risk – cont’d
• Best to focus on product risk and wait for audit of Systems Development process to address any weaknesses found
• Recommendations made in the course of a full audit will be addressed and tracked to completion
• Weaknesses can be recorded and addressed in the next audit of Systems Development
• Scheduled audit of Systems Development process can be brought forward if any serious weakness is identified at project level
© Charles Mansour Audit & Risk Service 2015
Networks
© Charles Mansour Audit & Risk Service 2015
Network Objectives
© Charles Mansour Audit & Risk Service 2015
Relationship Between IT and Business
Like the Postal delivery services
Point A
Point B
Business is responsible for
What’s in the packages
(Network Traffic) like the
Postal customer)
IT is responsible for the
mechanism for electronically
delivering the packages from
Point A to Point B (The
Communications
Network) like the Post Office
Business wants to move
Something electronically from
Point A to a remote Point B
© Charles Mansour Audit & Risk Service 2015
Network Devices
• Don’t forget!
• They are all little computers with their own
– Operating Systems
– Programs
– Parameters
– Data stores
– Connections
© Charles Mansour Audit & Risk Service 2015
Network Devices
• Don’t forget!
• They are all little computers with their own
– Operating Systems
– Programs
– Parameters
– Data stores
– Connections
© Charles Mansour Audit & Risk Service 2015
Network Devices Network Topology Diagram
• Firewall
• Hub
• Bridges
• Router
• Modems
• Terminals
• Printers
© Charles Mansour Audit & Risk Service 2015
Client Server Architecture
• Each computer or process on the network is either
– A server (a source of data)
– A client (a user of services and data that relies on the server to obtain them)
• The client / server connection is between two disparate machines that normally can’t ‘talk’ to each other
• The ‘conversation’ between the two is facilitated by ‘middleware’
© Charles Mansour Audit & Risk Service 2015
‘Thin Client’ and ‘Fat Client’
© Charles Mansour Audit & Risk Service 2012
Most work
done by
the server
Client
displays
output
Most work
done by
the server
Client
formats &
displays
output
Application
processing
shared
between
Server &
Client
All
Application
work done
by
Client
Database
shared
between
client &
server
© Charles Mansour Audit & Risk Service 2015
Network Auditing
• EXTREMELY Complex
• Focus should be on
– Level of service (Availability)
–Service Level Agreements
– Confidentiality
–Encryption
– Integrity
–Message validation techniques
© Charles Mansour Audit & Risk Service 2015
Auditing Focus • Understanding
• Enterprise Policy for Network usage and encryption
• Any agreements with third parties re network operation
• Network topology and design
• Network components and location
• Interconnected networks
• All access points into the network
• Internet Gateway
• Administration and operational responsibility
•distributed , mixed, centralised
• Primary Business Users
© Charles Mansour Audit & Risk Service 2015
Auditing Focus
• Establishing
– Logical access controls over network usage
– Physical and Environmental controls
– Service Level Agreements with Business
– Traffic Management
– Availability of network in the event of failure of any component
– Network Change and Configuration Management processes
© Charles Mansour Audit & Risk Service 2015
Potential Problem
• Most Wide Area Network connections are leased from the national Telecoms provider, e.g. BT – This means that the national telecoms provider is a service
provider to the enterprise, like an outsource company
– The enterprise has to satisfy itself that the KEY risks attaching to information whilst it is under the control of the telecomms provider are adequately addressed by their controls
– e.g. is the service provider’s physical security over it’s servers and routers adequate to protect the enterprise’s business information in transit under it’s control
– Many IT managers do not see this as an area that they have to do anything about
© Charles Mansour Audit & Risk Service 2015
We’ve Just Had a Quick Look At
• IT Audit Background
• Operating Systems and System Software
• Database
• Change Management
• Systems Development
• Networks
© Charles Mansour Audit & Risk Service 2015
Any questions?
We are happy to answer any queries…
© Charles Mansour Audit & Risk Service 2015
© Charles Mansour Audit & Risk Service 2015
Charles Mansour Audit & Risk Service
Overall Lodge
Pound Lane
Hadleigh
Suffolk
IP7 5EQ
Tel: 01473 823406
Mob: 07799 604338
e-mail: [email protected]
My Contact Details