"knowledge in is/it processes and standards" advisor ： dr. celeste ng reporters ：...

"Knowledge in IS/IT processes and

standards"

Advisor ： Dr. Celeste Ng

Reporters ： GROUP 4

1

Overview

ISO 15408 IEEE 1540 IEEE 1219 BS 7799 ISO 20000 ITIL ISO 15288 CMMI COBIT

2

………...4-23

……….24-38

……….39-50

……….51-70

……….71-90

……..91-129

……130-144

……145-159

……160-184

Introduction

What is the standard? What the standard doing? How to certificate the standard? Q&A

3

ISO15408(Common Criteria for Information Technology Security Evaluation)


Reporter ： 961623 鐘敏如

4

Introduction

Common Criteria for Information Technology Security Evaluation (abbreviated as Common Criteria or CC) is an international standard (ISO 15408). It is currently in version 3.1.

The CC is useful as a guide for the development, evaluation and/or procurement of IT products with security functionality.

5

Production Certified by CC Access Control Devices and Systems Biometric Systems and Devices Boundary Protection Devices and Systems Data Protection Databases Detection Devices and Systems ICs, Smart Cards and Smart Card related Devices and Systems Key Management Systems Network and Network related Devices and Systems Operating systems Other Devices and Systems Products for Digital Signatures Trusted Computing

6

Evaluation assurance levels

The Evaluation Assurance Levels (EALs) provide an increasing scale that balances the level of assurance obtained with the cost and feasibility of acquiring that degree of assurance.

Seven hierarchically ordered evaluation assurance levels are defined in the CC for the rating of a TOE's assurance. They are hierarchically ordered inasmuch as each EAL represents more assurance than all lower EALs.

TOE-target of evaluation7

Evaluation assurance levels Evaluation assurance level 1 (EAL1) - functionally tested

Evaluation assurance level 2 (EAL2) - structurally tested

Evaluation assurance level 3 (EAL3) - methodically tested and checked

Evaluation assurance level 4 (EAL4) - methodically designed, tested, and reviewed

Evaluation assurance level 5 (EAL5) - semiformally designed and tested

Evaluation assurance level 6 (EAL6) - semiformally verified design and tested

Evaluation assurance level 7 (EAL7) - formally verified design and tested

8

Evaluation assurance level 1 (EAL1) - functionally tested

EAL1 is applicable where some confidence in correct operation is required, but the threats to security are not viewed as serious.

EAL1 requires only a limited security target.

EAL1 provides an evaluation of the TOE as made available to the customer, including independent testing against a specification, and an examination of the guidance documentation provided. 9

Evaluation assurance level 2 (EAL2) - structurally tested

This EAL represents a meaningful increase in assurance from EAL1 by requiring developer testing, a vulnerability analysis (in addition to the search of the public domain), and independent testing based upon more detailed TOE specifications.

Developers or users require a low to moderate level of independently assured security.

10

Evaluation assurance level 3 (EAL3) - methodically tested and checked

This EAL represents a meaningful increase in

assurance from EAL2 by requiring more complete testing coverage of the security functionality and mechanisms and/or procedures that provide some confidence that the TOE will not be tampered with during development.

11

Evaluation assurance level 3 (EAL3) - methodically tested and checked (cont.)

Developers or users require a moderate level of independently assured security, and require a thorough investigation of the TOE and its development without substantial re-engineering.

12

Evaluation assurance level 4 (EAL4) - methodically designed, tested, and reviewed

EAL4 permits a developer to gain maximum assurance from positive security engineering based on good commercial development practises which, though rigorous, do not require substantial specialist knowledge, skills, and other resources.

13

Evaluation assurance level 4 (EAL4) - methodically designed, tested, and reviewed (cont.)

This EAL represents a meaningful increase in assurance from EAL3 by requiring more design description, the implementation representation for the entire TSF.

Developers or users require a moderate to high level of independently assured security and are prepared to incur additional security-specific engineering costs.

TSF- TOE security functionality 14

Evaluation assurance level 5 (EAL5) - semiformally designed and tested

This EAL represents a meaningful increase in assurance from EAL4 by requiring semiformal design descriptions, a more structured (and hence analysable) architecture, and improved mechanisms and/or procedures that provide confidence that the TOE will not be tampered with during development.

15

Evaluation assurance level 5 (EAL5) -

semiformally designed and tested (cont.)

EAL5 permits a developer to gain maximum assurance from security engineering based upon rigorous commercial development practises supported by moderate application of specialist security engineering techniques.

16

Evaluation assurance level 6 (EAL6) - semiformally verified design and tested

This EAL represents a meaningful increase in assurance from EAL5 by requiring more comprehensive analysis, a structured representation of the implementation, more architectural structure (e.g. layering), more comprehensive independent vulnerability analysis, and improved configuration management and development environment controls.

17

Evaluation assurance level 6 (EAL6) - semiformally verified design and tested (cont.)

EAL6 permits developers to gain high assurance from application of security engineering techniques to a rigorous development environment in order to produce a premium TOE for protecting high value assets against significant risks.

18

Evaluation assurance level 7 (EAL7) - formally verified design and tested

EAL7 is applicable to the development of security TOEs for application in extremely high risk situations and/or where the high value of the assets justifies the higher costs.

This EAL represents a meaningful increase in assurance from EAL6 by requiring more comprehensive analysis using formal representations and formal correspondence, and comprehensive testing.

19

Certification

