Knowledge in IS IT processes and standards Advisor Dr Celeste

"Knowledge in IS/IT processes and standards" Advisor：Dr. Celeste Ng Reporters：GROUP 4 1

Overview l l l l l ISO 15408 IEEE 1540 IEEE 1219 BS 7799 ISO 20000 ITIL ISO 15288 CMMI COBIT ………. . . 4 -23 ………. 24 -38 ………. 39 -50 ………. 51 -70 ………. 71 -90 ……. . 91 -129 …… 130 -144 …… 145 -159 …… 160 -184 2

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

ISO 15408 (Common Criteria for Information Technology Security Evaluation) Advisor：Dr. Celeste Ng Reporter： 961623 鐘敏如 4

Introduction l 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. l 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 l l l l 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 l 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 evaluation l 7

Evaluation assurance levels l Evaluation assurance level 1 (EAL 1) - functionally tested l Evaluation assurance level 2 (EAL 2) - structurally tested l Evaluation assurance level 3 (EAL 3) - methodically tested and checked l Evaluation assurance level 4 (EAL 4) - methodically designed, tested, and reviewed l Evaluation assurance level 5 (EAL 5) - semiformally designed and tested l Evaluation assurance level 6 (EAL 6) - semiformally verified design and tested l Evaluation assurance level 7 (EAL 7) - formally verified design and tested 8

Evaluation assurance level 1 (EAL 1) - functionally tested l EAL 1 is applicable where some confidence in correct operation is required, but the threats to security are not viewed as serious. l EAL 1 requires only a limited security target. l EAL 1 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 (EAL 2) - structurally tested l This EAL represents a meaningful increase in assurance from EAL 1 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. l Developers or users require a low to moderate level of independently assured security. 10

Evaluation assurance level 3 (EAL 3) - methodically tested and checked l This EAL represents a meaningful increase in assurance from EAL 2 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 (EAL 3) - methodically tested and checked (cont. ) l 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 (EAL 4) - methodically designed, tested, and reviewed l EAL 4 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 (EAL 4) - methodically designed, tested, and reviewed (cont. ) l This EAL represents a meaningful increase in assurance from EAL 3 by requiring more design description, the implementation representation for the entire TSF. l 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 (EAL 5) - semiformally designed and tested l This EAL represents a meaningful increase in assurance from EAL 4 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 (EAL 5) - semiformally designed and tested (cont. ) l EAL 5 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 (EAL 6) - semiformally verified design and tested l This EAL represents a meaningful increase in assurance from EAL 5 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 (EAL 6) - semiformally verified design and tested (cont. ) l EAL 6 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 (EAL 7) - formally verified design and tested l EAL 7 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. l This EAL represents a meaningful increase in assurance from EAL 6 by requiring more comprehensive analysis using formal representations and formal correspondence, and comprehensive testing. 19

Certification Step 1 -Vendor (applicant) applies for evaluation to evaluation laboratory. Step 2 - Evaluation laboratory and the certification body confirm with the vendor regarding target of evaluation and security level. Step 3 - Vendor provides products and related documents to laboratory for evaluation. 20

Certification(cont. ) Step 4 - Certification body certifies the evaluation results. Step 5 - 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 l l 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 Ng Reporter： 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. 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. □ Risk management in the software life cycle To identify and mitigate the risks continuously. 25

Process in detail □ Risk management process The risk management process is a continuous process for systematically addressing risk throughout the life cycle of a product or service. ‧ Activities contained: 1. Plan and implement risk management 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

Process in detail 27 Figure - Risk management process model (informative)

Process in detail Define the information requirements the risk management process must support. 28

Process in detail Plan and implement risk management • Establish risk management policies • Establish the risk management process. • Establish responsibility • Assign resources • Establish the risk management process evaluation 29

Process in detail Manage the project risk profile • Define the risk management context • Establish risk thresholds • Establish and maintain the project risk profile • Communicate risk status 30

Process in detail Perform risk analysis • Risk identification • Risk estimation • Risk evaluation 31

