SysTrust Introduction SYSTRUST COURSE February 2001.

SysTrust IntroductionSysTrust Introduction

SYSTRUST COURSE

February 2001

SysTrust HistorySysTrust History

SYSTRUST COURSE

February 2001

AgendaAgenda

Vision Task Force Membership SysTrust Roll-out Activities Task Force’s Due Diligence Support Tools Successes to Date Feedback to Date Future Enhancements

VisionVision

Real-time assurance on on-line databases

Systems ReliabilityTask Force Focus

Systems Reliability Assurance

Report oninternal control

Tomorrow

Today

Ultimately

Task Force MembershipTask Force Membership

Thomas E.Wallace, Chair

J. Efrim Boritz

Robert Parker

Robert J. Reimer

George H. Tucker III

Miklos A. Vasarhelyi

Sander Wexler

Dan White

CICA Staff

– Bryan Walker, Principal, Research Studies

AICPA Staff

– Erin P. Mackler, Technical Manager Assurance Services

– Judith M. Sherinsky, Technical Manager Audit and Attest Standards

SysTrust Roll-out Activities 1SysTrust Roll-out Activities 1

11/997/99 9/99

Issued

Exposure

Development

Supporting Tools

SysTrust Roll-out Activities 2SysTrust Roll-out Activities 2

SCAS/TFAS 1996 - 1997 Version 1 - Jan/88 - Nov/89

– Development - Jan/88 - April/99– Review - April/99 - June/99– Exposure Draft - July/99 - September/99– Final issuance - Fall 1999– Training courses - Fall 1999

Version 2 - Jan - July 2000 Version 3 - Jan - ? 2001

Task Force’s Due DiligenceTask Force’s Due Diligence

Review of draft conducted by:– Associates - practitioners, academics– Institutes’ technical committees– Ev Johnson - Chair of eComm Committee– Selective members of Institutes’ ASB– Industry - Internal Audit, CFO, CIO

Considered:– market and need, completeness and relevance of

principles & criteria, & other comments

Support Tools 1Support Tools 1

Competency Model -– What skills are needed for SysTrust

Training Courses -– SysTrust Overview– How to Perform a SysTrust Engagement– In-Depth Training in SysTrust Principles &

Criteria– Information Systems Audit & Control

Association (ISACA) courses


Practitioners Aids - – Workplans– Engagement letters– Representation letters– Checklists– Practice guides– Marketing ideas


Marketing– Conceptual Marketing Plan by AICPA– articles/ads e.g. Journal of Accountancy,

CA Magazine, ISACA– AICPA and CICA websites– pilot project testimonials by practitioners– conferences and training (UWCISA/JIS)– related organizations; e.g. ISACA

Alliances

Successes to DateSuccesses to Date

Approx. 40 engagements Typically $100 - 200,000 range Many pre-implementation/readiness

reviews Industries:

– Government, Banks, Utilities– .Coms: Loudcloud.com, Agillion.com

Adoption by Internal Audit departments

Feedback to DateFeedback to Date

Like framework: Need flexibility in use:

– ability to report on less than all principles– ability to issue a point in time report

Clarify privacy’s impact on reliability:– in - confidentiality of private information– out - accuracy of data, consent, individuals’

right to view, remediation, etc

Future EnhancementsFuture Enhancements

Versions 3.0 & 4.0?– enhancements to principles & criteria– enhancements to reporting

point in time, “seal” program, holistic

– continuous auditing & reporting Buy-in by industry

– management, internal audit, developers Buy-in by Practitioners

SysTrust!SysTrust!

SysTrust OverviewSysTrust Overview

SYSTRUST COURSE

February 2001

AgendaAgenda

Systems Reliability in Business What is SysTrust? Positioning SysTrust SysTrust Framework

– System– Reliability– Criteria– Controls

Systems Reliability Systems Reliability in Businessin Business

IT Running the BusinessIT Running the Business

IT Differentiatesin the MarketplaceIT Differentiatesin the Marketplace

IT Demandingmore CapitalIT Demandingmore Capital

IT Permeating allareas of a CompanyIT Permeating allareas of a Company

More Reliance onIT of PartnersMore Reliance onIT of Partners

GrowthProfitabilityMkt Share

GrowthProfitabilityMkt Share

SPEED, COST

& QUALITY

Drivers of NeedDrivers of Need

Like a weak link in a chain, an unreliable system can fail the entire business

Recent HeadlinesRecent Headlines

“Security rated

top on-line fear”

“Computer woes halt TSE trading”

“eBay waives $3-5 million listing

fees after service outage”