Step1-Vendor (applicant) applies for evaluation to evaluation laboratory.

Step2- Evaluation laboratory and the certification body confirm with the vendor regarding target of evaluation and security level.

Step3- Vendor provides products and related documents to laboratory for evaluation.

20

Certification(cont.)

Step4- Certification body certifies the evaluation results .

Step5- A Common Criteria Certificate will be issued by certification body if all reports concerning evaluation and certification have been confirmed for accuracy and consistency.

21

Reference

http://www.commoncriteriaportal.org/ http://www.ttc.org.tw/english/index_e.asp

22

Q&A

Thanks

23

IEEE Std 1540

Standard for Software Life Cycle Processes

— Risk Management

Advisor ： Dr. Celeste NgReporter ： 961642 謝孟潔

24

Introduction

□ What is IEEE Std 1540 do? IEEE Std 1540 defines a process for the management of risk throughout the software life cycle.

□ Field of application

It is suitable for adoption by an organization for application to all appropriate projects or for use in an individual project.

□ Risk management in the software life cycle

To identify and mitigate the risks continuously.

Although the standard is written for the management of risk in software projects, it may also be useful for the management of both system-level and organization-level risks.

25

□ Risk management process The risk management process is a continuous process for systematically addressing risk throughout the life cycle of a product or service.

1. Plan and implement risk management

‧ Activities contained:

Process in detail

2. Manage the project risk profile

3. Perform risk analysis

4. Perform risk monitoring

5. Perform risk treatment

6. Evaluate the risk management process

26

Figure - Risk management process model (informative)

Process in detail

27

Define the information requirements the risk management process must support.

Process in detail

28

• Establish risk management policies• Establish the risk management process.• Establish responsibility• Assign resources• Establish the risk management process evaluation

Plan and implement risk management

Process in detail

29

• Define the risk management context• Establish risk thresholds• Establish and maintain the project risk profile• Communicate risk status

Manage the project risk profile

Process in detail

30

• Risk identification• Risk estimation• Risk evaluation

Perform risk analysis

Process in detail

31

• Selecting risk treatment• Risk treatment planning and implementation

Perform risk treatmentProcess in detail

32

• Monitor risk• Monitor risk treatment• Seek new risks

Perform risk monitoring

Process in detail

33

• Capture risk management information• Assess and improve the risk management process• Generate lessons learned

Evaluate the risk management process

Process in detail

34

• Potential problems will be identified

□ By successfully implementing this risk management standard

• The likelihood and consequences of these risks will be understood

• The priority order in which risks should be addressed will be established

• Treatment alternatives appropriate for each potential problem above

its risk threshold will be recommended

• Appropriate treatments will be selected for risks above their thresholds

• The effectiveness of each treatment will be monitored

• Information will be captured to improve risk management policies

• The risk management process and procedures will be regularly evaluated

and improved

Summary

35

□Relevant standards

‧IEEE/EIA 12207.0-1996, IEEE/EIA Standard —Industry Implementation of International Standard ISO/IEC12207:1995, Standard for Information Technology —Software Life Cycle Processes

‧IEEE Std 610.12-1990, IEEE Standard Glossary of Software Engineering Terminology.

‧ISO/IEC 15026:1998, Information Technology—System and Software Integrity Levels.

‧ISO/IEC 16085:2006, Systems and software engineering -- Life cycle processes -- Risk management.

‧IEEE 16085, Systems and software engineering Life cycle processes Risk management.

Relevant standards

36

□Reference‧IEEE Standard for Software Life Cycle Processes—Risk Management

── Copyright © 2001 by the Institute of Electrical and Electronics Engineers, Inc.

‧IEEE 1540 – Software Engineering Risk Management: Measurement-Based Life Cycle Risk Management ── PSM 2001 Aspen, Colorado.

‧A Comparative Review of Risk Management Standards── Risk Management: An International Journal 2005, 7 (4), 53.66.

‧ISO/IEC 12207 Systems and software engineering — Software life cycle processes── Copyright © 2008 ISO/IEC-IEEE.

‧International Standardization in Software and Systems Engineering ── CROSSTALK - The Journal of Defense Software Engineering, Feb 2003 Issue.

□Certification

• Purposes

• Guidance and advice

37

Q&A

Thanks

38

IEEE 1219-1998

Institute of Electrical and Electronic Engineers-Standard for Software Maintenance

Approved 25 June 1998 ---IEEE-SA Standards Board


Reporter ： 961653 陳沛諭

39

What is IEEE 1219 ?

Standard describes the process for managing and executing software maintenance activities

• Comprised of 7 phases– Problem Identification – Analysis– Design– Implementation– System Test– Acceptance Test– Delivery

Process Name

Control

Input Output

40

Problem Identification

Change Request ValidatedChange Request

Uniquely Identify Change RequestEnter Request into Repository

Assign ID numberClassify type of maintenancePreliminary EstimatePrioritize ModificationAssign an MR to modification schedules

MR=Modification Request 41

Analysis

Validated Change RequestSystem DocumentationRepository Information

Feasibility ReportDetailed Analysis ReportUpdated RequirementsPreliminary Modification ListTest StrategyImplementation Plan

Conduct Tech ReviewVerify Documentation UpdateVerify Test StrategyIdentify Safety and Security Issues

Feasibility AnalysisDetailed Analysis

42

Design

Analysis Phase OutputSystem DocumentationSource Code, Database

Revised Modification ListUpdated Design BaselineUpdated Test PlanRevised Detailed AnalysisVerified RequirementsDocumented Constraints and Risks