Perform risk treatment Process in detail • Selecting risk treatment • Risk treatment planning and implementation 32

Process in detail Perform risk monitoring • Monitor risk treatment • Seek new risks 33

Process in detail Evaluate the risk management process • Capture risk management information • Assess and improve the risk management process • Generate lessons learned 34

Summary □ By successfully implementing this risk management standard • Potential problems will be identified • 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 35

Relevant standards □Relevant standards ‧IEEE/EIA 12207. 0 -1996, IEEE/EIA Standard —Industry Implementation of International Standard ISO/IEC 12207: 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. 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 ── PSM 2001 Aspen, Colorado. Risk Management ‧ISO/IEC 12207 Systems and software engineering — Software life cycle processes ── Copyright © 2008 ISO/IEC-IEEE. ‧A Comparative Review of Risk Management Standards ── Risk Management: An International Journal 2005, 7 (4), 53. 66. ‧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 Advisor：Dr. Celeste Ng Reporter： 961653 陳沛諭 39

What is IEEE 1219 ? l 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 Control Input Process Name Output 40

Problem Identification Uniquely Identify Change Request Enter Request into Repository Change Request Assign ID number Classify type of maintenance Validated Preliminary Estimate Change Request Prioritize Modification Assign an MR to modification schedules MR=Modification Request 41

Analysis Conduct Tech Review Verify Documentation Update Verify Test Strategy Identify Safety and Security Issues Validated Change Request System Documentation Repository Information Feasibility Analysis Detailed Analysis Feasibility Report Detailed Analysis Report Updated Requirements Preliminary Modification List Test Strategy Implementation Plan 42

Design Conduct software Inspection Verify Design is Documented Complete Traceability of Requirement to Design Analysis Phase Output System Documentation Source Code, Database Identify affected modules Modify module documentation Create Test Cases Identify documentation update requirements Revised Modification List Updated Design Baseline Updated Test Plan Revised Detailed Analysis Verified Requirements Documented Constraints and Risk 43

Implementation Conduct software Inspection Ensure that unit and integration testing are preformed Results of Design Phase System Documentation Project Documentation Source Code, Database Coding and unit testing Integration Risk analysis Test-readiness review Updated software and documents Statement of Risk Test-Readiness Review Report 44

System Test Place under SCM: Software code, MRs, Test Documentation Updated software documents Test-Readiness Review Report Updated System functional test Interface testing Regression Testing Test-readiness review Tested Fully Integrated System Test Reports Test-Readiness Review Report Regression Testing=Retesting to detect faults introduced by modification SCM=Software configuration management 45 MR=Modification Request

Acceptance Test Execute Acceptance Tests Report Test Results Conduct Functional Audit Establish New Baseline Place Acceptance Test Documentation Under SCM Fully Integrated System Test-Readiness Review Report Acceptance Test Plans Acceptance Test Cases Acceptance Test Procedures Functional acceptance tests Interoperability testing New System Baseline Regression testing FCA Report Acceptance Test Report FCA= Functional Configuration Audit 46

Delivery Arrange Physical Configuration Audit Complete Version Description Document Complete Updates to Status Accounting Database Tested/Accepted System PCA Conduct PCA Version Description Document Notify user community System for backup Installation and train customer PCA=physical configuration audit 47

IEEE Certification - about software maintain l CDSA: l Knowledge Area of CDSA exam % of questions on exam Software Requirements Software Design Software Construction Software Testing Software Maintenance Software Configuration Management Software Engineering Process Software Engineering Methods Software Quality Software Engineering Professional Practice Software Engineering Economics Computing Foundations Mathematical Foundations Engineering Foundations 7% 8% 10% 7% 7% 3% 3% 4% 5% 6% 7% 3% 10% 10% total 100% 48