“Rail company’s unreliable systemcauses rail cars to stack up, shippingdelays and shipments gone astray”

“Worm.Explore.Zip virus forces

shutdown of companies’ systems”

“Computer errors decimatemanaged care company’s stock”

Reliability & the MarketReliability & the Market

0

10

20

30

40

50

60

70

10/5

/98

10/1

9/98

11/2

/98

11/1

6/98

11/3

0/98

12/1

4/98

12/2

8/98

1/11

/99

1/25

/99

2/8/

99

2/22

/99

3/8/

99

3/22

/99

E*Trade Publicized Network Failures & Resulting Market Cap Decreases

E*T

rade

Sto

ck P

rice

(EG

RP

)

$767m

$737m $ 2.5b

Factors of UnreliabilityFactors of Unreliability

Denial of Service– system failures, crashes, capacity issues

Unauthorized Access– Viruses, hackers, loss of confidentiality

Loss of Data Integrity– corrupted, incomplete, fictitious data

Maintenance problems– unintended impact of system changes

Failure to fulfill commitments

Need for SysTrustNeed for SysTrust

What We Found: No Common Definition of Reliability

– e.g. is security in or out? No Basis for Comparison

– at what point is reliability achieved Differing levels of Objectivity & Rigor

– how much and how good is assessment

What is “SysTrust” ?What is “SysTrust” ?

SysTrust - A CA/CPA’s assurance report on a system’s reliability – US - SSAE #1– Canada -section 5025

Opinion on controls using framework of 4 principles & 58 criteria on reliability

To earn SysTrust opinion, a system must meet all criteria for principles reported on

A “SysTrust” Opinion...A “SysTrust” Opinion...

“ We have audited the assertion by mgmt that... ABC company maintained effective controls...over system availability, security, processing integrity and maintainability...based on SysTrust principles & criteria…”

“ In our opinion mgmt’s assertion…is fairly stated in all material respects...”

SysTrust Criteria

Components of “SysTrust”Components of “SysTrust”

System Description

Mgmt’s Assertions

Auditor’s Report

Positioning “SysTrust” Positioning “SysTrust” 11

ContinuousAuditing

PeriodicAssurance

ConsultingServices

Design ----Implement ---------------Operate

SysTrust

Positioning “SysTrust” Positioning “SysTrust” 22

Non-Financial

Financial

InternalUsers

ExternalUsers

SAS/70

S- 5900

WebTrust

SysTrust

DefinitionsDefinitions

“SYSTEM” “RELIABILITY” “CRITERIA” “CONTROLS”

(vs. internal control)

““SYSTEM” SYSTEM” 11

A SYSTEM is an organized collection of software, infrastructure, people, procedures and data that, together within a business context, produces information

Software

Procedures

Infrastructure

Data

People

SY

ST

EM

““SYSTEM” SYSTEM” 22

– infrastructure (facilities, equipment and networks)

– software (systems, applications, utilities)

– people (developers, operators, users and managers)

– procedures (automated and manual)

– data (transaction streams, data bases and tables)

““RELIABILITY” RELIABILITY”

Reliable System defined as:

“A system that operates without material error, fault or failure during a specified time in a specified environment.”

Four Principles:- Availability - Security- Integrity - Maintainability

““Reliability” FrameworkReliability” Framework

CRITERIACRITERIA CRITERIACRITERIA CRITERIACRITERIA CRITERIACRITERIA

AV

AIL

AB

ILIT

YA

VA

ILA

BIL

ITY

SEC

UR

ITY

SEC

UR

ITY

INTEG

RIT

YIN

TEG

RIT

Y

MA

INTA

INA

BIL

ITY

MA

INTA

INA

BIL

ITYRELIABILITYRELIABILITY

““CRITERIA”CRITERIA”

Each Principle has series of Criteria Criteria categories:

– policies exist and are appropriate– policies are implemented and operate– adherence to policy is monitored

Definition of Criteria:- measurable - relevant- objective - complete

Structure of Criteria Structure of Criteria 11Structure of Criteria Structure of Criteria 11

Structure of Criteria Structure of Criteria 22

PRINCIPLES

CRITERIA CATE-GORIES

Availability Security Integrity Maintainability TOTALS

Policies 5 5 5 5 20

Procedures 4 11 6 5 26

Monitoring 3 3 3 3 12

Totals 12 19 14 13 58

Example: AvailabilityExample: Availability

Principle: The system is available for operation and use at times set forth in service level statements or agreements.

Criteria Categories: – The entity has defined and communicated performance

objectives, policies, and standards for system availability.