Conduct software InspectionVerify Design is DocumentedComplete Traceability of Requirement to Design

Identify affected modulesModify module documentationCreate Test CasesIdentify documentation update

requirements

43

Implementation

Results of Design PhaseSystem DocumentationProject DocumentationSource Code, Database

Updated software and documentsStatement of RiskTest-Readiness Review Report

Conduct software InspectionEnsure that unit and integration testing are preformed

Coding and unit testingIntegrationRisk analysisTest-readiness review

44

System Test

Updated software documentsTest-Readiness Review ReportUpdated System

Tested Fully Integrated SystemTest ReportsTest-Readiness Review Report

Place under SCM: Software code, MRs, Test Documentation

System functional testInterface testingRegression TestingTest-readiness review

Regression Testing=Retesting to detect faults introduced by modificationSCM=Software configuration managementMR=Modification Request

45

Acceptance Test

Fully Integrated SystemTest-Readiness Review ReportAcceptance Test PlansAcceptance Test CasesAcceptance Test Procedures

New System BaselineFCA ReportAcceptance Test Report

Execute Acceptance TestsReport Test ResultsConduct Functional AuditEstablish New BaselinePlace Acceptance Test Documentation Under SCM

Functional acceptance testsInteroperability testingRegression testing

FCA= Functional Configuration Audit 46

Delivery

Tested/Accepted System

PCAVersion Description Document

Arrange Physical Configuration AuditComplete Version Description DocumentComplete Updates to Status Accounting Database

Conduct PCANotify user communitySystem for backupInstallation and train customer

PCA=physical configuration audit47

IEEE Certification- about software maintain

CDSA:

Knowledge Area of CDSA exam % of questions on exam

Software Requirements 7%Software Design 8% Software Construction 10%Software Testing 7%Software Maintenance 7%Software Configuration Management 3%Software Engineering Management 3%Software Engineering Process 4%Software Engineering Methods 5%Software Quality 6%Software Engineering Professional Practice 7%Software Engineering Economics 3%Computing Foundations 10%Mathematical Foundations 10%Engineering Foundations 10% total 100%

48

Reference material

IEEE Software Certification Meets New Standard --BY MARILYN G. CATIS

http://www.ieee.org/portal/site/tionline/menuitem.130a3558587d56e8fb2275875bac26c8/index.jsp?&pName=institute_level1_article&TheCat=1010&article=tionline/legacy/inst2009/jan09/prodservcommsoc.xml&

IEEE http://www.ieee.org/index.html?WT.mc_id=hpf_logo

CDSA-- Certification and Training for Software Professionalshttp://www.computer.org/portal/web/certification/home

Document downloadhttp://www.epegypt.com/library/files/books/IEEE_Specifications/ANSI_IEEE_CD1/IEEE_Std_1219-1998.pdf

49

Q&A

Thanks

50

BS 7799/ISO 17799

Code of Practice for InformationSecurity


Reporters ： 961663 蘇域灝

51

What is information security?

confidentialityensuring that information can only be accessed by those with the proper authorization.

integritysafeguarding the accuracy and completeness of information and the ways in which it is processed.

availabilityensuring that authorized users have access to information and associated assets whenever required.

Evolution

Destination:Establishing an effective Information Security Management System.Enable companies to manage information security.

PART1 PART2

Code of practice for information security management.

ISMS Information Security Management Systems-Specification with guidance for use.

What is BS7799?

ASPECT: Technical PhysicalOrganizational

Compliance

Asset Classificationand Control

Security Policy

OrganizationalSecurity

System Developmentand Maintenance

Business ContinuityManagement

AccessControl

Personnel Security

Communication andOperations Management

Physical andEnvironmental Security

organizational

operational

BS7799 part-1

BS7799 part-110 Domain(1)

1. Provide guidelines and management advice for improving information security.

2. Facilitate information security management within the organization.

3. Carry out an inventory of assets and protect these assets effectively.

Security Policy

OrganizationalSecurity

Asset Classificationand Control


4. Minimize the risks of human error, theft, fraud or the abusive use of equipment.

5. Prevent the violation, deterioration or disruption of industrial facilities and data.

6. Ensure the adequate and reliable operation of information processing devices.

Personnel Security

Communication andOperations Management

Physical andEnvironmental Security


7. Control access to information.

8. Ensure that security is incorporated into information systems.

9. Minimize the impact of business interruptions and protect the company’s essential processes from failure and major disasters.

System Developmentand Maintenance

Business ContinuityManagement

AccessControl


10. Avoid any breach of criminal or civil law, of statutory or contractual requirements, and of security requirements.

Enable audition maximize its effectiveness.

Compliance

BS 7799 Part 2

specifications with guidance for use provides recommendations for establishing an

effective

To establish the organization’s information security policy and objectives... and then meet these objectives.An Information Security Management System (ISMS) provides a systematic approach to managing sensitive information in order to protect it.It encompasses employees, processes and information systems.

PDCA model in BS 7799

The core of information security is risk assessment&risk treatment.

Risk ： It is the loss when the asset(information) cannot provide services.

Risk = Value * Threat * Weakness * Incidence

RISK MANAGEMENTNo Threat Description of the risk Comment1 Hackers2 Information theft3 Industry espionage4 Virus5 Intentional erasure6 Unintentional erasure7 Awareness8 Power failure

Identify Process Harm

PossibilityEstimation

SeverityEstimation