Reference material IEEE Software Certification Meets New Standard --BY MARILYN G. CATIS http: //www. ieee. org/portal/site/tionline/menuitem. 130 a 3558587 d 56 e 8 fb 2275875 bac 26 c 8/index. jsp? &p. Name=i nstitute_level 1_article&The. Cat=1010&article=tionline/legacy/inst 2009/jan 09/prodservcommsoc. xml& IEEE http: //www. ieee. org/index. html? WT. mc_id=hpf_logo CDSA-- Certification and Training for Software Professionals http: //www. computer. org/portal/web/certification/home Document download http: //www. epegypt. com/library/files/books/IEEE_Specifications/ANSI_IEEE_CD 1/IEEE_Std_1219 -1998. pdf 49

Q&A Thanks 50

BS 7799/ISO 17799 Code of Practice for Information Security Advisor：Dr. Celeste Ng Reporters： 961663 蘇域灝 51

What is information security? integrity availability safeguarding the accuracy and completeness of information and the ways in which it is processed. ensuring that authorized users have access to information and associated assets whenever required. confidentiality ensuring that information can only be accessed by those with the proper authorization.

Evolution

What is BS 7799? PART 1 Code of practice for information security management. PART 2 ISMS Information Security Management Systems-Specification with guidance for use. Destination: Establishing an effective Information Security Management System. Enable companies to manage information security.

BS 7799 part-1 ASPECT: Organizational Technical Physical organizational Security Policy Organizational Security Asset Classification Access and Control Compliance operational Physical and Environmental Security Communication and Business Continuity Operations Management Personnel Security System Development and Maintenance

BS 7799 part-1 10 Domain(1) l 1. Security Policy Provide guidelines and management advice for improving information security. l 2. Organizational Security Facilitate information security management within the organization. l 3. Asset Classification and Control Carry out an inventory of assets and protect these assets effectively.

BS 7799 part-1 10 Domain(2) l 4. Personnel Security Minimize the risks of human error, theft, fraud or the abusive use of equipment. l 5. Physical and Environmental Security Prevent the violation, deterioration or disruption of industrial facilities and data. l 6. Communication and Operations Management Ensure the adequate and reliable operation of information processing devices.

BS 7799 part-1 10 Domain(3) l 7. Access Control access to information. l 8. System Development and Maintenance Ensure that security is incorporated into information systems. l 9. Business Continuity Management Minimize the impact of business interruptions and protect the company’s essential processes from failure and major disasters.

BS 7799 part-1 10 Domain(4) l 10. Compliance Avoid any breach of criminal or civil law, of statutory or contractual requirements, and of security requirements. Enable audition maximize its effectiveness.

BS 7799 Part 2 l. To establish the organization’s information security policy and objectives. . . and then meet these objectives. l. 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. specifications with guidance for use provides recommendations for establishing an effective

PDCA model in BS 7799

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 MANAGEMENT Description of the risk Comment No Threat 1 Hackers 2 Information theft 3 Industry espionage 4 Virus 5 Intentional erasure 6 Unintentional erasure 7 Awareness 8 Power failure

Cause Analysis Possibility Estimation Estimate the Risk Happened Identify Process Harm Result Analysis Severity Estimation Let Down the Risk Happened Replacement Estimation

Implementing an ISMS includes 8 steps.

The firm who imports BS 7799 Over 80 000 firms around the world are BS 7799 / ISO 17799 compliant, including: l -內政部警政署入出境管理局 l -土地銀行 l -宏碁資訊管理中心 l -中央健保局 l -台灣大哥大 l -淡大資訊中心、中央大學電算中心

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 l l l ICST(行政院 國家資通安全會報 - 技術服務中心 - 資安論壇 ) http: //forum. icst. org. tw/ NCKU’s ICSC(成大資通安全研究中心) http: //www. icsc. ncku. edu. tw/ The White Paper of BS 7799 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/IEC 20000 Information Technology Service Management Advisor：Dr. Celeste Ng Reporter： 961607 周慧鈴 71

Introduction l 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 ISO 20000 -1. 73

Graph 74

75

Service delivery process l Service Level Management The service level management monitors and reports on service level , and holds customer reviews l Service Reporting To produce timely, reliable, accurate reports for informed decision making and effective communication. l 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. ) l 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 l 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 l to budget for and provide documentary evidence of the costs for service provision. 77