– The entity utilizes processes, people, software, data, and infrastructure to achieve system availability objectives in accordance with established policies and standards.

– The entity monitors the system and takes action to achieve compliance with system availability objectives, policies, and standards.

Example: Availability (cont’d)Example: Availability (cont’d)

Availability: The system is available for operation and use at times set forth in service level statements or agreements.

Criteria

A1 The entity has defined and communicated performance objectives, policies, and standards for system availability.

A1.1 The system availability requirements ofauthorized users, and system availabilityobjectives, policies, and standards areidentified and documented.

A1.2 The documented system availabilityobjectives, policies, and standards have beencommunicated to authorized users.

A1.3 The documented system availabilityobjectives, policies, and standards areconsistent with the system availabilityrequirements specified in contractual, legal,and other service level agreements andapplicable laws and regulations.

A1.4 Responsibility and accountability for systemavailability have been assigned.

A1.5 Documented system availability objectives,policies, and standards are communicated toentity personnel responsible for implementingthem.

““CONTROLS”CONTROLS”

primary evidential basis for evaluating whether criteria, hence, reliability principles satisfied

assurance provider assesses controls deemed relevant to concluding whether Criteria met

may supplement with direct tests of Criteria require judgment to determine nature and extent of

evidence required to verify existence, effectiveness and continuity of controls

Illustrative Controls Illustrative Controls 11

CICA’s ITCG– comprehensive coverage

risk management & control,

IT planning, IS acquisition,

development & maintenance,

operations & support, security, business continuity &

recovery, etc.

Illustrative Controls Illustrative Controls 22

ISACF’s COBIT– also comprehensive

planning & organization, acquisition &

implementation, delivery & support, monitoring, etc.

Example: Availability (cont’d)Example: Availability (cont’d)

Availability: The system is available for operation and use at times set forth in service level statements or agreements.

Criteria Illustrative Controls

A1 The entity has defined and communicated performance objectives, policies, and standards for system availability.

A1.1 The system availability requirements ofauthorized users, and system availabilityobjectives, policies, and standards areidentified and documented.

Procedures exist to identify and document authorized users of the system and their availabilityrequirements.

User requirements are documented in service level agreements or other documents.

A1.2 The documented system availabilityobjectives, policies, and standards have beencommunicated to authorized users.

There is formal communication of system availability objectives, policies, and standards toauthorized users through means such as memos, meetings, and manuals.

Procedures exist to log and review requests from authorized users for changes and additions tosystem availability objectives, policies, and standards.

A1.3 The documented system availabilityobjectives, policies, and standards areconsistent with the system availabilityrequirements specified in contractual, legal,and other service level agreements andapplicable laws and regulations.

A formal process exists to identify and review contractual, legal, and other service levelagreements and applicable laws and regulations that could impact system availability objectives,policies, and standards.

Procedures exist to review any new or changing contractual, legal, or other service levelagreements and applicable laws and regulations for their impact on current system availabilityobjectives, policies, and standards.

A1.4 Responsibility and accountability for systemavailability have been assigned.

A position(s) exists that has formal responsibility and accountability for system availability asindicated by a documented job description and organization chart.

A1.5 Documented system availability objectives,policies, and standards are communicated toentity personnel responsible for implementingthem.

Documented system availability objectives, policies, and standards are communicated topersonnel responsible for implementing them through such means as memos, meetings, andmanuals.

Additions and changes to system availability objectives, policies, and standards arecommunicated on a timely basis to entity personnel responsible for implementing and monitoringthem.

Principles & CriteriaPrinciples & Criteria

SYSTRUST COURSE

February 2001

SysTrust PrinciplesSysTrust Principles

The system is available for operation and use at times set forth in service level statements or agreements.

The system is protected against unauthorized physical and logical access.

System processing is complete, accurate, timely and authorized.

The system can be updated when required in a manner that continues to provide for system availability, security, and integrity.

Security PrincipleSecurity Principle

Category S1: – The entity has defined and

communicated performance objectives, policies, and standards for system security.


S1.1: The system security requirements of authorized users, and the system security objectives, policies and standards are identified and documented.

S1.2: The documented system security objectives, policies, and standards have been communicated to authorized users.

S1.3: Documented system security objectives, policies, and standards are consistent with system security requirements defined in contractual, legal, and other service level agreements and applicable laws and regulations.

S1.4: Responsibility and accountability for system security have been assigned.

S1.5: Documented system security objectives, policies, and standards are communicated to entity personnel responsible for implementing them.


Category S2: – The entity utilizes processes, people,