ReplacementEstimation

Let Down theRisk Happened

Estimate the Risk

Happened

CauseAnalysis

Result Analysis

Implementing an ISMS includes 8 steps.

The firm who imports BS7799

Over 80 000 firms around the world are BS 7799 / ISO 17799 compliant, including:

- 內政部警政署入出境管理局 - 土地銀行 - 宏碁資訊管理中心 - 中央健保局 - 台灣大哥大 - 淡大資訊中心、中央大學電算中心

Accredited Bodies

-AJA Registrars Limited

-BSI trading as BSI Management Systems and BSI Product Services

-China Certification Center Inc

-Japan Quality Assurance Organization

(p.s. 稽核員考試 )

Conclusion

It is the correct attitude that ensuring

information security in the enjoyment

of using information under convenience.

Therefore, we must make information security

protection measures.

Reference ICST( 行政院國家資通安全會報 - 技術服務中心 - 資安論壇 )

http://forum.icst.org.tw/ NCKU’s ICSC( 成大資通安全研究中心 )

http://www.icsc.ncku.edu.tw/ The White Paper of BS7799

www.callio.com/files/wp_iso_en.pdf United Kingdom Accreditation Service

http://www.ukas.com/ TAF( 財團法人全國認證基金會 )

http://www.cnla.org.tw/tafweb/index.aspx

Q&A

Thanks

70

ISO/IEC20000Information Technology Service

Management


Reporter ： 961607 周慧鈴

71

Introduction

The ISO 20000 standard (IT quality control standard) focuses on managing IT issues via a helpdesk: problems are classified, helping identify on-going issues or inter-linkages. Standardization in IT service management also considers system capacity, levels of management required when the system changes, financial budgeting, software control and distribution.

72

ISO/IEC 20000 consists of two parts

• ISO/IEC 20000 Part 1: Specification for Service Management ISO 20000-1 is a formal specification and defines the

requirements for an organization to deliver managed services of an acceptable quality for customers.

• ISO/IEC 20000 Part 2: Code of Practice for Service Management ISO 20000-2 is a Code of Practice that describes the

best practices for Service Management processes within the scope of ISO20000-1.

73

Graph

74

Service delivery process

Service Level Management The service level management monitors and reports on

service level , and holds customer reviews

Service Reporting To produce timely, reliable, accurate reports for informed

decision making and effective communication.

Service Continuity and Availability To ensure that the agreed objectives of availability and

continuity for the customer can be met in every case.

76

Service delivery process (cont.) Capacity Management The capacity management ensures that the service

provider has sufficient capacities permanently available in order to meet the current and future agreed business resource needs.

Information Security Management The objective of the information security management is to

provide effective control and monitoring of the information security for all service activities.

Budgeting and Accounting Management The aim of budgeting and accounting for IT services is

to budget for and provide documentary evidence of the costs for service provision.

77

Relationship processes Business Relationship Management The aim of business relationship management is to

understand the customer and the business process drivers and based on this to establish and maintain a good relationship between the service provider and the customer.

Supplier Management The aim of supplier management is to control

suppliers in order to ensure a smooth delivery of high quality services.

79

Resolution processes Incident Management The aim of incident management is to restore the

agreed service for the business and respond to service enquiries as quickly as possible.

Problem Management The aim of problem management is to minimize the

disruption to and impact on the business by proactively identifying and analyzing the root causes of service incidents and by managing problems until these are rectified.

81

Control processes

Configuration Management To define and control the components of the

service and infrastructure and maintain accurate configuration information.

Change Management To ensure that the use of standardized methods

to efficiently and expeditiously deal with the change

83

Release processes

Release Management Release management should be integrated

into the configuration and change management processes in order to ensure that the releases and implemented changes are coordinated.

85

Certification How is Certification Achieved? It requires adoption of the requirements of the

standard, and demonstration of adherence via audit by a third party, which is known as a certification body.

Who are the Certification Bodies? There are a growing number of accredited

certification bodies. Examples include BSI, Certification Europe Ltd, DNV, DQS, Japan Quality Assurance Organization, LRQA, SGS, STQC and TUV.

86

Steps to ISO 20000 Certification? Step1 - Create awareness

Communicate the goals and benefits of the ISO 20000 certification and the approach for achieving ISO 20000 compliance.

Step2 - Determine the ISO 20000 certification scope

Decide what parts of the organization, what services and/ or what locations shall be covered by the ISO 20000 certificate.

Step3 - Conduct an initial ISO 20000 assessment Determine gaps between today’s situation and the standard's

requirements. 87

Steps to ISO 20000 Certification?

Step4 - Set up the ISO 20000 project Choose a project manager and project staff. Determine the

necessary resources, prepare a project plan and assign tasks. Step5 - Conduct the ISO 20000 certification audit The actual ISO 20000 audit must be carried out by an external

certifier from a Registered Certification Body Step6 - Maintain ISO 20000 Certification The expiration date of Certification is three years. Make sure

that you continue to adhere to the standard and put a strong emphasis on continual service and process improvement.

88

Reference

http://www.itil.org/en/vomkennen/iso20000/servicedeliveryprozesse/index.php

http://en.it-processmaps.com/iso20000/faq-iso-20000-certification.html#ISO 20000 Audit

http://www.tw.sgs.com/zh_tw/home_tw_v2

89

Q&A

Thanks

90

ITIL, Service Support and Service

Delivery Information Technology Infrastructure

Library


Reporter ： 961619 黃柏菁