78

Relationship processes l 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. l Supplier Management The aim of supplier management is to control suppliers in order to ensure a smooth delivery of high quality services. 79

80

Resolution processes l 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. l 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

82

Control processes l Configuration Management To define and control the components of the service and infrastructure and maintain accurate configuration information. l Change Management To ensure that the use of standardized methods to efficiently and expeditiously deal with the change 83

84

Release processes l 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 l 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. l Who are the Certification Bodies? There 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? l Step 1 - Create awareness Communicate the goals and benefits of the ISO 20000 certification and the approach for achieving ISO 20000 compliance. l Step 2 - 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. l Step 3 - Conduct an initial ISO 20000 assessment Determine gaps between today’s situation and the standard's requirements. 87

Steps to ISO 20000 Certification? l Step 4 - Set up the ISO 20000 project Choose a project manager and project staff. Determine the necessary resources, prepare a project plan and assign tasks. l Step 5 - Conduct the ISO 20000 certification audit The actual ISO 20000 audit must be carried out by an external certifier from a Registered Certification Body l Step 6 - 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 l l l http: //www. itil. org/en/vomkennen/iso 20000/se rvicedeliveryprozesse/index. php http: //en. it-processmaps. com/iso 20000/faqiso-20000 -certification. html#ISO 20000 Audit http: //www. tw. sgs. com/zh_tw/home_tw_v 2 89

Q&A Thanks 90

ITIL, Service Support and Service Delivery Information Technology Infrastructure Library Advisor：Dr. Celeste Ng 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. l l 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 94

Processes of Service Desk and Incident Management Process Service Request Register Incident The Incident shall be recorded and documented in appropriate quality, in order to facilitate a swift and effective solution. Pro-Actively Inform Users The users are to be informed of detractions to the IT Services as soon as these are known to the Service Desk An Incident of the type Service Request is to be completely processed within the agreed resolution time. Monitor and Escalate Incidents 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. 95

Processes of Service Desk and Incident Management Immediate Incident Resolution by 1 st Level Support 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. Analyse and Resolve Incident in 2 nd Level Support If possible, the root cause of the Service interruption should be corrected, or at least a Workaround applied. 96

Processes of Service Desk and Incident Management Carry out Incident Management Reporting Close and Evaluate Incident Before the final closure of the Incident, it is to be submitted to a quality-control with regards to the resolution. It is to be ensured that improvement potentials are derived from past Incidents. Maintenance of Support Knowledge Base 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 qualityassured manner 97

Processes of Problem Management 98

Processes of Problem Management Identify and Analyse 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. Identify Problem Solution A resolution is to be found for identified Problems and a corresponding RFC, initiating the implementation of the resolution, is to be compiled. Monitor Problems and Errors Outstanding Problems are to be continuously monitored with regards to their processing status, so that where necessary corrective measures may be introduced. Compile Problem Management Reporting 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 99 existing Workarounds.

Processes of Problem Management Develop Problem Solution After the clearance of the Change the actual error-correction is to be developed and subsequently transfered to Release Management for Rollout. Close Problem 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 100 future Problems or Incidents.

Processes of Change Management 101

Processes of Change Management Set Rules for the Handling of Standard Changes For this purpose it is determined, how these Changes are handled. Pre-Evaluate RFC It is to be ensured, that only RFC which are in accordance with the defined quality requirements are accepted into the Change Management Process RFC= Request for Change EC =Emergency Committee Register and Classify Change 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) Handling of Urgent Change by Emergency Committee (EC) Quickest possible clearance or rejection of an Urgent Change, which is to serve to fight an emergency. 102

Processes of Change Management Clearance of Change by the Change Manager Evaluate Change Clearance or rejection of a Change as well as preliminary scheduling and incorporation into the FSC (Forward Schedule of Changes). Appraisal of the process and the results of the Change-implementation. Hold CAB Meeting Clearance or rejection of a Change, in addition to preliminary scheduling and incorporation into the FSC (Forward Schedule of Changes). Group Changes into Releases Approved Changes are to be grouped into Releases; the clearance for the Rollout is to be issued by Change Management. Security Management The ITIL-process Security Management describes the structured fitting of information security in the management organization. 103