software, data, and infrastructure to achieve system security objectives in accordance with established policies and standards.


S2.1: Acquisition, implementation, configuration and management of system components related to system security are consistent with documented system security objectives, policies, and standards.

S2.2: There are procedures to identify and authenticate all users accessing the system.

S2.3: There are procedures to grant system access privileges to users in accordance with the policies and standards for granting such privileges.

Security Principle Security Principle (cont.)(cont.)

S2.4: There are procedures to restrict access to computer processing output to authorized users.

S2.5: There are procedures to restrict access to files on off-line storage media to authorized users.

S2.6: There are procedures to protect external access points against unauthorized electronic access.

S2.7: There are procedures to protect the system against infection by computer viruses, malicious codes, and unauthorized software.

S2.8: Threats of sabotage, terrorism, vandalism and other physical attacks have been considered when locating the system.

Security Principle Security Principle (cont.)(cont.)

S2.9: There are procedures to segregate incompatible functions within the system through security authorizations.

S2.10: There are procedures to protect the system against unauthorized physical access.

S2.11: There are procedures to ensure that personnel responsible for the design, development, implementation and operation of system security are qualified to fulfil their responsibilities.


Category S3: – The entity monitors the system and

takes action to achieve compliance with system security objectives, policies, and standards.


S3.1: System security performance is periodically reviewed and compared with documented system security requirements of authorized users and contractual, legal, and other service level agreements.

S3.2: There is a process to identify potential impairments to the system’s ongoing ability to address the documented security objectives, policies, and standards, and to take appropriate action.

S3.3: Environmental and technological changes are monitored and their impact on system security is periodically assessed on a timely basis.

Principle: IntegrityPrinciple: Integrity

System processing is complete, accurate, timely and authorized.

Integrity PrincipleIntegrity Principle

Category I1: – The entity has defined and

communicated performance objectives, policies, and standards for system processing integrity.


I1.1: The system processing integrity requirements of authorized users and the system processing integrity objectives, policies, and standards are identified and documented.

I1.2: Documented system processing integrity objectives, policies, and standards have been communicated to authorized users.

I1.3: Documented system processing integrity objectives, policies, and standards are consistent with system processing integrity requirements defined in contractual, legal, and other service level agreements and applicable laws and regulations.

Integrity Principle Integrity Principle (cont.)(cont.)

I1.4: There is assignment of responsibility and accountability for system processing integrity.

I1.5: Documented system processing integrity objectives, policies, and standards are communicated to entity personnel responsible for implementing them.


Category I2: – The entity utilizes processes, people,

software, data, and infrastructure to achieve system processing integrity objectives in accordance with established policies and standards.


I2.1: Acquisition, implementation, configuration and management of system components related to system processing integrity are consistent with documented system processing integrity objectives, policies, and standards.

I2.2: The information processing integrity procedures related to information inputs are consistent with the documented system processing integrity requirements.

I2.3: There are procedures to ensure that system processing is complete, accurate, timely, and authorized.

Integrity Principle Integrity Principle (cont.)(cont.)

I2.4: The information processing integrity procedures related to information outputs are consistent with the documented system processing integrity requirements.

I2.5: There are procedures to ensure that personnel responsible for the design, development, implementation and operation of the system are qualified to fulfil their responsibilities.

I2.6: There are procedures to enable tracing of information inputs from their source to their final disposition and vice versa.


Category I3: – The entity monitors the system and

takes action to achieve compliance with system integrity objectives, policies, and standards.


I3.1: System processing integrity performance is periodically reviewed and compared to the documented system processing integrity requirements of authorized users and contractual, legal and other service level agreements.

I3.2: There is a process to identify potential impairments to the system’s ongoing ability to address the documented processing integrity objectives, policies, and standards and take appropriate action.

I3.3: Environmental and technological changes are monitored and their impact on system processing integrity is periodically assessed on a timely basis.

Principle: MaintainabilityPrinciple: Maintainability

The system can be updated when required in a manner that continues to provide for system availability, security, and integrity.

Maintainability PrincipleMaintainability Principle

Category M1: – The entity has defined and

communicated performance objectives, policies, and standards for system maintainability.


Category M2: – The entity utilizes processes, people,

software, data, and infrastructure to achieve system maintainability objectives in accordance with established policies and standards.


Category M3: – The entity monitors the system and

takes action to achieve compliance with maintainability objectives, policies, and standards.

SysTrust!SysTrust!

SysTrust Introduction SYSTRUST COURSE February 2001.

Documents

Transcript of SysTrust Introduction SYSTRUST COURSE February 2001.