91

ITIL is a set of concepts and practices for Information Technology Services

Management (ITSM), IT development and IT operations.

ITIL is the most widely accepted approach to IT service management in the world.

92

Processes of Service Support

1.Service Desk and Incident Management

2.Problem Management

3.Change Management

4.Release Management

5.Configuration Management

93

Processes of Service Desk and Incident Management

Register Incident

Maintenance of Support

Knowledge Base

Carry out Incident Management

Reporting

Problem Management

Immediate Incident Resolution by

1st Level Support

Pro-Actively Inform Users

Monitor and Escalate

Incidents

Process Service Request

Close and Evaluate Incident

Analyse and Resolve Incident in 2nd Level Support

94

Register Incident


Knowledge Base


Reporting

Problem Management


1st Level Support



Incidents





The Incident shall be recorded

and documented in appropriate quality, in order to facilitate

a swift and effective solution.

Register Incident

An Incident of the type Service Request is to

be completely processed within the

agreed resolution time.


The processing status of outstanding Incidents is

to be continuously monitored, so that

counter-measures may be introduced as soon as possible if Service Levels are likely to be breached.

Monitor and Escalate Incidents

The users are to be informed of detractions to the IT Services as soon as

these are known to the Service Desk


95


Register Incident


Knowledge Base


Reporting

Problem Management


1st Level Support



Incidents




An Incident of the type Service interruption is to be solved within the agreed solution period.

The aim is the fast recovery of the IT

Service, where necessary with the aid

of a Workaround.

Immediate Incident Resolution by 1st Level

Support If possible, the root cause of the Service interruption should be corrected, or at least a Workaround applied.

Analyse and Resolve Incident in 2nd Level

Support

96


Register Incident


Knowledge Base


Reporting

Problem Management


1st Level Support



Incidents




Before the final closure of the

Incident, it is to be submitted to a

quality-control with regards to the

resolution.

Findings from the processing of Incidents as well as information from

other Service Management Processes are to be incorporated into the

Support Knowledge Base in a structured and quality-

assured manner

It is to be ensured that improvement potentials are derived from past

Incidents.


Maintenance of Support Knowledge Base

Carry out Incident Management Reporting

97

Processes of Problem Management

Identify and Analyse Problem

Monitor Problems and Errors

Identify Problem Solution

Develop Problem Solution

Close Problem

Compile Problem Management Reporting

Change Management

Release Management

98






Close Problem


Past Incidents and other indications of problems in the IT

infrastructure are to be analysed, in

order to find the root causes of

repeatedly occurring IT Service

interruptions. It is to be ensured that the other IT Service

Management processes as well as IT Management are informed of outstanding

Problems, their processing-status and existing Workarounds.

Outstanding Problems are to be continuously monitored with regards

to their processing status, so that where necessary corrective measures

may be introduced.

A resolution is to be found for identified Problems and a

corresponding RFC, initiating the implementation of the resolution, is

to be compiled. Identify and Analyse Problem




99






Close Problem Change Management

Release Management

It is to be ensured that the knowledge gained is made

available to the other IT Service Management processes, in order to be used for the handling of future

Problems or Incidents.

After the clearance of the Change the actual error-correction is to be

developed and subsequently transfered to Release Management

for Rollout.


Close Problem

100

Processes of Change Management

Set Rules for the Handling of Standard Changes

Pre-Evaluate RFC

Clearance of Change by the Change Manager

Register and Classify Change

Group Changes into Releases

Evaluate Change

Handling of Urgent Change by Emergency Committee (EC)

Hold CAB Meeting

Security Management

Release Management

101



Pre-Evaluate RFC




Security Management

Release Management

It is to be ensured, that only RFC which are in accordance with the defined quality requirements are

accepted into the Change Management Process Quickest possible clearance

or rejection of an Urgent Change, which is to serve to

fight an emergency.

Registration and categorization of RFCs/ Changes, so that only documented RFCs gain access

into the process and are assigned to the correct and appropriate body (Change

Manager, CAB, or EC)

For this purpose it is determined, how these Changes are handled.

RFC= Request for Change

EC =Emergency Committee


Pre-Evaluate RFC



102


Pre-Evaluate RFC



Evaluate Change


Hold CAB Meeting

Security Management

Release Management

Appraisal of the process and the results of the

Change-implementation.

Approved Changes are to be grouped into Releases; the

clearance for the Rollout is to be issued by Change Management.

Clearance or rejection of a

Change, in addition to preliminary

scheduling and incorporation into the FSC (Forward

Schedule of Changes).

Clearance or rejection of a Change as well as preliminary scheduling and

incorporation into the FSC (Forward Schedule of Changes).


Hold CAB Meeting


Evaluate Change

Security Management

The ITIL-process Security Management describes the structured

fitting of information security in the management organization.

103

Processes of Release Management

Plan Rollout Develop Distribution and Back-out Procedures

Test Release

Carry out Rollout

104



Test Release

Carry out Rollout

Development of technical and/ or organisational procedures for the distribution of the new Release

components.

Planning of the Rollout in detail and devising the necessary technical concepts for the

distribution of the Release.

Plan Rollout

Develop Distribution and Back-out Procedures

105



Test Release

Carry out Rollout

Rolling-out of the Release components into the productive IT environment and ensuring that the Rollout was successful.

The Release components and the distribution and back-out

procedures are to be submitted to a realistic test

Test Release

Carry out Rollout

106

Processes of Configuration Management