Processes of Release Management 104

Processes of Release Management Develop Distribution and Back-out Procedures Planning of the Rollout in detail and devising the necessary technical concepts for the distribution of the Release. Plan Rollout Development of technical and/ or organisational procedures for the distribution of the new Release components. 105

Processes of Release Management Test Release The Release components and the distribution and back-out procedures are to be submitted to a realistic test Carry out Rollout Rolling-out of the Release components into the productive IT environment and ensuring that the Rollout was successful. 106

Processes of Configuration Management 107

Processes of Configuration Management Identify and Document CI Status Carrying out of updates in the CMDB as a reaction to changes to the IT infrastructure. Define and Update CMDB Structure 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. CMDB=Configuration Management Database CI =Configuration Item Record 108

Processes of Configuration Management Carry out CMDB Audits Regular checking of contents of the CMDB. Supply Information Regarding CIs Make available information regarding CIs as required by the other IT Service Management Processes. 109

Processes of Service Delivery 1. 2. 3. 4. 5. Service Level Management Availability Management Capacity Management IT Service Continuity Management Financial Management for IT Services 110

Processes of Service Level Management 111

Processes of Service Level Management Maintain Structures for Service Level Management 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. Define Service Requirements from the client viewpoint with regards to a new or altered IT Service are to be documented and submitted to an initial evaluation. Carry out Service Level Reporting 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. 112 Process Complaints and Carry out SLA Reviews Investigation of the agreed Service Levels, in order to ensure that the SLAs are still adequate for client requirements; SLA =Service Level Agreement

Processes of Service Level Management Prepare Service Implementation 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. Identification of preconditions, which must be established for the implementation of the new or altered Service. Negotiate and agree Contractual Regulations for the Service Finalisation of binding agreements to an IT Service between the IT Organisation and the client-side. 113

Processes of Service Level Management Commission Service Implementation ITC Infrastructure Manager The ITC Infrastructure Manager is responsible for the provision and operation of certain infrastructure components. After clearance of the Change, the implementation of the IT Service is to be planned in further detail; Application Manager The Application Manager is responsible for the creation, upgrading and supporting of an application or applicationclass. 114

Processes of Availability Management 115

Processes of Availability Management Define Guidelines for High Availability Definition of guidelines for applications and infrastructure components Compile Availability Improvement Plan Design of concrete suggestions for measures aimed at the increase in availability Identify Need for Action with Regards to Availability 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. 116

Processes of Availability Management Monitor Availability Carry out Availability Reporting Monitoring of the availabilities agreed within the SLAs and where necessary, identification of needs for action for ensuring the agreed Service Reporting on the adherence to availability agreements, and on counter-measures for the correction to occurred infringements or projected availability issues. Levels. 117

Processes of Capacity anagement 118

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. Monitor IT Capacities Compile Capacity Plan Design of concrete measures for the adjustment of IT capacities in reaction to infringements to performance and capacity agreements Monitoring of performance and IT capacities agreed upon in the SLAs and where necessary. Carry out Capacity Reporting To Performance and Capacity agreements, and on countermeasures for the correction to occurred infringements or 119 projected shortages related to the agreed Service Levels.

Processes of IT Service Continuity anagement 120

Processes of IT Service Continuity anagement 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. Carry out ITSCM Risk Analysis Identification of the risks from a business viewpoint and linking those risks to IT Services and infrastructure components Determine Technical Measures for Containing Risks Determination of concrete technical measures in order to reduce the risks in association with events of disaster; compilation of corresponding RFCs 21 1

Processes of IT Service Continuity anagement Practice the Event of 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 Organisational Measures for Containing Risks Carry out ITSCM Reporting Definition and implementation of organisational measures in order to be prepared for the event of a Reporting on changes to the risksituation as well as on the status of counter-measures for the preparation disaster. for disaster events. 122

Processes of Financial Management for IT Services 123