Define and Update CMDB Structure

Identify and Document CI Status

Carry out CMDB Audits

Supply Information Regarding CIs

107






The structure of the CMDB is to be defined and updated in such a way,

that it can hold the necessary information related to CIs, including their attributes and relationships.

Carrying out of updates in the CMDB as a reaction to changes to the IT

infrastructure.

CMDB=Configuration Management Database

CI =Configuration Item Record



108










Regular checking of contents of the CMDB.

Make available information regarding CIs as required by the other IT Service Management

Processes.



109

Processes of Service Delivery

1. Service Level Management 2. Availability Management 3. Capacity Management 4. IT Service Continuity Management 5. Financial Management for IT

Services

110

Processes of Service Level Management

Maintain Structures for Service Level Management

Define Service Requirements

Create ServiceSpecification Sheet

Negotiate and agree Contractual Regulations for the Service

Prepare Service Implementation

Commission Service Implementation

Carry out Service Level Reporting

Process Complaints and Carry out SLA Reviews

Change Management

ICT Infrastructure Management

Application Management

Release Management

111








The multitude of documents used within

Service Level Management are to be

adjusted in such a manner, that they correspond to the

requirements of new or changed IT Services.

Investigation of the agreed Service Levels, in order to ensure that

the SLAs are still adequate for client

requirements;

It is to be given account of the attained Service

quality as well as potential counter-measures for the

correction of infringements to the agreed Service

Levels.

Requirements from the client viewpoint with regards to a new or

altered IT Service are to be documented and submitted to an

initial evaluation.

SLA =Service Level Agreement





112







Create Service

Specification Sheet

The requirements of a new or altered IT Service are described in more detail, and specifications are drawn up as to how the Service is created from an IT viewpoint and how the invoicing takes place.


Finalisation of binding agreements to an IT Service between the IT Organisation and the client-side.


Identification of preconditions, which must be established for the implementation of the new or altered Service.

113





Change Management



Release Management


ITC Infrastructure Manager

The ITC Infrastructure Manager is responsible

for the provision and operation of certain

infrastructure components.

Application Manager

The Application Manager is responsible for the creation, upgrading and supporting of an application or application-

class.


After clearance of the Change, the

implementation of the IT Service is to be planned in further detail;

114

Processes of Availability Management


Change Management

Release Management


Define Guidelines for High Availability

Identify Need for Action with Regards to Availability

Compile Availability Improvement Plan

Commission Measures for the Increase in Availability

Monitor Availability

Carry out Availability Reporting

115



Definition of guidelines for applications and

infrastructure components


Analysis of availability levels required within the SLAs, and identification of

areas within the IT infrastructure where action is needed in order to

ensure sufficiently high availability.





Design of concrete suggestions for measures aimed at the increase in

availability

116



Monitoring of the availabilities agreed within the SLAs and where

necessary, identification of needs for action for ensuring the agreed Service

Levels.




Reporting on the adherence to availability agreements, and on

counter-measures for the correction to occurred infringements or projected

availability issues.

117

Processes of Capacity anagement


Change Management

Release Management


Forecast the Future Demand for IT Capacities

Compile Capacity Plan

Commission Optimisation Measuresfor IT Capacities

Monitor IT Capacities

Carry out Capacity Reporting

118

Forecast the Future Demand for IT Capacities

Compile Capacity Plan

Monitor IT Capacities


Processes of Capacity anagement

Forecast the Future Demand for IT Capacities The future demand is to be estimated upon the basis of performance and capacity-

utilization measurements, in addition to information from the

client-side.

Compile Capacity Plan Design of concrete

measures for the adjustment of IT capacities in reaction to

infringements to performance and capacity

agreements

Monitor IT Capacities Monitoring of

performance and IT capacities agreed upon in the SLAs and where

necessary.


To Performance and Capacity agreements, and on counter-measures for the correction to occurred infringements or

projected shortages related to the agreed Service Levels. 119

Processes of IT Service Continuity anagement


Change Management

Release Management


Create IT Service Continuity Plan

Carry out ITSCM Risk Analysis

Determine Technical Measures for Containing Risks

Commission Measures for the Increase in Availability

Carry out Organisational Measures for Containing Risks

Practice the Event of Disaster

Carry out ITSCM Reporting

120



Identification of the risks from a business viewpoint and linking those risks to IT Services and infrastructure

components

Create IT Service Continuity Plan Identification of measures with the aim of being prepared for potential disasters; establishment of the organizational conditions for disaster

precaution.






Determination of concrete technical measures in order to reduce the risks in association with events of disaster; compilation of corresponding RFCs 121




Carry out ITSCM Reporting



Definition and implementation of organisational measures in order to be prepared for the event of a

disaster.


The prepared arrangements for the event of a disaster are to be submitted

to a realistic test, in order to confirm that these arrangements are functional

and sufficient.

Carry out ITSCM Reporting Reporting on changes to the risk-

situation as well as on the status of counter-measures for the preparation

for disaster events. 122

Processes of Financial Management for IT Services

Define Structures for Financial Management

Carry out Budget Planning Session

Operational Administration of IT Budget

Allocate Costs for the Provision of IT Services

Issue Invoice for ITServices

Carry out Financial Management Reporting

Optimise Costs of Providing IT Services

123








Define the structures necessary for the management of financial planning data and costs, as well as for the allocation of costs to IT

Services.

Carry out Budget Planning Session Carrying out the budget planning session for a

particular planning period, taking into account the

interests of business and IT

organisation

Allocate Costs for the Provision of IT

Services Allocation of the costs incurred within the IT organisation, so that these can be apportioned to the individual IT Services.

124


Operational Administration of IT Budget



Carry out Financial Management Reporting



Operational Administration of IT Budget Monitoring of the actual usage of the IT budget, so that only previously planned

expenditures are made; handling of

unforeseen budget requirements.

Carry out Financial

Management Reporting Reporting on

planned/ actual figures regarding

costs for providing IT Services,

revenues, and IT budget

Issue Invoice for IT

Services Issuing of an invoice for the provision of IT Services and

transmission of this invoice to the

client.

Optimize Costs of Providing IT Services

Identification of potentials for

cost-optimization with regards to

the provision of IT services. 125

ITIL Certification

The ITIL Certification Management Board (ICMB) manages ITIL certification.

EXIN and BCS/ISEB(the British Computer Society) are the examination providers , provide ITIL exams and accredit ITIL training providers .

126

ITIL Certification Path The Foundation Certficate is a proof of

understanding of the itil basis which includes most of itil terminology, terms, concepts and relationships between various ITIL processes

Practitioner Certificate in IT Service Management (ITIL Practitioner) wich is basically the proof of the practical knowledge

ITIL Service Manager certification . This certification proofs the highest skills including theory, practice, experience in ITIL but also communication, negotiation and presentation skills.

127

References http://www.itilcertification.org/ http://en.wikipedia.org/wiki/

Information_Technology_Infrastructure_Library#Certification

http://wiki.en.it-processmaps.com/index.php/ITIL_Processes

128

Q&A

Thanks

129

ISO/IEC 15288(International Standards Organization / Institution of Civil

Engineers)

Systems and software engineering - System life cycle life cycle processes


Reporter ： 961665 佟光杰

130

What is ISO/IEC 15288?

ISO/IEC 15288:2008-System Life Cycle Processes establishes a common framework for describing the life cycle of systems created by humans. It defines a set of processes and associated terminology.

These processes can be applied at any level in the hierarchy of a systems structure.

131

System Life Cycle Processes ISO/IEC 15288

‧ Agreement process

Organizational project-enabling process‧

Project processes‧

Technical processes‧

132

Purpose of the Acquisition Process

The purpose of the Acquisition Process is to obtain a product or service in accordance with the acquirer’s

requirements. Purpose of the Supply Process

The purpose of the Supply Process is to provide an acquirer with a product or service that meets agreed

requirements. 133

Life Cycle Processes Management Process PurposeThe purpose of the System Life Cycle Processes Management Process is to assure that effective system life cycle processes are available for use by the organization.

Purpose of the Investment Management ProcessThe purpose of the Investment Management Process is to initiate and sustain sufficient and suitable projects in order to meet the objectives of the organization.

Investment

Organizationalproject-enabling process

Enterprise

environment

management

Life cycle

model

management

Investment

management

Resource

management

Quality

management

134

Organizational project-enabling process (continue)

Purpose of the Enterprise Environment Management ProcessThe purpose of the Enterprise Environment Management Process is to define and maintain the policies and procedures needed for the organization’s business with respect to the scope of this International Standard.

Purpose of the Resource Management ProcessThe purpose of the Resource Management Process is to provide resources

to projects. Quality Management Process Purpose

The purpose of the Quality Management Process is to assure that products, services and implementations of life cycle processes meet enterprise quality goals and achieve customer satisfaction.

135

The project management processes exist to establish and evolve project plans, to assess progress against the plans and to control execution of the project through to its completion.

The plans are developed to accomplish business objectives and project goals established by the enterprise processes. For large projects, there may be a need to apply the project management process at lower levels. 136

The Technical Processes are used to define the requirements for a system, to transform the requirements into an effective product, to permit consistent reproduction of the product where necessary, to use the product to provide the required services, to sustain the provision of those services and to dispose of the product when it is retired from service.

137

System Stages of 15288 Concept

The Concept Stage is executed to assess new business opportunities and to develop preliminary system requirements and a feasible design

DevelopmentThe Development Stage is executed to develop a system-of-interest that meets acquirements and can be produced, tested,

evaluated, operated, supported and retired. Production

The Production Stage is executed to produce or manufacture the product, to test the product and to produce related supporting and enabling systems as needed. 138

System Stages of 15288(continue)

UtilizationThe Utilization Stage is executed to operate the product, to deliver services within intended environments and to ensure continued operational effectiveness.

SupportThe Support Stage is executed to provide logistics, maintenance, and support services that enable continued system-of-interest operation and a sustainable service.

RetirementThe Retirement Stage is executed to provide for the removal of a system-of-interest and related operational and support services, and to operate and support the retirement system itself.

139

Five Steps to Implement 15288

140

ReferenceISO/IEC 15288 :2008

Systems and software engineering - System life cycle life cycle processes

ISO/IEC 12207:2008

Systems and software engineering - Software life cycle life cycle processes

CNS 15008:2006

Systems engineering - System life cycle processes

143

Q&A

Thanks

144

CMMICapability Maturity Model Integration


Reporter ： 961612 蔡依潔

145

About CMMI

The U.S. Department of Defense entrust Carnegie Mellon University Software Engineering Institute(SEI).

CMMI is a process improvement maturity model for the development of products and services.

It consists of best practices that address development and maintenance activities that cover the product lifecycle from conception through delivery and maintenance.

146

Staged Representation