Processes of Financial Management for IT Services Carry out Budget Planning Session Define Structures for Financial Management Define the structures necessary for the management of financial planning data and costs, as well as for the allocation of costs to IT Services. 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

Processes of Financial Management for IT Services 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. Issue Invoice for IT Services Issuing of an invoice for the provision of IT Services and transmission of this invoice to the client. Carry out Financial Management Reporting on planned/ actual figures regarding costs for providing IT Services, revenues, and IT budget Optimize Costs of Providing IT Services Identification of potentials for cost -optimization with regards to the provision of IT services. 125

ITIL Certification l l 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 l l l 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 l l l http: //www. itilcertification. org/ http: //en. wikipedia. org/wiki/Information_Tech nology_Infrastructure_Library#Certification http: //wiki. en. itprocessmaps. 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 processes Advisor：Dr. Celeste Ng 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

l 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. l 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

Organizational project-enabling process Life cycle model management Investment l Resource management Enterprise environment management Quality management Life Cycle Processes Management Process Purpose The 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. l Purpose of the Investment Management Process The purpose of the Investment Management Process is to initiate and sustain sufficient and suitable projects in order to meet the objectives of the organization. 134

Organizational project-enabling process (continue) l Purpose of the Enterprise Environment Management Process The 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. l Purpose of the Resource Management Process The purpose of the Resource Management Process is to provide resources to projects. l 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

l 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

l 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 l Concept The Concept Stage is executed to assess new business opportunities and to develop preliminary system requirements and a feasible design l Development The Development Stage is executed to develop a system-ofinterest that meets acquirements and can be produced, tested, evaluated, operated, supported and retired. l Production The Production Stage is executed to produce or manufacture the product, to test the product and to produce related 138 supporting and enabling systems as needed.

System Stages of 15288(continue) l Utilization The Utilization Stage is executed to operate the product, to deliver services within intended environments and to ensure continued operational effectiveness. l Support The Support Stage is executed to provide logistics, maintenance, and support services that enable continued system-of-interest operation and a sustainable service. l Retirement The Retirement Stage is executed to provide for the removal of a system-of-interest and related operational and support services, 139 and to operate and support the retirement system itself.

Five Steps to Implement 15288 140

141

142

Reference ISO/IEC 15288 : 2008 Systems and software engineering - System life cycle processes ISO/IEC 12207: 2008 Systems and software engineering - Software life cycle processes CNS 15008: 2006 Systems engineering - System life cycle processes 143

Q&A Thanks 144

CMMI Capability Maturity Model Integration Advisor：Dr. Celeste Ng Reporter： 961612 蔡依潔 145

About CMMI l l l 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 Maturity Level Process Areas ……… Process Areas 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 5 (Optimizing ) Level 4 (Quantitatively Managed) Level 3 (Defined) Level 2 (Managed ) Level 1 (Initial) 148

Maturity Level (Cont. ) l Level 1 : Initial 1. 2. Processes are usually ad hoc and chaotic. An inability to repeat their successes. l Level 2 : Managed 1. The projects of the organization have ensured that processes are planned and executed in accordance with policy. The process discipline helps to ensure that existing practices are retained during times of stress. 2. 149

Maturity Level (Cont. ) l Level 3 : Defined 1. Processes are well characterized and understood, and are described in standards, procedures, tools, and methods. The organization’s set of standard processes is established and improved over time 2. l 1. 2. Level 4: Quantitatively Managed Establish quantitative objectives for quality and process performance and use them as criteria in managing processes Quantitative objectives are based on the needs of the customer, end users, organization, and process implementers. 150

Maturity Level (Cont. ) l Level 5 : Optimizing 1. 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

Level 2 Process Areas • REQUIREMENTS MANAGEMENT(REQM) • PROJECT PLANNING(PP) • PROJECT MONITORING AND CONTROL(PMC) • SUPPLIER AGREEMENT MANAGEMENT(SAM) • MEASUREMENT AND ANALYSIS(MA) • PROCESS AND PRODUCT QUALITY ASSURANCE(PPQA) • CONFIGURATION MANAGEMENT(CM) 153