1. The staged representation offers a systematic, structured way to approach model-based process improvement one stage at a time. 2. To reach a particular level, an organization must satisfy all of the appropriate goals of the process area.

147

Maturity Level

Level 1(Initial)

Level 2 (Managed

)

Level 3 (Defined)

Level4(Quantitatively

Managed)

Level 5 (Optimizing

)

148

Maturity Level (Cont.)

Level 1 : Initial1. Processes are usually ad hoc and chaotic.

2. An inability to repeat their successes.

Level 2 : Managed 1. The projects of the organization have ensured that

processes are planned and executed in accordance with policy.

2. The process discipline helps to ensure that existing practices are retained during times of stress.

149

Maturity Level (Cont.)

Level 3 : Defined1. Processes are well characterized and understood,

and are described in standards, procedures, tools, and methods.

2. The organization’s set of standard processes is established and improved over time

Level 4: Quantitatively Managed 1. Establish quantitative objectives for quality and

process performance and use them as criteria in managing processes

2. Quantitative objectives are based on the needs of the customer, end users, organization, and process implementers. 150

Maturity Level (Cont. )

Level 5 : Optimizing1. Improves its processes based on a quantitative

understanding of the common causes of variation inherent in processes.

2. Continually revised to reflect changing business objectives, and used as criteria in managing process improvement

151

Process Areas

Groups of process areas chosen for process improvement to achieve maturity level 3

152

Evaluation methods

Sub-projects Work items

SCAMPI Pre-evaluation

1. SCAMPI Evaluation plan

2. Training course

3. Implementation of the SCAMPI appraisal

4. Correction of the lack of evaluation and examine

SCAMPI Formal evaluation 1. SCAMPI evaluation plan

2. Examine before the formal evaluation

3. Implementation of the SCAMPI appraisal

The SCAMPI ( Standard CMMI Appraisal Method for Process Improvement) method is used for appraising organizations using CMMI.

157

Reference

http://www.sei.cmu.edu/

158

Q&A

Thanks

159

COBITCOBITControl Objectives for Information and Related

Technology


Reporter ： 961610 王淨嬪

160

COBITCOBIT

Developed (1993) by

the international Information Systems Audit and Control

Association

ISACA

161

COBIT - Introduction

COBIT is an IT governance framework and supporting toolset.

162

Source : COBIT 4.1 Excerpt BOOK

163

Information Criteria

Effectiveness deals with information being relevant and pertinent to the business process as well as being delivered in a timely, correct, consistent and usable manner.

Efficiency concerns the provision of information through the optimal (most productive and economical) use of resources.

Confidentiality concerns the protection of sensitive information from unauthorised disclosure.


164

Information Criteria (cont.)

Integrity relates to the accuracy and completeness of information as well as to its validity in accordance with business values and expectations.

Availability relates to information being available when required by the business process now and in the future. It also concerns the safeguarding of necessary resources and associated capabilities.


165

Information Criteria (cont.)

Compliance deals with complying with those laws, regulations and contractual arrangements to which the business process is subject, i.e., externally imposed business criteria.

Reliability of Information relates to the provision of appropriate information for management to operate the entity and for management to exercise its financial and compliance reporting responsibilities.


166


167

IT RESOURCES

Applications are the automated user systems and manual procedures that process the information.

Information is the data, in all their forms, input, processed and output by the information systems in whatever form is used by the business.

Infrastructure is the technology and facilities that enable the processing of the applications.

People are the personnel required to plan, organise, acquire, implement, deliver, support, monitor and evaluate the information systems and services. They may be internal, outsourced or contracted as required.


168


169

COBIT - Domains

COBIT’s process orientation is demonstrated by the process model which organizes the IT into 34 processes subdivided into 4 domains

1. Plan and organise (PO)

2. Acquire and Implement (AI)

3. Deliver and Support (DS)

4. Monitor and Evaluate (ME)

170

COBIT – Process Model

Domains

Processes

Activities/Tasks

171

COBIT - Domains

Plan and Organise (PO)—Provides direction to solution delivery (AI) and service delivery (DS)

Acquire and Implement (AI)—Provides the solutions and passes them to be turned into services

Deliver and Support (DS)—Receives the solutions and makes them usable for end users

Monitor and Evaluate (ME)—Monitors all processes to ensure that the direction provided is followed


172


173


174


175


176


177


178

Source : COBIT 4.1 Excerpt BOOK179


180

How to certificate the standard?

OneOnePeople who want to certificate the COBIT license to take the COBIT Foundation Certification Exam.

‣Cost : $150 U.S.D.

‣Exam Time : 1hr

‣Questions : 40 Single-Choice Questions(28 questions answered correctly.)

‣Tools : Computer and Network

Source : 資策會 181

How to certificate the standard?

TwoTwo Company who wants

to implement COBIT needs to cooperate with ISACA.

Case Example

182

Sources

BOOK - COBIT® 3rd Edition Control Objectives

BOOK - COBIT® 4.1 Excerpt Executive Summary Framework

Website – ITIL http://www.itil.org/en/vomkennen/cobit/index.php

Website – 資策會 http://www.iiiedu.org.tw/ites/COBIT.htm

Website – ISACA http://www.isaca.org/

183

Q&A

Thanks

184

"knowledge in is/it processes and standards" advisor ： dr. celeste ng reporters ：...

Documents

level of assurance

degree of assurance

toes assurance

tested eal1

evaluation andor procurement

moderate level

systems biometric systems

systems products