• • • Level 3 Process Areas REQUIREMENTS DEVELOPMENT(RD) TECHNICAL SOLUTION(TS) PRODUCT INTEGRATION(PI) VERIFICATION(VER) VALIDATION(VAL) ORGANIZATIONAL PROCESS FOCUS(OPF) ORGANIZATIONAL PROCESS DEFINITION (OPD) ORGANIZATIONAL TRAINING(OT) INTEGRATED PROJECT MANAGEMENT (IPM) RISK MANAGEMENT(RSKM) DECISION ANALYSIS AND RESOLUTION(DAR) 154

Level 4 Process Areas • Organizational Process Performance(OPP) • Quantitative Project Management(QPM) • The organization of through the evaluation : • 中冠資訊股份有限公司、鼎升資訊科技股 份有限公司 、財團法人 業技術研究院 155

Level 5 Process Areas • ORGANIZATIONAL INNOVATION AND DEPLOYMENT(OID) • CAUSAL ANALYSIS AND RESOLUTION(CAR) • The organization of through the evaluation : • IBM國際商業機器股份有限公司、凌羣電腦 股份有限公司、中山科學研究院 156

Evaluation methods l The SCAMPI ( Standard CMMI Appraisal Method for Process Improvement) method is used for appraising organizations using CMMI. Sub-projects Work items 1. SCAMPI Evaluation plan SCAMPI Pre-evaluation 2. Training course 3. Implementation of the SCAMPI appraisal 4. Correction of the lack of evaluation and examine 1. SCAMPI evaluation plan SCAMPI Formal evaluation 2. Examine before the formal evaluation 3. Implementation of the SCAMPI appraisal 157

Reference l http: //www. sei. cmu. edu/ 158

Q&A Thanks 159

COBIT Control Objectives for Information and Related Technology Advisor：Dr. Celeste Ng Reporter： 961610 王淨嬪 160

COBIT Developed (1993) by the international Information Systems Audit and Control Association ISACA 161

COBIT - Introduction l COBIT is an IT governance framework and supporting toolset. 162

Source : COBIT 4. 1 Excerpt BOOK 163

Information Criteria l l l 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. Source : COBIT 4. 1 Excerpt BOOK 164

Information Criteria (cont. ) l l 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. Source : COBIT 4. 1 Excerpt BOOK 165

Information Criteria (cont. ) l l 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. Source : COBIT 4. 1 Excerpt BOOK 166

Source : COBIT 4. 1 Excerpt BOOK 167

IT RESOURCES l Applications are the automated user systems and manual procedures that process the information. l Information is the data, in all their forms, input, processed and output by the information systems in whatever form is used by the business. l Infrastructure is the technology and facilities that enable the processing of the applications. l 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. Source : COBIT 4. 1 Excerpt BOOK 168

Source : COBIT 4. 1 Excerpt BOOK 169

COBIT - Domains l 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 l l 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 Source : COBIT 4. 1 Excerpt BOOK 172

Source : COBIT 4. 1 Excerpt BOOK 173

Source : COBIT 4. 1 Excerpt BOOK 174

Source : COBIT 4. 1 Excerpt BOOK 175

Source : COBIT 4. 1 Excerpt BOOK 176

Source : COBIT 4. 1 Excerpt BOOK 177

Source : COBIT 4. 1 Excerpt BOOK 178

Source : COBIT 4. 1 Excerpt BOOK 179

Source : COBIT 4. 1 Excerpt BOOK 180

How to certificate the standard? One l People who want to certificate the COBIT license to take the COBIT Foundation Certification Exam. ‣ Cost : $150 U. S. D. ‣ Exam Time : 1 hr ‣ Questions : 40 Single-Choice Questions(28 questions answered correctly. ) ‣ Tools : Computer and Network Source : 資策會 181

How to certificate the standard? Two l Company who wants to implement COBIT needs to cooperate with ISACA. l Case Example 182

Sources l l l BOOK - COBIT® 3 rd 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