Technical Reference Model for the Government Procurement of
Transcription
Technical Reference Model for the Government Procurement of
Technical Reference Model for the Government Procurement of Information Systems (TRM) 2010 June 2011 Information Services Industry Division, Commerce and Information, Policy Bureau, Ministry of Economy, Trade and Industry Information-Technology Promotion Agency, Japan This document has been translated by Erklaren Co., Ltd. 1 Contents 1. 2. Introduction .................................................................................................................................. 4 1.1. Background ................................................................................................................................... 4 1.2. Objectives ...................................................................................................................................... 4 1.3. Audiences ...................................................................................................................................... 5 1.4. Coverage ....................................................................................................................................... 5 1.5. Document Structure....................................................................................................................... 6 1.6. Overview of Revisions to the 2009 version ................................................................................... 6 1.7. Revisions Planned in the 2011 version ......................................................................................... 7 Overview ....................................................................................................................................... 8 2.1. TRM Relationships with Other Documents, Guidelines, or Reference Models ............................ 8 2.2. Structure of this Technical Reference Model ................................................................................ 11 3. Definition (Categorization of Technologies) ........................................................................... 18 4. Procurements and System Design Policies ............................................................................ 24 4.1. Functional Configuration Model .................................................................................................. 24 4.2. Physical Configuration Model ...................................................................................................... 34 4.3. Categorization of Service-Work................................................................................................... 37 4.4. Policies for Defining Business Application .................................................................................. 40 4.5. Policies for Common Databases ................................................................................................. 46 4.6. Policies for Implementing Common Business System for Ministries .......................................... 48 4.7. Virtualization Technologies .......................................................................................................... 49 4.8. Standpoints of Cloud Users ......................................................................................................... 52 4.9. Standpoints of Cloud Integration ................................................................................................. 63 4.10. Security Issues ............................................................................................................................ 68 4.11. Policies for Employment of Green-IT .......................................................................................... 77 4.12. Notes on Employment of IPv6 .................................................................................................... 79 5. Descriptions of Technological Domain ................................................................................... 80 5.1. BI/DWH/ETL ................................................................................................................................ 82 5.2. EAI ............................................................................................................................................... 94 5.3. iDC Facility .................................................................................................................................. 96 5.4. SOA Related Functions ............................................................................................................. 100 5.5. Maintenance Environment......................................................................................................... 109 5.6. Servers ...................................................................................................................................... 120 5.7. Storage ...................................................................................................................................... 134 5.8. Shared PC / Office Printer ......................................................................................................... 139 5.9. Operations Management/Security ............................................................................................. 158 5.10. EIP............................................................................................................................................. 193 5.11. Open Web Server ..................................................................................................................... 196 5.12. Groupware, File Server, and Mail Server .................................................................................. 206 2 5.13. Integrated Account Management, Authentication, Authorization (Access Control) .................. 221 5.14. Integrated Directory................................................................................................................... 233 5.15. WAN, Ministerial LAN, DNS/DHCP/Proxy, Remote Access...................................................... 238 5.16. Workflow, BAM .......................................................................................................................... 267 5.17. Common Elements in Domains ................................................................................................ 268 6. Procurement of services ......................................................................................................... 269 6.1. Support for master plan formulation .......................................................................................... 271 6.2. Support for procurement ........................................................................................................... 278 6.3. System Integration (Design/Development) ............................................................................... 297 6.4. Operation ................................................................................................................................... 323 6.5. Helpdesk.................................................................................................................................... 348 6.6. Maintenance .............................................................................................................................. 372 6.7. Tasks incidental to procurement of devices .............................................................................. 425 6.8. Tasks incidental to procurement of iDC equipment ................................................................... 444 6.9. Network procurement ................................................................................................................ 466 6.10. Cloud service ............................................................................................................................ 504 6.11. Cloud construction .................................................................................................................... 505 6.12. Security ..................................................................................................................................... 506 6.13. Other ......................................................................................................................................... 538 7. Recommended Technology Standard.................................................................................... 539 7.1. Requirements for technology standards in conformity with the “Framework for Interoperability Relating to Information Systems” .............................................................................................. 539 7.2. Items for technology standard evaluation cited in “TRM 1st issue: The Report on the Results of Validity Examination” ................................................................................................................. 542 7.3. Guidelines for the Selection of Recommended Technology Standards .................................... 543 7.4. Recommended Technology Standard ....................................................................................... 550 Appendix 1 Case Examples of Procurement................................................................................ 555 Appendix 2 Case Examples: Service Procurement Specifications ........................................... 559 Appendix 3 Table: Guidelines on the transition of encryption algorithms ............................... 567 Appendix 4 References................................................................................................................... 570 3 1. Introduction This document provides information about procurement of information systems, aiming to be used as a supplemental reference to the “Basic Guidelines for Government Procurement Related to Information Systems.” 1.1. Background The integration of separately-procured separation-of-procurement-policy recommended information in the “Basic systems Guidelines following for the Government Procurement Related to Information Systems,” effective from July 2007 (agreed at the Liaison Conference of Chief Information Officers (CIO) of Ministries and Agencies, hereinafter referred to as the Procurement Guidelines), could, in some cases, create problems due to the lack of interoperability of the individual business systems with the common platform system caused by the incompatibility of employed vendor-specific technologies, especially the interface for service-calls. In addition, the individually implemented systems may often lack user-friendliness, because, situations where the ministries and agencies have independently implemented their portal systems—home pages or portals for electronic submission. The Japanese users are often required to have different client systems for the different systems prepared by the ministries and agencies: those systems often require unique software or a specific web browser for the client systems on the user-side, or a version mismatch of execution environments interferes with the use of the systems. Moreover, even if the systems implemented in the ministries and agencies through independent procurement are optimum in the sense that they follow the Procurement Guidelines, the “Guidelines for Optimizing Operation and Systems” (agreed at the Liaison Conference of Chief Information Officers (CIO) of Ministries and Agencies in March 31 2006), and “Framework for Interoperability Relating to Information Systems” (announced by the Ministry of Economy, Trade and Industry in June 29 2007, hereinafter referred to as “Framework for Interoperability”), such systems might not be optimum from the stand point of the government as a whole, due to the lack of applicability to other systems. 1.2. Objectives The objectives of this “Technical Reference Model for the Government Procurement of Information Systems” (hereinafter referred to as “Technical Reference Model”) are as follows: • Improving user friendliness, • Ensuring system integration of separately-procured systems, • Minimizing total cost in the job-operations and systems lifecycle, • Improving efficiency of procurement. 4 This Technical Reference Model, with the intention of being used as a reference for optimum procurement and implementation of information systems, provides the following: • Technical guidelines for ensuring separation of procurement and integration following the Procurement Guidelines (Ch. 4), • Technical guidelines for realizing visualization, clouds, and green IT, • Functional configuration model consistent with the typical procurement models (Ch. 4), • Physical configuration model consistent with typical government information systems (Ch. 4), • Definition of technology domains (categories) — possible minimum group of procurement items (Ch. 5), • Example of neutral descriptions of requirements for each technology domain in cases of the procurement of goods (Ch. 5), • Essentials of requirement descriptions for each procurement category in case of the procurement of services (Ch. 6), • Interoperable open standards to be preferentially employed (Ch. 7), • Supplemental case examples (Case examples of procurement), • Notes on ensuring security (Encryption algorithm transfer issues). 1.3. Audiences This Technical Reference Model is prepared with the assumptions that it is referenced by the following audiences: • CIOs, Deputy CIOs, and support staff in the ministries and agencies, the independent administrative institutions, and the local governments, • Persons in charge of information system design / planning / operations in the ministries and agencies, the independent administrative institutions, and the local governments, • Persons in charge of procurement in the ministries and agencies, the independent administrative institutions, and the local governments, • Procurement supporters • Vendors bidding for the government information systems procurement. Note that, in the application of this Technical Reference Model to the procurement of systems other than government information systems, adjustments, according to individual procurement policies or system integration policies, are necessary as for the scale of procurement items and the technologies or open standards to be employed preferentially. 1.4. Coverage This Reference Model provides technical information applicable typically to the following systems: • Information systems of the central government, 5 • Information systems of the independent administrative institutions, • Information systems of the local governments. Note that, although this Technical Reference Model is basically applicable to the implementation and procurement by the above information systems, adjustment or customization is necessary in some cases such as the application to systems other than those of the central government. Note that this Technical Reference Model will be revised periodically, reflecting requests from persons in charge of the government procurement of information systems, or for catching-up with changes in the trends of system requirements or product-features. Note that this Technical reference Model, in accordance with the Procurement Guidelines, is prepared to help create procurement specifications having no ambiguity in requirements, having no unrealistic requirements, and having no requirements or factors in favor of specific hardware or software products or technologies. 1.5. Document Structure Besides this Technical Reference Model, which provides technical information, the following documents constitute the document family of the technical reference model for the government procurement of information systems: “Utilization Manual of the Technical Reference Model for the Government Procurement of Information Systems (TRM)” (hereinafter referred to as “Utilization Manual”), and the List and Descriptions of Technologies, an attachment to the TRM published on the website. 1.6. Overview of Revisions to the 2009 version In the 2010 version, the following are added to the 2009 version or modified: • Addition: classification of service procurement, • Addition: essentials of descriptions of requirements in service procurement, • Addition: technical guidelines for virtualization, • Addition: technical guidelines for the utilization of clouds, • Addition: technical guidelines for the implementation of clouds, • Modification: improvement and augmentation of descriptions on information security, • Modification: addition of detailed descriptions of guidelines for the selection of recommended technical standards, • Modification: separation and publishing on the website of the technology list and descriptions of technologies. 6 1.7. Revisions Planned in the 2011 version In the 2011 version, the augmentation of the descriptions is planned as follows: • Revising the technical requirements for the procurement of goods, • Adding typical requirement-descriptions for the procurement of services, • Adding typical requirement-descriptions on the utilization of clouds, • Adding typical requirement-descriptions on the implementation of clouds, • Adding descriptions on the utilization of open standards in procurement specification documents. 7 2. Overview This chapter provides the general overview of this Technical Reference Model. 2.1. TRM Relationships with Other Documents, Guidelines, or Reference Models This Technical Reference Model provides the technological information necessary, in order to prepare specific requirement-descriptions in a request for information (RFI) or a request for proposal (RFP), for breaking-down the principles recommended in the following documents, guidelines, or reference models: •Guidelines for Optimization of Government Information Systems, described in the Guidelines for Optimizing Operation and Systems, •Guidelines for Government Procurement, described in the Procurement Guidelines, •Guidelines for Interoperability of Information Systems, described in the Framework for Interoperability, •Guidelines for Information System Security described in the Standards for Information Security Measures for the Central Government Computer Systems. 2.1.1. Relationship to the Guidelines for Optimizing Operation and Systems This Technical Reference Model provides the technical information to implement the principles of the following guidelines recommended in the Guidelines for Optimizing Operation and Systems: [Guideline 4-1] As for the computerization of the whole or a part of job-operations, if such operations are similar to those executed in other ministries, agencies, divisions, or departments, etc, and the computerized systems can be applied to the operations in other entities, construct a unified computer system and share the system among the entities, for the purpose of consolidation and centralization of information systems. In addition, even in a case where distributed data-management by the individual ministry or agency is preferable, reduce the cost required for system development and maintenance while keeping the interoperability, through the unification and centralization of functions required by applications and the unification of requirements for data management; [Guideline 4-2] Reduce the number of LANs used in ministries or agencies to one per a ministry or agency, by consolidating mail or other basic job-operation systems and centralization of maintenance jobs; 8 [Guideline 4-3] Use LAN terminals connected to ministry’s internal LANs for accessing information systems to execute job-operations. Use ministry’s internal LANs or other infrastructure networks for accomplishing server-to-server connection or server-to-user connection; [Guideline 4-4] Use the Kasumigaseki-WAN for the connection between ministries or agencies. Use the local government wide-area network (LGWAN) for the connection of government ministries or agencies to local governments; [Guideline 4-5] Employ hardware, software, and communication protocols that are open and conforming to international or de-facto standards in the implementation of information systems; [Guideline 4-6] Consolidate and reduce the number of the connection points to the information systems used to publish information on the internet such as home pages, and apply comprehensive security measures covering other information systems connecting to such systems; [Guideline 4-7] Prepare back-up systems for the systems where integrity and high-availability is required, among the systems shared by ministries and agencies, or the systems tightly linked to the citizens’ lives or social / economic activities of Japan. 2.1.2 Relationship to the Procurement Guidelines This Technical Reference Model provides technical information following the Procurement Guidelines, promotes flawless government procurement in accordance with the guidelines, and supports trouble-free implementation of information systems. This Technical Reference Model enables the followings: • Separation of procurement along phases of design or development; • Management of design or development processes; • Completeness of information necessary for preparing proposals; • Separation of the procurement of hardware and the procurement of software • Separation of procurement in the phase of design, development and deployment, the procurement in the phase of operation, and the procurement in the phase of maintenance; • Elimination of ambiguity in requirements; • Requirement description based on open standards. Note 1: “Open standards” refer to the standards satisfying the following: (1) The standards are agreed through a publicly-open participation process, and the specifications are public 9 down to the implementation levels; (2) No one is rejected to adopt the standards; (3) Multiple products that implement the standards are available in the market. Note 2: This Technical Reference Model uses the term the “common platform system” as a term collectively referring to the “common platform system” used in the Procurement Guidelines and the “H /W infrastructure used in the “Application Manual of the Basic Guidelines for Government Procurement Related to Information Systems” (Ver. 2) (published in July 1, by Administrative Management Bureau, Ministry of Internal Affairs and Communications, hereinafter referred to as the Application Manual). In the same way, Technical Reference Manual uses the term “common platform system provider,” collectively referring to the “common platform system provider” and the “H / W infrastructure provider.” 2.1.3. Relationship to the Framework for Interoperability This Technical Reference Model provides information following the Framework for Interoperability: the provided information supports the preparation of procurement specifications in accordance with the government policies on information system and the interoperability presented in the Framework for Interoperability. This Technical Reference Model includes the following: • Policies on the neutrality of requirements; • Policies on the preferential employment of open standards; • Policies on the selection of the optimum information system; • Policies on the adoption of openness. In addition, this Technical Reference Model recommends that the individual business systems should be loosely connected to the common platform system through loosely coupled services.. The recommendation is in accordance with the following guideline presented in the Framework for Interoperability: Guideline: When procurements of systems are separated into individual functions, it is desirable to avoid putting limitations on computers and platforms on which such functions are executed. Therefore, service interfaces should be platform-independent, and the individual services are asynchronously and loosely coupled. 2.1.4. Relationship to the Standards for Information Security Measures for the Central Government Computer Systems This Technical Reference Model provides the technical information necessary for the preparation of procurement specifications that are following the Standards for Information Security Measures for the Central Government Computer Systems and in accordance with the Standards for Information Security Measures for the Central Government Information Systems. Note: The latest version of the Standards for Information Security Measures for the Central Government Computer Systems was released on April 23, 2011. Refer to the following URL: http://www.nisc.go.jp/active/general/kijun01.html 10 2.1.5. Relationship to the Security-by-Design Policy and the Risk-factor Reference Model This Technical Reference Model, in the section 4.10, provides the guidelines of security measures, by introducing the generals of security-by-design and the risk factor reference model. 2.1.6. Relationship to the Government Shared Platform System This Technical Reference Model, in the section 4.8, provides the general idea of using “clouds,” the idea will be applicable to the use of the Government Common Platform. 2.2.Structure of this Technical Reference Model This Technical Reference model, in Ch.3 and in the following chapters, provides technical information as summarized in the following sub-sections. 2.2.1. Ch. 3: Definition (Categorization of Technologies) Ch. 3 shows the technology categories defined in this Technical Reference Model and the Separated appendix: Table of Technical Categorization (Technical Domains). This Technical Reference Model, for the purpose of avoiding ambiguities in the communications between the procurers and providers, categorizes the technologies from the view points of the both parties. Ch.3 categorizes technologies from the view point of providers through layering of the IT system structures, formalizing the layered structure according to the TRM framework, and mapping the individual elements of technology onto the framework by their usages or features 11 Break-Down -Structure of the IT-Technologies Top Level Second Level Technologies Specific Items Functions Hardware PC / Platform In-Office-shared Thin Client Personal Computer Printers In-Office-shared Printer Server Server Hardware Storage Disk Storage Server Hardware Tape Storage Network Switch LAN Secure Wireless LAN WAN Router Remote Access Private Line Service Business PC / Office Operation Printer Common Operation Environment OS Kernel Peripheral Support Platform Command Line Interface Web Browser Video Viewer Server Server Operating System OS Service Thin Client Server Network DNS / DHCP / Proxy DNS Server DHCP Server Proxy Server VoIP Application Application Web Server Platform Execution AP Server Environment Data Meta Data Registry Management DB Server File Sharing Integrated Directory Data Exchange EAI / Linkage Data Adapter Legacy-System Integration Table 2.2-1: Technology Category (Part) Figure 2.2-2 shows the technology domains mapped on the layer of TRM Framework. 12 (H/W) Shared PC, Shred-inOffice Printer Hardware Platform EAI (Web Service) (Server OS) (H/W) Server (Protocol) (H/W) Storage DNS, DHCP, Proxy Authentication, Integrated Account Management, Integrated Directory (H/W) WAN, Ministry’s Internal LAN Remote Access Common Technologies to All Domains (Client OS) File Legacy Server Integration SOARelated Functions (SOA) (Network Service) (GeneralPurpose Middleware) BI/ DWH/ ETL Maintenance Environment (Base S/W) EIP Groupeware, Workflow, Mail Server BAM System Operation Management Application Platform Public Web Server Security (Shared S/W) (Dedecated Middleware) Base Applications Job-Operation Platform (Common Business System) (Individual Business System) Approval Individual Business Applications iDC Facility Colors indicate where the technology in the box is used. Mainly used in client environments: PCs or printers Mainly used in server environments: servers or storages Same as described at the left Technologies common Network to the entire IT sphere: related independent of technologies specific environments Figure 2.2-2 Technology Domains mapped on the TRM Framework 2.2.2. Ch. 4: Procurements and System Design Policies Ch.4, from the standpoint of procurers, shows the goods and services to be purchased in each technical domain: domains are defined through classifying and categorizing the target functions, making models—patterns—of functions for each unit of purchase, assembling necessary technologies likely procured at one time as certain groups —domains—and allocating the functions to the domains. At the same time Ch. 4 shows where, in the physical configuration of the ministry and agency systems, each domain in the Function Configuration Model is allocated. Note that it is not always required to realize each function shown in the configuration diagram with a separate piece of hardware: from the standpoint of optimization, realization on a single server of functions allocated to multiple technology domains would be preferable. For example server consolidation, utilization of existing servers, or utilization of communication equipments for remote-access are preferable methods. Elimination of redundant services or goods through optimization-assessment is essential. Also, Ch.4, for the purpose of complementing the Guidelines for Optimizing Operation and Systems, and the Procurement Guidelines, shows the policies of designing information systems to be procured; and for the purpose of Request For Information (RFI), and Request For Proposal (RFP) and procurement specifications, shows policies of designing business application, policies for common databases, utilization of common business system for Ministries, policies of employing green IT, policies of security, policies of virtualization, and policies of utilization and implementation of clouds. 13 2.2.3. Ch. 5: Descriptions of Technology Domains Ch. 5 provides the descriptions of Technology Domain from the standpoint of the procurers of goods, with examples of requirement specifications for general — common to ordinary specifications. Although the functional or non-functional requirements shown in those examples are realistic because the technologies or goods are available and proven in Japan at the time of publication of this Technical Reference Model. Those specifications are only general purpose examples. Therefore, when applied to the actual procurement, the example specifications should be customized according to the situations: the parameters (variables) in { } need to be modified, the example descriptions in [ ] needs to be modified or selected, and addition or elimination of requirements will be necessary. Note that, in such customization, sufficient consideration or care is required for avoiding unreasonably-severe conditions or putting in unnecessary requirements. Also, note that it is not always necessary to procure all the technical elements shown in the domains: previously procured technological elements or certain elements purchased in other purchase orders may be reusable. Utilization of existing resources or elements included in other purchases and avoidance of duplicated procurement through the optimization assessment is necessary when actual specifications are prepared by applying the descriptions in Ch.5. 2.2.4. Ch. 6: Procurement of Services Ch. 6 shows the categorization of services to be procured from the standpoint of procurers, and then shows the overviews of services to be described in specifications for each of the categories defined. Also, Ch.6 provides information on the following: prerequisite information prepared by procurers to be described as a detailed requirement; outputs of services; essential points to be described in procurement specifications and comments / interpretations; and project-dependent points and information-system-feature-dependent points to be taken into account. Note that, in comparison with Ch.5, Ch.6 does not provide information so that the descriptions can be copied to actual specifications, for the reason that the service-procurement specifications will be more dependent on project-specific factors than those of the procurement of goods, and therefore the specifications must be prepared so that the outputs of the service-procurement in the proceeding phase is sufficiently detailed. 14 Planning phase Requirements definition 要件定義 phase Development phase 開発フェーズ 6.2 6.2.3 Support for ( 等) procurement (Project management, etc.) 6.3 Operation/maintenance 運用・保守フェーズ phase 6.4 運用 6.4 Operation 6.5 Helpdesk 6.1 Support 6.1全体計画 for master 策定支援 plan formulation 6.2.2 Support for procurement 6.2 1 調達支援 (requirements ( 等) definition, etc.) 6.3 System integration (design/development) 6.3 ハードウェア更改 6.3 機能追加 6.7 Tasks incidental to procurement of devices 6.6 Maintenance Hardware maintenance Software maintenance Application maintenance System infrastructure maintenance 6.8 Tasks incidental to procurement of iDC equipment ・ 設備) 6.9 Network procurement 6.12 Security Figure 2.2-3: Classification of procurement of services 15 Figure 2.2-4 Descriptions of the Services Service 6.1 Support for master plan formulation 6.2 Support for procurement 6.3 System integration (design/development) 6.4 Operation 6.5 Help desk 6.6 Maintenance 6.7 Tasks incidental to procurement of devices 6.8 Tasks incidental to procurement of iDC equipment 6.9 Network procurement 6.10 Cloud service 6.11 Cloud construction 6.12 Security 6.13 Other (to be created) Service operation Planning the systematization initiative and systematization plan creation Service operations of supporting procurement for ministries: e.g. implementation of requirements definition, deciding on procurement policies/procedures, creation of procurement specifications, request for comment, evaluation of contractors, and project management. Service operations concerning information system integration: e.g. design, development, migration, operation, operation/maintenance design of information systems. Service operations concerning information systems (“6.5 Help desk” may be considered as part of the operations of 6.4; however, it is separately described in Chapter 6.5) Service operations concerning help desk to respond to inquiries from users on system operationuse Service operations of information system maintenance: e.g. correction of information system faults, modification of system/software products after delivery and adaptation to changed environments Service operations generated incidental to procurement of devices(*excluding maintenance): e.g. installation, configuration of devices necessary for information systems (including ready-made software, such as OS which is inseparable from hardware) Service operations such as installation and configuration of various equipment in facilities (data center) prepared by customers, and operation monitoring of relevant systems (and operations incidental to it) Services related to construction of networks, such as LAN and WAN (Wide Area Network), and service operations incidental to service procurement, such as WAN service and internet service. Service operations using cloud system services Service operations to construct cloud systems This section describes security cautions in procurement of services and security approaches during construction of information systems Service operations not included in 6.1 – 6.12, such as procurement of business package software. 16 2.2.5. Ch. 7: Recommended Technology Standards Ch. 7 shows the open standards to be preferentially employed especially in the procurements of government information systems. Note that those open standards are solely chosen for the purpose of the separation of procurement recommended in the Procurement Guidelines, and will not cover all the technologies to be procured. Also note that as for the employment of open standards, the excessive employment of open standards to the layer where the interoperability is unnecessary may limit the selection of technologies or products to open-standard conforming products. Therefore, open standards in procurement specifications should be specified only in the following layers: the interface between the elements of information systems to be procured separately; and the interface of the existing environments and the newly procured elements of information systems. It is preferable to leave the decision of open-standard employment of the lower levels to the vendors. 2.2.6. Separated appendix 1: Samples of Procurement Separated appendix 1 introduces the actual specifications of the government procurement as a supplement to this Technical Reference Model, for the purpose of reducing the work load in preparing high-quality procurement specifications. In preparing actual specifications, it is preferable to use the examples as well as the descriptions in the main chapters of this Technical Reference Model. The web page of the Ministry of Internal Affairs and Communications and the web pages of other ministries publish procurement examples not shown in this separated appendix. 2.2.7. Separated appendix 2: Samples of Procurement Requirements of Service Separated appendix 2 shows a table, listing the actual procurement specifications, on which Ch. 6 is based. 2.2.8. Separated appendix 3: Encryption Algorithm Transition Separated appendix 3 introduces the necessity of the transition of the encryption algorithm SHA-1 and RSA1024 widely used at present to more secure algorithms. 2.2.9. Separated appendix 4: References Separated appendix 4 lists the documents or articles helpful to understand this Technical Reference Model, and shows how to access them. 17 3. Definition (Categorization of Technologies) The purpose of this Technical Reference Model in this document is to promote smooth and less ambiguous communications between the procurers and the bidders by providing categorizations for technologies that are well accepted by both the procures and the providers. Chapter 3 categorizes technologies in technology domains mainly from the providers’ point of view, provides a layered structure of IT systems, configures the TRM framework, and maps element technologies onto the framework. (Client OS) Hardware Platform (H/W) PC, Inofficeshared Printer Data Utilization Application Platform Data Management Data Exchange / Linkage (Server OS) (H/W) Server SOARelated Functions Web Service (Protocol) (H/W) Storage (H/W) Network Common Technologies to All Domains Job-Operation Platform Business / Process Management Network Service Application Platform Inf ormation Access / Collaboration System Operation Management Office Applications Security Base Applications Development / Maintenance Environment Individual Business Applications iDC Facility Colors indicate where the technology in the box is used. Mainly used in client environments: PCs or printers Mainly used in server environments: servers or storages Same as described at the left Technologies common Network to the entire IT sphere: related independent of technologies specific environments Figure 3-1: TRM Framework The Figure 3-2 can be used as a reference to how the technology domains are mapped in the layers of the TRM Framework. 18 (H/W) Shared PC, Shred-inOffice Printer EAI (Web Service) (Server OS) (H/W) Server (Protocol) (H/W) Storage DNS, DHCP, Proxy Authentication, Integrated Account Management, Integrated Directory (H/W) WAN, Ministry’s Internal LAN Remote Access iDC Facility Colors indicate where the technology in the box is used. Mainly used in client environments: PCs or printers Mainly used in server environments: servers or storages Same as described at the left Technologies common Network to the entire IT sphere: related independent of technologies specific environments Figure 3-2: Technology Domains mapped on TRM Framework 19 Common Technologies to All Domains (Client OS) File Legacy Server Integration SOARelated Functions (SOA) (Network Service) Hardware Platform (GeneralPurpose Middleware) BI/ DWH/ ETL Maintenance Environment (Base S/W) EIP Groupeware, Workflow, Mail Server BAM System Operation Management Application Platform Public Web Server Security (Shared S/W) (Dedecated Middleware) Base Applications Job-Operation Platform (Common Business System) (Individual Business System) Approval Individual Business Applications Table 3.1: Break-down Structure of IT-Technologies Break-Down -Structure of the IT-Technologies Top Level Second Level Technologies Specific Items Functions Hardware PC / Personal Computer Platform In-Office-shared Thin Client Printers In-Office-shared Printer Server Server Hardware Storage Disk Storage Server Hardware Tape Storage Network LAN Switch Secure Wireless LAN WAN Router Remote Access Private Line Service Business PC / Office Operation Printer Common Operation Environment OS Kernel Peripheral Support Platform Command Line Interface Web Browser Video Viewer Server Server Operating System OS Service Thin Client Server Network DNS / DHCP / Proxy DNS Server DHCP Server Proxy Server VoIP Application Application Web Server Platform Execution AP Server Environment Data Meta Data Registry Management DB Server File Sharing Integrated Directory Data Exchange EAI / Linkage Data Adapter Legacy-System Integration Web Service ESB (Enterprise Service Bus) 20 Web Service Protocol Base Technology Security Service High-Reliability Messaging Service Transaction Service Base Information Mashup Portal Application Access / EIP Portal Sites Collaboration Personalize Application Integration Contents Management System Groupware E-mail Instant Message Full Text Search Web Conference Screen Sharing Service Business / Business Process Management Process Business Activity Monitoring Management Business Model Simulation Work Flow Data Utilization Business Intelligence Data Warehouse ETL (Extract / Transfer / Load) Data Mart OLAP (Online Analytical Processing) ODS (Operational Data Store) Data Mining Dashboard Reporting Tool / Service SOA Related Management Function Service Repository / Registry Office Office Application Image Processing Application Word Processing Presentation Spread Sheet Facsimile Image Publishing 21 Document Processing Calculation System System System Operation Management Availability / Performance Operation Operation Management Management Management Client PC Management Server Management Network Management Storage Management Service Desk Security Security Security Management Trail Management Function Virus Protection Function Virus Gateway Internet Content Filtering Function Firewall Function Intrusion Detection / Protection Function Network Connection Monitoring Function Encryption Function Anti-Spam Mail Function Integrated Account Management Directory Linkage OS Access Control Web Single Sign-on Desktop Single Sign-on Common Common Coded Character Set Technology to Technology to Graphic Format All Domains All Domains CD-ROM Format DVD Format Character Symbol Tagset / Markup-language Definition Data Element Standard Video Format Compaction / Archiving Magnetic Tape Business Information Geographic Information 22 Character Set / Data Representation Locale / Native Language Support Programming Language Modeling Support Accessibility Network Network Communication Protocol Service Service Time Service Development / Development / Development Environment Maintenance Maintenance Development Tool Environment Environment Configuration / Version Management Tool Project Management Tool Test Tool Video Processing Voice Information Processing CAD (Computer Aided Design) Expert System E-learning Product / Service specific Technology Product / Kiosk Service specific Mobile Device Technology Product Information Mobile / Wireless IC Card Media Distribution Service Geographic Information Service Document Management Service TRM Supporting Technology IT Service Management TRM Supporting Technology Software Lifecycle Management Internal Control Framework 23 4. Procurements and System Design Policies 4.1. Functional Configuration Model This chapter, from the standpoint of procurers, shows the allocation of technology elements configuring applications, the common platform systems, and networks to the technology domains in the Functional Configuration Model. In particular, on the boundary between the common platform system and networks, allocation of network-technology elements are defined as consistent as possible with actual situation of technology elements procured. Note that the Functional Configuration Model includes elements configuring private-cloud environments (a private cloud refers to a cloud constructed and used locally within an organization.). Functional Configuration Model : Technology Domains Application Individual Business System Common Platform System Workflow / BAM Common Business System Legacy System Integration Function for SOA System Operation Management / Security BI/DWH/ETL EIP Public Web Server Groupware / File Server Maintenance Environment EAI Server Storage iDC Facility Integrated Account Management / Authentication / Permission Integrated Directory Network Remote Access Shared PC In-office-shared Printer WAN / Ministry’s Internal LAN Figure 4.1-1 Functional Configuration Model 4.1.1. Definition of Technology Domains Technology Domains, defined through categorization and classification of technologies in such a way that the items of actual procurement in the central government fit in, are also used as top level classifications to coarsely categorize or classify the nonnegligible technologies or products belonging to more than one domain, or difficult to precisely allocate. The Technology Domains are defined as follows: 24 Application Technology Domain Definition Individual • Job-operations defined in the Job-operation Manual Job-operations • Individual business applications of job-operation Legacy System • Mechanism existing in the application layer to make a linkage between the job-operations realized on legacy systems and Integration those on the common platform system • Note that EAI, etc. are excluded. Common Platform System Technology Domain Definition Common Job-operation • Common job-operations defined in the Job-Operation Manual available on the common platform system. Workflow / BAM BI /DWH / ETL • The services commonly available to individual job-operations. • A versatile mechanism to manage or monitor job-processes • Note that web-service-based BPM is excluded. • A versatile and high-performance mechanism for data referencing / search / analyzing data, effective for reducing individual implementation of job-operation input / output display screens or forms. • Also, refers to a versatile mechanism for data handling. EAI • A versatile mechanism for linking job-operation systems. SOA Related Function • Web-service-based framework for organizing the entire operation systems through linking the web-services • Also, refers to related technology standards to support the framework. System-operation • The entire mechanism for managing operations or preserving security of the common platform system and applications. Management / security • Note that mechanisms required to be implemented in the individual applications are excluded. Maintenance • The mechanism for implementing the environments required for the maintenance of the common platform system and Environment applications. • Also, in cases, specifically refers to the mechanisms for enabling maintenance including in-operation-maintenance procedures, development tools, or automatic-testing. Server • Server hardware and software supporting all the functions 25 described above so far. • Required to be an integrated environment under unified management with reliability, availability, and flexibility; and, in cases, virtualized implementations are required. • Network equipments such as routers or switches are included. Storage • Storage hardware and software supporting all the functions described above so far. • Required to be an integrated environment under unified management with reliability, availability, and flexibility; and, in cases, virtualized implementations are required. iDC Facility • A physical environment and programmed operation / maintenance services supporting the servers and storage devices described above. (Physical environment: the entire facility and location-environment including buildings / machine-rooms / installation-spaces, and equipment for power / air-conditioning / communication / fire-extinguishing /security.) Network Technology Domain Definition EIP • An integrated portal service used in a limited capacity by the ministries. • Note that functions related to groupware are generally excluded, and mechanisms for information-delivery and sharing through portals are included. Public web server • Hosts the public — externally accessible — homepages • Desired to have integrated content-management functions including CMS, etc. • Also desired to have simple functions for information gathering / acceptance Groupware / File Server • A mechanism supporting groupware functions such as mailing / scheduling / booking facilities or conference rooms, and handy information sharing. • Note that, when the technology domain is implemented using portals, some functions overlap with those of EIP. Integrated Account Management / • Refers to a mechanism comprehensively managing users in an integrated manner. 26 Authentication / • access-control. Permission Integrated Directory Unique IDs are allocated to all users for authentication and • A meta-directory supporting the above-described Integrated Account Management / Authentication / Permission. • Desired to serve as a parent directory of various directories implemented and used in other systems. WAN Ministry’s Internal • A main body of network services, including physical communication lines and DNS / DHCP / Proxy. LAN • Desired to have basic security features. Shared PC / • PCs or Printers shared in offices. In-Office-Shared Printer • Must be equipped with mechanisms for implementing and maintaining versatile and secured environments. • Note that dedicated equipment for specific job-operations is excluded. Remote Access • A mechanism for accessing a ministry’s internal LAN from outside of the ministry office. • Desired to have supplemental security-protection functions such as VPN or authentication, network-connection environment. 27 as well as a 4.1.2. Intended Items of Procurement This subsection shows the intended items of procurement where the definition of domains for services and goods are listed separately, where services, designs and developments are described. Note that expense of operation / maintenance, migration / transition, or installation is excluded. Structure of Items of Service Procurement Application Design and Development of Individual Business System (including physical design of DB) Common Platform System Design and Implementation of Workflow / BAM Design and Implementation of BI / DWH / ETL Network (Design and Implementation of ESB, BPM, Service Repository and Web Service) Design and Implementation of Maintenance Environment Design, Implementation, Deployment and Installation of Server Design, Implementation, Deployment and Installation of Storage Remote Access physical design of DB) Design and Implementation of SOA Design and Implementation of EAI / External Linkage (Configuration Design / High Reliability Design / Performance Design / Integration and Virtualization Design / Physical Design of DB) Design and Development of Common Business System (including Design and Implementation of Legacy-system Integration iDC facility Design of Operations and Development of Management Tools (including the following functions: Monitoring, Backup, Trouble Administration, Recovery Operations, Configuration Management, Resource Management, Resource Planning) Security Design and Construction (Configuration Design, High Reliability Design, Functional Design, Integration / Virtualization Design) Design and Implementation of Shared PCs Design and Implementation of Printers shared in Of f ices (including network security and personal information protection) Design and Implementation of EIP Design and Implementation of a Public Web Server Design and Implementation of Groupware Design and Implementation of a File Server Integrated Account Management / Authentication / Permission Design and Implementation of an Integrated Directory Design and Implementation of a WAN Design and Construction of a Ministry’s Internal LAN Figure 4.1-2 Structure of Items of Service Procurement in Relation to Technology Domains 28 Structure of Items of Procurement of Goods Application (Software Products working as a functional element or an engine in individual business system) Software Products used as an element or an engine of common business system Products for Remote Access (Dedicated Terminals or Printers) (AP Server, Development Tools) Common Platform System Workflow Products Products for SOA BAM Products (including ESB, BPM, Service Repository, Webservice Products) Products of BDI / DWH / ETL Maintenance Environment Products for EAI Software Products for EIP System Operation Management Software Products Software Products for Public Web Servers Security Software Products Groupware Products File Server Products Mail Server Products (including Development Tools and automatic-test tools) Server Product Network (Server, Router, Switch, Highreliability Product, Integration / Virtualization Product, Web Server, AP server, DBMS, OS) Products for Remote Access Storage Products iDC facility (including storage devices, highreliability products, products for integration or virtualization) Software for Integrated Account Management / Authentication / Permission Software Products for Directory Management Communication-line subscription f or WAN Shared PC (PC, COE Management Software, OA Software Products, Security Software Products, OS) Shared Printers in Offices (Hardware and Software Products for Management Equipments f or Ministry’s Internal LAN Figure 4.1-3 Structure of Items of Procurement of Goods in Relation to Technology Domains 4.1.3. Guidelines for Necessity-judgment of the Employment of Technology Domains in Procurements Note that the Functional Configuration Model or Categorization of Procurement described above should be flexibly applied to actual procurement: unnecessary items, even if listed in such models, should be excluded, and on the other hand necessary ones should be added. Basic ideas for deciding whether a certain technology domain must be included in the procurement or not is shown below: Application Technology Domain Necessity of Technology Domain Individual job-operation ・ Mandatory Linkage ・ Optional (rarely required) ・ Required in case of the procurement of dedicated tools for systems to legacy linkage. Generally the function is included in job-operation systems, EAI, or external linkages. 29 Common Platform System Technology Domain Necessity of Technology Domain Common job-operation ・ Optional (highly required) ・ For details, refer to “4.3. Guidelines for Procurement of Job Applications.” Workflow and BAM ・ Optional (rarely required) ・ For workflow tools (other than BPM). If such tools are commonly used among more than one individual job-operation system, such tools should be included in the procurement of common platform systems.. BI / DWH / ETL ・ Optional (fairly required) ・ In many cases, such tools are more reasonably implemented as a part of an individual job-operation system than implemented as a component of the common platform system. EAI ・ Optional (fairly required) ・ In some certain cases, the function is fulfilled in SOA-related-functions. SOA Related Function ・ Optional (highly required) ・ Refer to “4.3. Guidelines for Procurement of Job Applications.” System operation and ・ Mandatory Security ・ Note that the functional coverage should be determined carefully. Maintenance ・ Mandatory Environment ・ Note that the functional coverage should be determined carefully. Server ・ Mandatory ・ Note that the functional coverage should be determined through a trade-off analysis with use of external resources. Storage ・ Optional (not highly but likely required) ・ In cased of small configurations, storages will often be included in servers. IDC and Equipment ・ Mandatory ・ Note that the coverage should be carefully determined through a trade-off analysis with use of external IDC resources: whether having IDCs in-house is better or not than using outside resources. 30 Network Technology Domain Necessity of Technology Domain EIP ・ Optional (fairly required) ・ In some cases, the function is fulfilled in a groupware or a file-server. Public Web Server ・ Optional (fairly required) ・ In some cases, public web servers are often procured independently. Groupware and ・ Optional (highly required) File-server ・ In some cases, a groupware, or a file-server is procured independently. Integrated Account ・ Optional (fairly required) Management, ・ In some cases, those functions are included in procurement Authentication, and such as common job-operation systems or individual Permission business applications. Integrated Directory ・ Optional (fairly required) ・ In some cases, the function is fulfilled in other procurements such as integrated-account-management, or authentication and permission. ・ Mandatory Shared PC and ・ Optional (highly required) In-office-shared Printer ・ In some cases, those are procured independently. Remote Access ・ Optional (fairly required) ・ The purchase decision depends on specific requirements of WAN and Ministry’s Internal LAN ministries and agencies. Also note that, as for packaged software products or middleware software products described later in “4.4. Policies for Defining Business Application,” decisions of procurement should be done after trade-offs, such as whether the products should be procured for the use limited in the individual job-operations, or whether they should be procured as an infrastructure shared by more than one job-operation. For an example, CRM software products or RIA software products, not listed as an infrastructure on the assumption that they are used in individual job-operations, are allowed be procured included in shared infrastructures. Refer to “5. Descriptions of Technology Domains” for preparing procurement specifications of packaged software products or middleware software products, where “Basic Features”—functions expected to be included in standard products—are effective to eliminate products not having acceptable features, and “Additional Features” should be used to pick up products having features 31 that are expected to be effective or indispensable to the realization of the individual job-operation. Especially for the procurement of large systems on which the separate-procurement rule is expected to be applied, it is recommended to use fully “Additional Features” not to overlook indispensable features from the standpoint of expandability or automation of system operation and management. On the other hand, for a small-scale system, note that the “Basic Features” may be over-requirements from the standpoint of functions, performance, and reliability, and trade-offs should be made before picking up the features as indispensables. 4.1.4. Items of Procurement Although services and goods should be procured separately, installation work requiring no design work, such as carrying-in and emplacement of hardware or installment of software, can be included in the procurement of goods and services as incidental work. Also, maintenance of hardware products and software products should be included in procurement of goods. In addition, in the case of low-budget procurement, services and goods are allowed to be procurement simultaneously if such combined procurement of services and goods will be fully expected to contribute to the simplification of the maintenance scheme or the simplification of procurement process. - Procurement of Service As for a unit of service procurement, different policies should be applied to different phases — the design / development phase and the maintenance / operation phase. These policies are described below. Note that they are supposed to be applied to the procurement of service, and in other cases they should be used only as references. In the design / development phase, different policies are applied to individual job-operations and common job-operations. Especially, for the case of common job-operation, treat all elements grouped in the technical domains for the common platform system as a unit of procurement, and then, according to the necessity of specialized technologies, determine the domains to be procured independently while taking care to prevent the increase in the number of vendors by limiting the targets of separation to as few as possible. At the same time, determine the unit of separation flexibly but generally following technology domain separation. In the maintenance / operation phase, it is essential to treat maintenance and operation separately. Maintenance means handling problems, addition of functions, modification, and tuning, etc. by vendors having sufficient knowledge of the system. Operation means system monitoring, preliminary failure analysis, and back-up by vendors having no special knowledge of the system, and working according to manuals. Note that hardware maintenance or software-product maintenance should be procured as a part of the procurement of goods, and not dealt with here. 32 Generally, maintenance should be done continually by the providers of the design or development in the design / development phase. Note that, though, because maintenance of packaged software-products or simple systems done by minimal development effort requiring no special tuning could be assigned to other vendors than the provider of the system. It is necessary to take the above into consideration. System operation, because less dependent to the vendors of design / development, will be recommended to be consolidated as tightly as possible not simply following the unit of procurement in the design / development phase or maintenance phase. - Procurement of Goods The procurement of goods should be consolidated so that the number of procurements is as small as possible. Note that, however, special-not generally available-goods, goods not procured along with other goods, or goods probably requiring contract-renewal on design modification or redesign will be practically procured separately. 33 4.2. Physical Configuration Model The Physical Configuration Model was prepared as a reference model for designing entire information system configurations, providing tangible system configurations of the two types of systems—“network systems” and “common platform systems,” which were accepted as realistic models in the government and will be frequently referenced to in actual government procurement processes. Note that the Physical Configuration Model, represented in the diagrams below, should be used as a configuration example. Therefore, it is not required to install individual physical devices or equipment corresponding to the functions shown in the model: more than one functional element could be realized by a single device, or some functional elements could be fulfilled by existing devices. Items to be procured — systems or devices — should be determined by taking into consideration all factors of the individual project, such as requirements of optimization or utilization of existing resources. Of the Physical Configuration Model, the Network Physical Configuration Model provides the entire model-structure of networks used inside government ministries or agencies, and the Common Platform System Physical Configuration model provides the basic model-structure common to the servers on the Network Physical Configuration Model. The Network Physical Configuration Model is based on the outputs of the 4th working group (information security) of the Liaison Conference of Deputy CIOs, etc, providing the six model segments of the internal network of the ministries and agencies — S1 to S6 — created through the analysis of the information system optimization plans by the ministries and agencies, where the segments S1, S2, S3, S4, S5, and S6 respectively correspond to DMZ, intranet servers, the central government LAN, outside-the-central-government servers, network, and information remote-access / extraction. 34 Figure 4.2-1: Physical Configuration model of Network The Common Platform System Physical Configuration Model was created from the stand point of servers in the ministries and agencies, providing the structural model, where common platform system basic functions are fundamental functions commonly used in the ministries and agencies, including the following: network access, user registration / authentication, common database management (optional), API or protocols for individual business applications, linkage to other systems (optional), common security infrastructure, system operation / maintenance infrastructure, common applications (optional), common public portal (optional), common repository, and others (“optional” indicates that the function is selectively required). 35 Figure 4.2-2: Physical Configuration Model of Common Infrastructure 36 4.3. Categorization of Service-Work While, in the case of procurement of goods, the technology domains in the Functional Configuration Model —defined with a focus on the procurement of gods, —is well-applicable, in the case of procurement of service, a categorization according to the procurement phases of information systems would be easier to understand and apply. Procurement of services starts with the planning phase, and proceeds to the requirement definition phase, the development phase, and the system operation / maintenance phase. Major categories of service-work are shown in Figure 4.3-1 in relation with the phases of procurement. Refer to the Ch.6 for the details of service-work and the essential points to be described in procurement specifications. Planning phase Requirements definition 要件定義 phase Operation/maintenance 運用・保守フェーズ phase Development phase 開発フェーズ 6.2 6.2.3 Support for ( 等) procurement (Project management, etc.) 6.3 6.4 6.4 Operation 6.5 Helpdesk 6.1 Support 6.1全体計画 for master 策定支援 plan formulation 6.2.2 Support for procurement 6.2 1 調達支援 (requirements ( 等) definition, etc.) 6.3 System integration (design/development) 6.3 ハードウェア更改 6.3 機能追加 6.6 Maintenance 6.7 Tasks incidental to procurement of devices Hardware maintenance Software maintenance Application maintenance System infrastructure maintenance 6.8 Tasks incidental to procurement of iDC equipment ・ 設備) 6.9 Network procurement 6.12 Security Figure 4.3-1: Categorization of Procurement of Service 37 The system development phase consists of the sub-phases — design, development, test, and system-migration — and is followed by the system-operation / maintenance phase. Note that the following are included in the category of system development: development from scratch (new development); renewal of existing systems (system renewal); system migration required for renewing hardware (hardware renewal); and addition of sub-systems for augmenting functions (functional augmentation). Also note that application maintenance, in some cases, includes partial modifications of existing applications. For details, refer to the Figure 4.3-2 for the relationship of maintenance service-work to the categorization of the system development service-work (design / development). Also, note that the procurement of service-work requiring design work (basic design or detailed design), and the procurement of service-work (including correction of design documents) requiring no design work are respectively categorized into the Section 6.3 System Integration (Design / Development), and in Subsection 6.6.3 Application Maintenance of Section 6.3 Maintenance. Refer to the Ch.6 for description in detail. Attributes of Service Service Items Design ■New Development ■System Renewal ■Hardware Renewal ■Sub-system-level Functional Augmentation Development / Test / System Migration <Design / Development in System Integration> New Development System Renewal Hardware Renewal Functional Augmentation ■Modification (Correction, Functional Augmentation, Bug-fixing) (Design Correction) Maintenance (Scheduled Maintenance / Inspection) Including Defect-warranty work <Maintenance> Application Maintenance Including Defect-warranty work <Maintenance> ■Procurement of Application Maintenance requiring no development work Application Maintenance ■Maintenance of others <Maintenance> Hardware Maintenance, Software Maintenance, System Infrastructure Maintenance Including Defect-warranty work Figure 4.3-2 Mapping of Application Maintenance on Categorization Chart of Design /Development 38 The Figure 4.3-3 shows the mapping of the categories of service work on the Functional Configuration Model for Procurement of Service, suggesting the following: as for the development phase, almost all the services in the Functional Configuration Model are categorized in system integration, compared with the procurement of networks or incidental work to iDC equipment categorized as individual services. As for the procurement of server or storage, design / integration are contained in the category of system integration, and implementation / installment is categorized as an incidental work to procurement of goods. System operation / maintenance are procured in the system-operation / maintenance phase. Note that, in the Figure 4.3-3, the planning phase or the requirement definition phase is not shown. 6.4 Operation 6.6 Maintenance 6.3 System construction 6.7 機器調達付帯作業 6.8 Tasks incidental to procurement of iDC equipment 6.7 Tasks incidental to procurement of devices 6.3 System construction 6.8 iDC設 備調 達付 帯作 業 6.9 Network procurement 6.9 Network procurement Figure4.3-3 Mapping of Services on the Functional Configuration Model for Procurement of Service 39 4.4. Policies for Defining Business Application The applications in the Functional Configuration Model are defined according to the Job-Operation Manual— the individual job-operations are defined in “application” and the common-job operations are defined in “common platform,” respectively. However, as for common job-operations, the different types of descriptions are generally used according to the following three cases: A: Specific job-operations belonging to higher job operation layers such as electronic payment; B: System functions provided by the common platform system such as BPM or BI; C: The lower common-services used by the higher services defined in the SOA. Generally, defining the boundaries of common jobs and individual jobs — more specifically, extracting common job-operations from entire job-operations— is not easy. However, in the case of A, because the functions are defined more clearly compared with other cases, definitions or extractions as mentioned are easily accomplished by defining interfaces to and from individual job-operations through clarifying the scope of the job-operations, functions and requirements. As for B, the difficulty comes from the lack of consensus or clear image of the functiond provided by the common platform system. This Technical Reference Manual is expected to solve this difficulty through sharing knowledge of the functions provided by the common platform system. If the common platform is used for the purpose of running applications on the common platform, it is indispensable to have attitude to use various functions proactively; through the utilization of the common platform system, it is expected to reduce the volume of development, risk and cost of the project, or maintenance cost of application. As for C, the degree of difficulty depends largely on the service granularity described in the SOA or how the common job-operation is extracted and defined. Because widespread of SOA concepts and related technologies such as SaaS are insufficient and the applications still remain in transitional stages, the difficulty requires time to be resolved. Therefore, especially for C, it is recommended to treat the category as one of the step-wise approaches described later, and at the first step, procure individual systems closed to individual job-operations from the developers of individual job-operation systems instead of procuring the common platform system from the developer of such common platform systems. In the following sub-sections, policies of application-system development of job-operations are described. 4.4.1. Stepwise Approach and Redefinition of the Entire System Architecture 40 The Stepwise approach is one of the critical methods of the system configuration-design of common job-operations, especially for category C described in the previous sub-section: because when a project's scale is large and a long-term “waterfall-model” development approach should be applied, the coverage, functions, and strictly-defined requirements are required to be completed prior to the development, job-operation analysis including BPR, and “ToBe” type breakdown of business processes from the highest concept to detailed processes is prerequisite — thoughtless acceptance of the existing job-operation flows, or simple copy-paste of the existing displays would result in a re-building of old legacy systems. However, in many cases, such an approach like that described above is not easy to apply because of a shortage of skills and experiences on either the procurer or provider side, especially in today’s situation where the SOA or its related technologies such as SaaS are not proliferated and widely accepted. Therefore, a practical way is recommended as follows: first of all, squeeze the scale of a project suspected to be a long-term-waterfall type, and then apply a stepwise-development approach. For squeezing the scale of project, the following two approaches, except for cutting-down the system coverage or reducing job-operation functions are generally applicable: The first is division of project — dividing a project into reasonable pieces satisfying time and cost conditions, where the job-operations are allocated to sub-systems that are loosely coupled by EAI or some other similar methods: also, division into sub-systems is accomplished so that an integrated DB based on DOA (data center) is placed at the center around which applications are placed. The approach requires redefinition and reconstruction of the entire architecture. Note that the approach will not produce a simple division of procurement in accordance with the structure of the existing sub-systems. The second is the application of package-products described later which will drastically reduce the volume of development, where division of project and fundamental reduction of development-volume should be simultaneously considered. Note that the clear definition of the entire architecture is indispensable as a prerequisite of such considerations. As described above, the project-scale squeeze and the development-volume reduction will make up the application of the stepwise approach. The stepwise approach will desirably proceed along the steps as follows: at the early stage, construct the system on the basis of services of large granularity connected loosely by an EAI-like method; then, divide each service into services of smaller granularity step-by-step; and finally specify common services. Note that the stepwise approach should desirably be applied incrementally to a single flow of design to system-operation, and cyclically over a long period. The stepwise approach should be realized through the formulation of the entire architecture at first, followed by proof-of-concept experiments or prototyping of the common platform system and pilot job-operations, executed in the following processes or in the combinations of processes: • Persons procurers, execute in the planning phase following the advices made by Deputy CIO; 41 • Contracted service provider executes architecture formulation, proof-of-concept experiments, and prototyping; • Contracted system providers execute in the “confirmation of basic requirements” work. Through the processes in the stepwise approach, the systems are incrementally implemented, and at the same time maintenance and restructuring of the entire architecture are necessary. This Technical Reference Model is expected to support the formulation of the entire architecture and smooth execution of subsequent work. 4.4.2. Fundamental Reduction of Development Volume through Employment of Packaged Products Some of the computer systems used in public sectors, developed in the early days of computing, still continue to use the architectures of those days. Packaged software applicable to job-operations requiring no customization would be perfect for fundamentally reducing system development volume. Although those applicable to the job-operations in the ministries and agencies are rare, some of general-purpose packaged software products, middleware products, and internet technologies will be applicable. Therefore, although the best is to find and employ packaged products just-fit to the objective job-operations, the application of packaged products, even if best-fit packaged products were not available, could fairly reduce the development volume in some cases like those described below: • CRM products: Case Management CRM products are used in businesses for comprehensively managing customers — attributes, sales-history, sales-promotion-history, conversations, and support-history including response to complaints. CRM software products will be applicable to the government job-operations requiring case management to individually support citizens and private businesses, such as tax-related jobs or health-insurance-related jobs: CRM products are expected to serve there as engines. • Spreadsheet: Ledger Management In job-operations requiring management of ledgers, spreadsheets will be desirably used for creating electronic images of ledgers. In cases where the ledgers are shared among job-operators, or large sheets exceeding the capacity of spreadsheet are used, RDBs on the back-end linked by SQL or web-services to the front-end spreadsheets will serve well. Also, middleware software is applicable there. • BI tools: Reference / Search, Outputting in forms, and Statistical Processing 42 BI tools will be successfully applied to data reference / search / analysis, and printing-data-in-forms, and drastically reduce development volume in case management, ledger-management, or in other systems. Especially for statistical analysis jobs, the data-mining functions of BI tools are highly useful. • RIA Technologies: Screen-handling Programs In the screen-handling programs used in mainframes, due to various technical constraints, the volume of information displayed on a screen is limited: job-operation screens were divided into pieces, and the operators had to execute jobs through complicated job menus for the computer-system-side convenience. Also, as for C / S based job-systems, it was a concern that as a consequence of an easy transfer of C / S to Web, the user friendliness which the originals have had would be lost, or the volume of information on a screen would be limited due to the limitation posed by the features of the browsers used for screens. Recently, RIA technologies such as Ajax enable web-based systems to provide user-friendliness and sufficient information on screen: through the use of such technologies, the following is expected: reduction of the number of screens and development volume; improvement of user-operability, job-operation-efficiency, and user-satisfaction; and reduction of maintenance / training cost. Moreover, because having superior functionality for linkage to services on the internet, the RIA technologies are effectively applied to low-cost-use of information on the internet such as map information or bibliographic information. • PC Packages with SOAP Interface: Screens One of the integration methods of job-operation systems using SOA is as follows: the servers provide various types of functions usable as Web-services, and PC packages with SOAP interfaces use the Web-services as the users of services. The approach will be effective for providing flexible screens satisfying individual user requirements — with smaller development man-hours. The PC software products for the above-described purpose are supposed to be the following: software packages for OA such as spreadsheet-software; mailers; and dedicated products to the job-operations. On the other hand, the Web-services on servers will be implemented in the following ways: applying the products whose functions are usable as a web-service based on SOA; or augmenting the existing systems by adding Web-service interfaces. • BPM and Integrated Directory: Workflow Management of decision-making processes Workflow management of decision-making processes is a mechanism for the management of decision-making processes called “Ringi” where more than one decision maker sequentially reviews and approves a circulated decision-request. In workflow management, in such processes, 43 considerable work is spent on the preparation of information necessary for decision-makers or the arrangement and management of circulation routes. Utilization of BPM products available on the common platform system and the integrated directory available on networks will be one of the effective alternatives to specialized products for workflow management. • Service-Reuse: BPM products and ESB Products In cases where service-reuse is required, the utilization of BPM products or ESB products should be considered first. One of the reasons that service-reuse is difficult in conventional application systems is that how functions are combined or what branching conditions change the course of processes is coded in the programs or JCLs. On the other hand, the utilization of functional services through BPM products or ESB products is expected to promote the reuse, and as a result the business applications are expected to become more flexible and more maintainable. The concept of service-orientation — the base of SOA — puts more emphasis on reusability than on system-development. Job-operation models, job-flow models, and common / standard functions based on the concept of usability are becoming available, of which the application can be expected to largely reduce the risk and the volume of development. • Utilization of Cloud Services The functions so far described will realistically be realized by cloud services in addition to the utilization of packaged products (reference to “4.8: Standpoints of Cloud Users” for the utilization of cloud services, and “4.9: Standpoints of Cloud Designers” is recommended.) Because cloud services are expected to rapidly expand from those that have been described so far and those currently available on the public cloud such as CRM, Spreadsheet, BI, and Groupware, application of cloud services should be considered in every project in future. Although the employment of cloud services has potential advantages such as low-initial development cost, short lead-time, flexibility to increase / decrease of the operational requirements, smaller operational work-load, or low energy consumption, assessments on the following should be made before the decision of employment of cloud services: availability of services; institutional constraints; security and BCP; and SLA. List and confirm the critical items of the service level agreement (availability, reliability, data management, and security). Also note the following: the application of cloud services still remains in its early stage, and the number of domestic applications is still small; they will be procured by procurement-of-service, instead of procurement-of-goods; and procurement of cloud services, especially public cloud services, will possibly lead to another vendor-lock-in — narrowing the selection of vendors —, because market-availability is still small. 4.4.3. Requirement-Definition in the Application of Packaged Products, etc. 44 The easy duplication of requirements of the existing systems without re-evaluating the necessity, or simple acceptance of the requirements by job-operators leads, in many cases, to a situation where the application of packaged products is difficult and the estimated development-volume remains large. To avoid such situations, hold, as a goal, the application of packaged products and keep the policy of satisfying the true job-requirements through the application of packaged products. The design method strongly recommended is the following: at the early stage where the packaged products to be used are not yet determined, design the system based on the generally available functions referring to Ch. 5 of this Technical Reference Model and others, and after determining which packaged products to use, review, make adjustments, and finalize the design. 4.4.4. Review Process in Stepwise Approach The stepwise approach, in addition to the advantages in reduction of project-risk or development volume, will greatly contribute to the implementation of a high-user-satisfactory system. In the conventional waterfall-model approach, as a matter of practice, modification of design or implementation following the users’ comments in a timely manner is not easy: request for comments on the system design collects no responses because the users could not imagine how the systems will be used in the actual job situation of them, and users return comments or complaints back just after the implementation is completed when they touch the system; and those comments given in the final phase are often not reflected in the system because such reflection would roll-back the project, or even put the project into confusion. In the stepwise approach, review of the actual system is strongly recommended in the design phase: primary functions and screens, not necessarily all, are implemented in the design phase; users are requested to operate the system and make comments; and those functions and screens are modified to satisfy the users; and the rest of functions and screens are determined sequentially. The review-on-the-system, described above, is largely expected to contribute, not only to user-satisfaction, but to reduction of roll-back in the final stage and avoidance of project-risk, and reduction of development-volume or promotion of packaged-product-application as a result of these efforts to make the reviews easy. 45 4.5. Policies for Common Databases On the reconstruction to a large extent of systems towards total optimization, data-review is also indispensable: reviewing locally-optimized databases and then constructing the totally-optimized common database (hereinafter referred to as a “common DB”) is expected to, through the rationalization of the entire system, to contribute not only to the cost-reduction, but also to high-level administrative work and the provision of services to citizens. 4.5.1 Definition and Realization of the Common DB The following three types of databases orienting the common DB have been under consideration in forward-thinking ministries and agencies: Common DB as total optimization: optimized DB used by the whole government; Common DB as core: DB used as a core of primary jobs of specific ministries; Common DB for reference: DB widely-used for referencing the data related to specific jobs of specific ministries. The common DB as total optimization is expected to collectively store the fundamental data of private businesses or citizens. For private businesses, total-optimization focusing on the corporate financial / tax information data based on commercial-registration data is required, and for citizens, optimization — spanning ministries, and local governments — focusing on the data on the Basic Resident Register based on the census register is required. Because there are many problems of concern due to a large number of stakeholders, big influence, and protection of personal information, the common DB as total optimization is out of the scope of this document. The common DB as core — well expected to be used for patent administration in the Japan Patent Office — is expected to be an essential database for specific ministries and agencies required to do particular jobs. However, the target ministries and agencies are limited. The common DB for reference — well expected to be used for statistical analysis, etc. — is desired to be planned or implemented in many ministries and agencies. Although, whether the preparation of the Common DB is treated as an individual job or as a common job is dependent on the decisions of the ministries and agencies, an architecture covering the entire system that minimizes the overlaps over more than one job-operation. At the same time, a common data base, even when implemented for the purpose of particular ministries and agencies, is desired to be implemented in such a way that interfaces compatible with open standards for the public access or referential access are prepared. Note that such data as that expected to be prepared in particular common business system for Ministries — personnel and payment, document management — is out of the scope of this document. 46 4.5.2. Policies for Job-Operation System-Implementation using Common DB Systems using common DBs should be designed and implemented on the basis of software products such as BI or CRM. Even implemented from scratch or add-on — customizing such products and adding on the system, those systems should be designed so that, in accordance with the concept of DOA, applications surrounding the database placed in the center of those applications, use the database, instead of the data embedded and confined in applications. Also, the systems should be designed so that processes related to data modification and processes related to data reference are separated, for purpose of wide data-sharing. Especially in cases where the SOA is applied, processes (services) related to data modification should be able to provide the modified data as a service provider to allow the processes (services) related to data reference to use the data as a service consumer: such service-functions such as providing and referencing data will promote not only wide-sharing of common DBs, but system reuse. 4.5.3. Responsibility Sharing among Integration Service Providers on Common DB As a general rule, physical design / implementation of common DBs is the responsibility of the providers of common platform systems, and logical DB design / implementation is the responsibility of the providers of individual job-operation systems. However, note that in cases where construction of common DBs is treated as a common work instead of independent work, the provider of common platform system will be responsible for everything, because the provider does the work of DB logical design / implementation. Note that system operation / maintenance is allowed to be assigned to the provider that did the design / implementation work. 4.5.4. Stepwise Approach in Common DB Planning / Implementation As for the common DB planning / Implementation, it is strongly recommended to apply the stepwise approach — proof-of-concept experiment, implementation of parts of systems, and implementation of the entire system. Also in the early stages of the stepwise approach, it is recommended to arrange the development structure so that the provider assigned to the logical design / implementation takes the responsibility of physical design / implementation: it will improve the efficiency of work. Note that individual DB-implementation will easily lead to problems such as inflation of maintenance costs and troubles when the system is required to expand: it is desirable to consider as seriously as possible the application of DBs that are widely shared. 47 4.6. Policies for Implementing Common Business System for Ministries One of the purposes of common business system for Ministries is total optimization — optimizing the government systems as a whole beyond the boundaries of ministries. Therefore, common business system for Ministries must be visibly effective in reducing and streamlining ministry-dedicated systems. 4.6.1. Policies for Connecting with Ministry-dedicated Systems Common business system for Ministries should connect with ministry-dedicated systems through interfaces that are as simple and as loose as possible, because common business system for Ministries linked to other various systems, should be as immune as possible to the changes in those systems, as generally required in system connections. For such loose connections, use interfaces that are prepared by the common business system for Ministries, and do not implement unique interfaces unless strongly required for some special reasons. Workflow, authentication infrastructure, and other common functions prepared by the common business system for Ministries should be proactively used, because such functions will be a considered as a part of common job-operations. However, note that employment of such common functions does not always result in the elimination of the necessity of ministry-dedicated implementation of the functions. Ministry-dedicated systems are not only required tentatively and temporally in the case of stepwise implementation / deployment, but required in the case of a To-Be-model to satisfy particular requirements of ministries, where the simple and individual implementation of ministry-dedicated systems would be more realistic than the complicated application of common business system for Ministries. Note, therefore, that in any case, the decision of individual implementation should be done after sufficient consideration and assessment. 4.6.2. More Total-optimization-oriented Implementation Approach In implementing common business system for Ministries, arrangement and planning from the standpoint of total optimization is strongly recommended even though implementation and migration of common business system for Ministries is often planned on system-by-system basis, because common business system for Ministries have mutual dependency in such functions as authentication, workflow, and employee information. In such total arrangement and planning, the following are included as major issues: deployment schedule; data migration; and linkage to existing systems. In addition, covering existing systems and also systems in the planning phase, arrangement and planning on the following is strongly recommended: directory information, authentication, and character code including extended codes 48 4.7. Virtualization Technologies Virtualization masks boundaries or physical features of IT resources by inserting a virtual layer between a resource and a resource-user (OS or application) to enable flexible use of resources (Figure 4.7-1) which originated in the technologies developed to improve the hardware utilization efficiency in 1960s, Virtualization has recently been gathering attention as one of the solutions for IT problems such as utilization-efficiency-decrease and cost-increase in infrastructure, cost-increase in IT management, and increase in energy consumption. Section 4.7 provides policies for virtualization where the IT resource is hardware, and the user is an OS (refer to *1). Note that there are two types of virtualization mechanisms: realized by hardware for virtualization; and realized by software for virtualization. Application Virtual Layer OS, Middleware Virtual Layer (*1) Hardware (Server, Storage, Network and others) Figure 4.7-1: Conceptual Diagram of Virtualization 4.7.1. Policies for Application of Virtualization Technologies Virtualization technologies can enable improvement of the efficiency in IT resource utilization. Also, hardware virtualization expectedly reduces footprint and power consumption, and in addition, increases system flexibility that leads to a reduction in system-operation and management work load. However, note that virtualization could increase system overhead, or in case of the virtualization of existing systems, migration may sometimes require modifications of application programs. 4.7.2. Types of Virtualization ・ Server Virtualization In one type of virtualization, more than one virtual server shares one physical server, and in another type, one virtual server runs on more than one physical server utilizing all the power. This sub-section describes the former, because it will be more realistic in the actual procurement. Server-virtualization software products enable construction on a physical server of more than one virtual server running independently by an independent OS. Virtual Machine Monitor (VMM) is one of such products, 49 providing independent virtual servers (virtual machine) through hardware simulation, — in some cases the virtual server is called a “guest server,” and the OS on a virtual server is called the “guest OS.” VMM software products are generally categorized by host-type VMM and hypervisor-type VMM, which are shown in the Figure 4.7-2. Application Application Guest OS Guest OS Virtual Machine Virtual Machine Host-type VMM Application Application Management Tool Guest OS Guest OS Management OS Virtual Machine Virtual Machine Virtual Machine Application Host OS Hypervisor-type VMM Hardware Hardware Host-type VMM Hypervisor-type VMM Figure 4.7-2 Two Types of Server Virtualization ・ Storage Virtualization Various types of storage virtualizations are available: in “dividing storage,” one storage device such as a hard-disk drive has more than one virtual storage; in “storage consolidation,” more than one physical storage is consolidated into a huge virtual storage; and in “storage-capacity virtualization,” the storage-capacity that a server will know, is not limited by the physical capacity. Note that by storage-consolidation more than one physical server can be consolidated beyond the boundaries of its chassis, in comparison with the storage device consolidation enabled by RAID. ・ Network Virtualization “VLAN” is a virtual network independent of physical connections, enabling terminal-grouping. Another is “network device virtualization,” where a physical device such as a router, switch, firewall, or load balancer works as more than one independent device, or more than one device is consolidated to work as a single device. ・ Desktop Virtualization Desktop virtualization is a screen-transfer-type thin-client technology where the server processes applications or saves data, and the client handles input / output devices such as a keyboard or mouse. As shown in the Figure 4.7-3, screen-transfer is realized by server-based-computing, a blade-PC, or a virtual PC (VDI). In the virtual PC scheme, more than one virtual client machine is composed on a physical server where OSs or applications belonging to virtual machines are running. 50 Desktop AP Desktop AP Desktop AP Terminal Service Desktop AP Desktop AP Desktop AP Desktop AP Desktop AP Desktop AP Client OS Client OS Client OS Client OS Client OS Client OS Virtual Machine Virtual Machine Virtual Machine Server OS Blade Hardware Server-based-computing Blade Hardware Blade Hardware Blade-PC Hypervisor Virtual PC Figure 4.7-3: Three Schemes of Desktop Virtualization 4.7.3. Points to Consider in Integration by Virtualization The following are points to consider in system-integration by applying virtualization technologies: ・ Design and assessment should be done for each unit of virtualized-resource allocation, physical resource, and resource-pool, instead of conventional hardware- resource sizing; ・ Consider application, in the virtualized layer, of an N-to-N model covering the entire resource-pool for the server-availability requirement, instead of the conventional design based on one-to-one or N-to-one model in hardware layer; ・ Consider monitoring and security of the management-layer of the hypervisor, virtualized server, and cloud, in addition to the conventional system design; ・ Pay attention to the possible performance-degradation, invisibility of resources from the management side (difficult to view), and resource-conflicts in multi-tenant environments; ・ Confirm the compatibility of the hardware products planned to be procured with the virtualization scheme to be employed; ・ Confirm the compatibility of the software (program) products planned to be procured with the virtualization scheme to be employed; ・ Note that there is a possibility, in the migration phase to the virtualized system, that the virtually realized functions — especially those related to device drivers — do not work in the same way as the originals. ・ Prepare migration plans (of sizing, verification, data-migration, and others) for the migration from physical environments. 51 4.8. Standpoints of Cloud Users “Cloud” generally refers to an information processing mechanism using networks through which information-services are provided or used on demand, which should be treated from the following two standpoints: users' standpoints that a cloud is an environment through which information services are provided to be consumed by users; and service-providers' standpoints that a cloud is a tool implemented by providers to deliver services. This section describes the points that cloud users should remember from the standpoints of users — who use services delivered through the cloud. 4.8.1. Basic Policies for Selecting Cloud Services Clouds, which could be categorized in many ways, are basically, according to the user-acceptance policy, categorized into the following two: a public cloud constructed on the internet and providing services on the assumption that it is accessible by the general public; and a private cloud providing services constructed on the assumption that it is accessible only by specific users. Note that a cloud closed to a “community” formed by users having common objectives is called a community cloud, which can be categorized in between those mentioned above. This section describes policies for selecting service-delivery mechanisms among the following: commercial public clouds by private providers; the ministry clouds, closed in a ministry and agency; community clouds such as the government common platform, shared by ministries and agencies; and on-premise, a conventional service-delivery not categorized in clouds. Note that, for classifying clouds, except for the categorization by openness mentioned above, the following categorizations by what is delivered as a service is helpful: SaaS (Software as a Service), where services are delivered to applications; PaaS (Platform as a Service), where services are delivered to a platform (on which applications run); and IaaS (Infrastructure as a Service), where services are delivered to an infrastructure (hardware or iDC). Figure 4.8-1 shows the categorization of clouds along two axes; assumed users of services, and provided services. Note here that, because combination of clouds, such as “hybrid” (combination of different services) or “multi” (combination of services from different providers) can be allowable, assessments matching the usage or purposes will be necessary. 52 SaaS PaaS IaaS Public Cloud Community Cloud Private Cloud On-premise Commercial Service Providing Web-mail Related Functions Commercial Service Providing CRM Related Functions, etc. Government Common Platform Ministry Cloud (Common Joboperation) Business Application Commercial Service Providing Business Application Environments Government Common Platform Commercial Service providing Infrastructures Government Common Platform Local Government Cloud (Local Government ASP) Infrastructure Ministry Cloud Local Government Cloud (Shared Service-Center) Ministry Cloud Local Government Cloud (Shared Service-Center) Figure 4.8-1 Categorization and example of clouds Generally, clouds will contribute to cost reduction because of its scale merit, application of virtualization technologies, and on-demand-based charging. In the case of IaaS, improvement of the hardware-use-efficiency by the application of virtualization technologies is expected to reduce cost, compared to the cases of on-premise systems where the server-configuration is determined to ensure the availability of individual application systems at the peak load — at an off-peak, plenty of resources are not utilized. In the case of PaaS, in addition to the effects by IaaS, cost-reduction is expected in system-operation / software-maintenance which can be eliminated by the employment of PaaS. In the case of SaaS, in addition to the effects mentioned above, cost-reduction is expected in the development / maintenance of business applications in the same way as expected in the employment of job-packages. Although additional cost is required due to a lot of factors in the deployment of cloud-based systems, reduced cost surpassing such additional cost is generally expected. On the other hand, for the individual systems using clouds, it is necessary to determine which type of service-delivery (including on-premise) is best. The essential factors to take into consideration are the following: cost, swiftness, data-linkage, service-menu, legal-constraints, and service-level. Note that, in cases where the best cloud service is not ready-to-use, it is necessary to figure-out alternative solutions through the assessment of those factors. Assessment policies of those factors are described as follows: 53 - Cost Generally, a public could is the lowest-cost option, followed by a community cloud, a private could, and an on-premise system— the highest: a public could is advantageous in scale-merit and expected to contribute to the total efficiency — the existing reasonable fee structures including a contract option, which, especially in case of using IaaS, allows users to contract a minimum configuration for their normal time with an option of adding resources in their peak time or busy seasons. In addition, even in temporal use, a public cloud is expected to contribute to cost-reduction because of its reasonable cost-structure: such features of a public cloud would be another advantage in cost-reduction. Note that because fee structures, which fundamentally determine cost, are determined and controlled by individual providers, in some cases they may be out of the scope of general assumptions: especially in cases of community clouds or private clouds constructed by the fund of an organization in charge of construction, in some cases, the fee structure does not match the actual expense paid by user-organizations because the fee structure is determined by non-economic reasons, and requires users to decide the use of the service from higher standpoints, taking into account the discrepancies between the user optimum solutions and the total-optimum solutions. Also note that users are required to make an assessment of the total cost because, in addition to the fee, extra expenses will be required for additional work such as re-structuring job-operation systems, the hybrid-type use or the multi-type use mentioned above, implementation / system-migration, and additional security measures. - Swiftness The on-demand-feature is one of the advantageous features generally expected for cloud services such as PaaS or IaaS — meaning that services become instantly available when demanded — in comparison with the cases of conventional systems where such convenience has to be realized on prefabricated menus of standardized features for infrastructures designed / implemented on order-made basis. Such swiftness is generally expected in PaaS or IaaS, whether based on a public cloud, a community cloud, or a private cloud. Note, though, that in the case of community clouds or private clouds, such swiftness might not be attainable due to the lead time and procedures required before the service becomes available, as long as those in the case of conventional on-premise systems, or additional time might be required for analyzing how the cloud will be used because of the lack of care for on-demand capability on the constructor side. In some cases because of the lack of integrity in service menus, extra time is required for devising appropriate application measures and, in extreme cases, a longer time than that in on-premise cases will be required where detailed consideration and negotiations between cloud-service users and providers, which are time-consuming when several organizations are involved. Also note that in the case of SaaS, because of the necessity of job-operation restructuring and consideration on a linkage mechanism to services, significant advantages / disadvantages are not 54 generally certain advantages are expected only when public-cloud based applications are employed in small job-operations or some particular job-operations. - Data-linkage In a community cloud such as the Government Shared Platform System, the data-linkage capability is significantly required: the data-linkage capability, considered as a function of PaaS, enables secured and low-cost implementation of high-level data linkage among the systems belonging to the community through common functions provided by the clouds. Such capability is expected to produce the most powerful effect in community clouds: the Government Shared Platform System, the following are expected: data linkage across the borders of ministries and agencies, system-linkage among the common business system for Ministries, and finally the system linkage between the individual ministry systems that share the common government systems. Although the data-linkage capability is also expected to produce effects in private clouds, the effect will be limited inside ministries. In public clouds or on-premise-based systems, where conventional data-linkage mechanisms are required, the capability will not produce any particular effects. - Service Menu Service menus should be selected so that the system modifications that would be required for transferring the existing systems to the systems using services or applications available on clouds will be minimized. As for IaaS, in most cases, the transformation will be feasible if the menu includes the OSs or DBMSs required by the existing systems, and as for PaaS, beyond OS or DBMS, system-operation management or processing might be modified. So, when comparing IaaS and PaaS from the point of system-transfer to cloud, IaaS is easier but the effects are smaller, and PaaS is harder but the effects are larger. On the other hand, in the case of implementing new systems on clouds, a feasibility study should start with SaaS and proceed to PaaS instead of IaaS. Procurement specifications should be created based on the standpoints of cloud-utilization because the utilization of cloud would be unattainable if the procurement specifications were created based on on-premise systems, lacking the standpoints of utilization of clouds. Note that, in case of hybrid-type or multi-type use, attentions should seriously be paid on interface design, emergency measures, and responsibility-divide including security issues, even if their employment is desired when a clear plan for the utilization exists and the effects are well expected. - Legal Constraints 55 Generally, a public cloud is most likely to be legally constrained, followed by a community cloud, a private cloud and an on-premise system where handling legal constraints are easy. Note that issues on legal constraints are dependent on providers. Refer for details to “4.8.2. Institutional Issues.” - Security Constraints Generally, a public cloud is the most severely constrained on the server / data storage locations for the security requirements on data archiving, followed by a community cloud and a private cloud of which situations are most close to those of on-premise systems. Also, because data and systems are concentrated, a public cloud is the most severely constrained, followed by a community cloud, a private cloud, and an on-premise system. Note that, however, large-scale clouds would have advantages with regard to security technologies or security-management operations because it could be easier to concentrate the expert skills and knowledge, or monetary resources in a case of a large-scale cloud. Also note that security constraints are highly dependent on individual providers. Refer to “4.8.10. Security Issues,” and “6.12. Security.” - Service Level Generally, in cloud services, because the computer systems or facilities, etc. owned by the providers systems and their situations of operations are not the easily visible from the user side, users are always concerned about the ambiguity in the responsibility-divide as well as the risk of service-down due to system faults. Therefore, the providers must prepare SLAs (Service Level Agreement) which are used for confirmation of mutual — users and providers — understandings with regard to the quality assurance standard for service functions, service coverage, or service quality. Because the service level is largely dependent on the provider, it can be assumed that no essential differences derived from the differences of the types of clouds (public, community, or private) exist in SLAs. Refer to “4.8.3 Selecting Providers or Services.” 4.8.2. Institutional Issues Institutional issues should be taken care of when clouds are used. In this sub-section, the details in relation to the following are described: “Location of Data,” “Relations to the Act on the Protection of Personal Information,” “the Guidelines for Safety Management of Medical Information Systems,” “the Guidelines for Information Disclosure of Safety and Reliability of ASP / SaaS,” “Issues on the Copyright Act,” “Relations to e-Document Act” and “Foreign Exchange and Foreign Trade Act” - Data locations One of the problems when using a cloud is that users are unable to know where the data is stored: 56 the data may be stored in a place belonging to a foreign county, or it may be hopping from one country to another, without staying in some place. Because data archiving is restricted legally by the laws of the country where the data physically exists, the laws and regulations of the countries where data is archived should be investigated. Note that some cloud-service providers do not disclose where data is stored. On the use of clouds, it is necessary to know where data is stored: if the data is stored in the United States, the users should pay attentions on a risk that the data could be seized legally for investigation, because, while the Electronic Communications Privacy Act (ECPA) prohibits the disclosure of communications to investigative authorities without a search warrant, the PATRIOT Act gives more power to the investigative authorities, and furthermore, users should know that, in some countries, other countries even the internet is censored. - Relations to the Act on Personal Information Protection Act In Japan, the Act of the Protection of Personal Information, Article 22 stipulates as follows: “When a business operator handling personal information entrusts an individual or a business operator with the handling of personal data in whole or in part, it shall exercise necessary and appropriate supervision over the trustee to ensure the security control of the entrusted personal data.” Article 23 stipulates that, except in some particular cases, business operators are not permitted to provide personal data to a third party without obtaining the prior consent of the person. Also the Article 16 stipulates that business operators are not permitted to handle personal information about a person without obtaining the prior consent of the person beyond the scope necessary for the achievement of the Purpose of Utilization specified at the time of obtainment. On the other hand, there are no legal constraints on the location of preserved personal information. As a conclusion, in Japan, preserving personal information on servers provided by the third party including foreign business operators is permitted insofar as the obligations such as supervision of subcontractors stipulated in the “Act on the Protection of Personal Information” are fulfilled. The EU directive prohibits moving personal information of inhabitants in EU to the third countries that do not assure sufficient protection. The following eight countries are certified to have sufficient protection (as of November 2010): Switzerland, Canada, Argentina, Bailiwick of Guernsey, the Isle of Man, Isle of Jersey, Faroe Island, and Israel. Registered business operators in the United States are admitted as eligible for handling personal information according to the safe harbor rules. Business operators in Japan, in some cases, would be judged as ineligible for handling personal information. - The Guidelines for Safety Management of Medical Information Systems, version 4.1 (Feburuary,2010) Using data centers in foreign countries for SaaS is practically — in order to follow the guidelines — difficult, because the guidelines require as follows: “The applications, platforms, servers, and 57 storages, etc. used for providing ASP / SaaS services must be placed at the locations within the jurisdiction of domestic laws and regulations in order to promptly submit the documents required by laws to the supervisory authorities.” - The Guidelines for Information Disclosure of Safety / Reliability of ASP / SaaS Since April 2008, the certification system based on the “Guidelines for Information Disclosure of Safety / Reliability of ASP / SaaS” has been effective as the scheme of information disclosure on safety / reliability of ASP / SaaS providers. Note that the certification systems would not effectively work unless the providers were prohibited to start business without the certification, and the certification system was acknowledged by both domestic and international providers. As a conclusion, the certificate could be used as a criterion for selecting providers, depending on to what extent the certification system is acknowledged. - Issues related to the Copyright Act Since the effectuation of the revised “Copyright Act” on January 2010, certain improvements have been made, such as the curtailment of rights of reproduction for information search services and the curtailment of rights of reproduction for information analysis. However, providers have been expressing concern that some services permitted and provided in other countries, could be judged illegal by domestic laws, such as holding copyrighted works in trust by storage service. As for analyzing copyrighted works on clouds and providing the added value, the providers are worried about the risk of being judged as committing an “indirect violation of providers’ rights.” Other services, such as recommendation services or thumbnails referencing multimedia copyright protected works, could be judged illegal. - Relations to the e-Document Act Since the effectuation in April 2005 of “Act on Utilization of Telecommunications Technology in Document Preservation, etc. Conducted by Private Business Operators, etc.” (Hereinafter referred to as “e-Document Act”), preserved electromagnetic records in addition to written documents have become legally acceptable in cases of about 250 laws. However, the e-Document Act does not care much about preserving such documents in the servers of third parties, because the main concern of the act is computerization of written documents. As a consequence, some particular laws or regulations still put limitations on data-preservation measures: “Ordinance Enforcement of the Installment Sale Act” stipulates that the books shall be preserved in principle sales-offices, and the “Ordinance for Enforcement of the Corporate Tax Act” stipulates that the books shall be preserved at the location of tax payment. Therefore, for the jobs related to such laws, use of publicly available cloud services is limited. 58 - Foreign Exchange and Foreign Trade Act The “Foreign Exchange and Foreign Trade Act” (hereinafter referred to as “Foreign Exchange Act”) stipulates that in order not to undermine the maintenance of international peace and security, a resident who intends to provide specific technology in the specified region, or to specific non-residents / corporations, shall obtain a permission from the Minister of Economy, Trade and Industry, and in Article 25, Paragraph 3, that as for the “electronic transactions designed to provide the specified technologies to specified countries,” the permission shall be obtained. Therefore, as for transmission of information from a location inside Japan to a server of a third party located in a foreign country, transmission to a server located in a foreign country owned by the sender of information with an intention of providing information to users in foreign countries, or transmission of the outputs of computational processing by the server resources located inside Japan, the sender, in some cases, will be required to obtain such a permission. The specified technology mentioned above refers to a technology related to weapons of mass-destruction such as nuclear weapons or conventional weapons. Note that many technologies used for non-military purposes, such as cryptographic technologies, are included in the restricted technologies, and require careful handling. 4.8.3. Selecting Providers and Services For utilizing clouds, providers of services should be selected through careful assessment. Points of the assessment are described below for each of the following factors: “Server / Data locations,” “Management of Multi-Tenants,” “Information Security Measures,” “Business Sustainability,” “Services,” “SLA,” “Service Continuity,” “Service Cost,” “Continuity of System Environment in case of Changing Providers,” and “Evidence of Data-erasing on Service Termination.” - Server / Data Location Note that while cloud-service providers who use servers and storages located at several distributed sites in an integrated way for ensuring the availability of services do not always disclose the site information, in recent examples, providers on the request of users — especially corporate users — disclose the geographical information of servers preserving the data of the user concern. Make the selection of providers taking such locations issues into account. - Management of Multi-Tenants Generally, except for a so-called “private cloud,” more than one corporation and business entity share the same environment — it is called multi-tenant type of cloud usage. In such multi-tenant environment, additional measures for security and availability will be required to enable such shared 59 use. In some cases where as high confidentiality as that of a private cloud is required, an IPsec VPN based environment is employed. Therefore, attentions should be paid to what security services are provided by what providers. - Information Security Measures Attentions should be paid to providers’ actions or attitudes to the ISM system (JIS Q27001: 2006, ISO / IEC 27001: 2005) and the privacy-mark system of the Ministry of Economy, Trade and Industry, what providers have a system to accept “audit of contractors as a part of internal control,” or instead to provide reports compatible with “SAS70 (Statement on Auditing Standards No. 70,” or “Audit Committee Report No.18 ‘Assessment of Control Risk of Entrusted business’ — Report 18 Audit — of “The Japanese Institute of Certified Public Accountants.” Note that in addition Type II of SAS70 is an important assessment reference because the compliance of providers’ job-operations to the laws and regulations is assessed. - Business Sustainability Because, when using clouds, users have no other choices than leaving their business infrastructures to providers’ hands, attentions should be paid to the healthiness of management foundations of providers. Note that, in some cases where providers are based in foreign countries, of which the information of business is difficult to obtain, special cares should be taken such as requesting providers for confirmations before making the decision to use their services. - Satisfiability of Functions Note that, because specifications of the provided functions are out of the reach of users — users just use those functions— a FIT / GAP analysis and preparation of counter measures to “GAPs” is necessary before selecting services, to the same extent as required in the case of employing packaged products. - Satisfiability of SLA with the Requirement Providers rarely agree on user specific SLAs, because providers are doing business with a wide range of users. Furthermore, even SLAs prepared by major providers are only on the availability of services, not including performance, back-up, recovery from service downs, or level of security. Note that it is necessary to understand the service level of the services to be provided, make assessments on the satisfiability, and request confirmations to the provider as much as possible if the satisfiability is not clear, before finalizing a contract. Also note that it is necessary to make assessments on a proposed service level according to 60 system needs and estimations on the utilization, and pay attention to the trade-offs — higher costs for higher functions — between service levels and costs not easily accepting the general tendency that services with higher service level obtain higher evaluations. - Service Continuity Note the necessity of requesting confirmations from the providers on the continuity of services because services are prone to be updated for improvement by providers. Request the provider to announce version-ups well in advance and to assure that the same services are available after the version-ups. - Service Cost In many cases of cloud services charging system is based on the quantity of service provided. However, continuously note the possibility of the charging system modification due to the economic conditions or the situations in competition, and at the beginning of service, prepare for such modifications of the charging system. Also note the necessity of cost evaluation — focusing on whether or not using cloud service will contribute to cost reduction — from the standpoint of total life-cycle cost. - Continuity of System Environments in case of Changing Providers Note the necessity of the study in advance on whether the development-environment, the development tools, or the data in use are transferable to another provider’s environment: especially, in the case of SaaS, confirmations are necessary on whether the data in use is downloadable in a ready-to use manner the data structure preserved. - Evidence of Data-erasing on Service Termination At the termination of service, the data in use must be saved and eliminated from the system completely — to the extent that recovery is impossible — destroyed, not just erased. Note the necessity of requiring a report certifying the completion of the elimination of data, especially for highly classified data. 4.8.4 Points of Procurement and Contract In this sub-section, several points that need attentions in procurement or contract of cloud services are described from the following standpoints: “Click-wrap Contract,” “Application of Separation-of-Procurement Policy (Procurement Standards),” “Avoidance of Provider-lock-in,” and “Preservation of Interoperability.” 61 - Click-wrap Contract (shrink-wrap contract) Note that in some cases, subscription of cloud services is contracted by the click-wrap style— similar to the shrink-wrap contract in the case of packaged software products — where the click on the agreement document is deemed as the consent to the subscription. Although the validity of such contracts is not clear in Japan — in the U. S. there is a judicial precedence supporting the validity of a shrink-wrap contract, but none as for a click-wrap contract — , much attention should be put on contracting procedures in the case of click-wrap. - Application of Separation-of-Procurement Policy (Procurement Standard) The policy recommends separation of procurement for applications or system infrastructures. However, in the case of cloud services, the situation is different in the following ways: in case of SaaS, because only services are procured, there are no procured objects that the policy may care about; in the case of developing applications on PaaS, because details of the development depend on providers, it is difficult to obtain estimations on applications before the selection of provider; and in the case of making assessments on IaaS as a development base, because applications are to be developed on the IaaS development base — estimations on applications is inseparable from that of IaaS — decisions of use of IaaS should be done before procuring applications. Furthermore, there exists a case where more than one provider is involved that provides SaaS services on IaaS or PaaS. In such a case, it is essential to make the responsibility boundaries of providers clear between IaaS / PaaS and SaaS. - Avoidance of Provider-lock-in In the government procurement system, a service is procured on a fixed term basis, and on the expiration of the term, the contract is renewed through another competitive bidding for the purpose of giving a chance of entry to all providers: it means that the service may be transferred to another service provider. Therefore, it is critical to ensure a smooth transfer of service and data, especially in case of PaaS, because the applications developed in the former environment may not work well in the next environment, and in case of SaaS the smooth transfer of data is essential. - Preserving Interoperability In cases where the interoperability with other systems is required, a to-full-extent investigation of the service on its interoperability is indispensable. Also note that an extensive investigation on the possible problems on the service level or security level is necessary. 62 4.9. Standpoints of Cloud Integration This section describes the essential points from the view of the cloud integrator— a person in charge of the integration on the procurer side or an integrator on the provider side. The two different standpoints are useful to each other and share the same objective of providing cloud services in cloud procurement / integration. Because most of the clouds to be implemented in the ministries or agencies can be classified in the category of private cloud, the descriptions in this section are based on the assumption that the cloud is a private cloud. Moreover, the descriptions will help , procurers or integrators on the provider sides when they prepare for the cases where the cloud is to be shared by more than one ministry or agency — community cloud, or to be composed of multiple clouds — hybrid cloud. 4.9.1. Components of Cloud Clouds consist of a variety of components, of which types and product-implementations are dependent on the service type of the clouds — SaaS, PaaS, and IaaS. In the generally available cloud, a “resource pool” preserves IT resources such as hardware and software available to users on an on demand-basis: those resources are provided to users as information services on a network through the “network infrastructure” and “operation / management infrastructure.” Note that with regard to SaaS and PaaS, detailed element-by-element consideration or design are required.— for example, what types of software resources such as application-software provided as a job-service, operational environment for applications, or database, should be prepared, and how many of them should be implemented and stored in the resource pool. - IT Resource Servers and storages are the basic components of a cloud. In clouds, through the application of virtual technologies, physical components such as servers and storages are generally virtualized: those virtual servers execute information processing jobs in collaboration with the virtual storages composed of physical devices such as internal disk-drives embedded in physical servers or independent disk-drives. - Network Infrastructure The major function of network infrastructures is the provision of LAN functions inside the cloud system and connection-interfaces to external networks. NAS / SAN working for the high-speed and large-capacity data-transmission between servers and storages is one of the major components of network infrastructures. Through the application of virtualization technologies to networks, a virtualized network such as VLAN is available. Note that, in some cases, specialized network 63 functions, such as load-balancing or SSL acceleration, are treated as an IT resource and stored in a resource-pool. - Operation-Management Infrastructure Operation-management infrastructures provide cloud-specific monitor / control functions similar to the monitor / control functions common to conventional systems. In a cloud, the application of virtualization or automation technologies has made the execution / management functions for dynamic provisioning and deployment indispensable. Except for those, the operation-management infrastructures work for user ID / security management, provide user-interfaces such as service-menus or management-portals, and manage SLA. The Figure 4.9-1 shows an example of how the conventional system shown in the Figure 4.2-1 is constructed through the application of cloud-resources, where some of conventional components have been replaced by cloud-services. In the figure, the servers inside the round rectangles are realized by the application of cloud resources. Note that a group of servers distributed in different segments are realized through the application of cloud services. The purpose of the figure is to illustrate how the components are connected by networks, so the details of network infrastructure or operation-management are not shown. Figure 4.9-1 Example of Cloud-Resource Application 64 4.9.2. Service Menu Service menus, in the case of clouds, list the standard services prepared by providers for users, aiming for prompt and stable provision of services: in some cases, the service menu includes options for a specific service or options applicable for the entire menu. Basically, the service should desirably consist of a limited number of standardized functions — even though modifiable to some extent by options — and what the service provides to users should be clearly described in the menu: providing services in such a way as described above would lead to the uniformity of service — similar kind of services provides similar level of functions — and contribute to the efficient use of resources or improvement of service quality. It is worth adding that automation of a part or the entire service-providing processes would contribute to a speed-up of service delivery. Service prices, are sometimes determined case by case, using the menus and options: such flexibility of pricing in accordance with the user situations is expected to guide users to some specifically patterned usage of services, or to promote reasonable sharing of resources. Note that, although requiring the services not listed on service menus is possible, it could not always lead to the total-optimization, or could be even disadvantageous from the point of investment recovery, because, in some cases, due to additional development or procurement, extra time would be required for defining specifications, making price-estimations, or finalizing the SLA (described in the following sub-section), and in addition the start of service would be delayed. 4.9.3. SLA SLA, in the case of clouds, is prepared by providers, proposing the agreement on the quality of the standardized services for the purpose of prompt service delivery — in some cases, the SLA can be selected by users through making selections of menus or options mentioned in the previous sub-section. A cloud has no unique business factors for determining requirements of an SLA, or the technological / operational factors involving the selection of an SLA, except for that, in comparison with cases of conventional systems individually designed in accordance with a predefined SLA, cloud services are designed by providers on some assumed level of service: it is such a large difference that the consensus in case of cloud is built through such a process that the user selects the services from the service menu including options prepared by the provider. Note that, although it is possible that some cases require services that enable SLA requirements not listed on the menu It might not always lead to total-optimization, and could be even disadvantageous from the point of investment recovery, because, in some cases, due to additional development or procurement, extra time would be required for defining specifications, making price-estimations, and furthermore the start of service would be delayed. 65 4.9.4. Use Case and Defining Requirements Requirements for cloud services are defined by use-cases where defined players involved in the integration of systems based on cloud services, or the use of services act according to their role. Players and their roles are defined as follows: - The provider: preparing environments for SaaS, PaaS, or IaaS Required to care about the security of services and resources; maintainability, completeness, and reliability of resources on the cloud; effective handling of resources on the cloud; and scalability in data size, number of tasks, and number of users. - The consumer: implementing services on the service-environment provided by the provider Required to care about the short-lead-time to start-of-service, and pay-as-you-go charging policy. - The end-user: using customer services implemented on the cloud Required to care about the types and functions of services, the completeness of data and requests on the cloud. - The enabler (vendor): providing services or goods to providers and users - The operator: operating the cloud environment 4.9.5. Points to Take Care Cloud Implementation The points to take care cloud implementation are listed below: ・ It is required to design systems and operations by selecting the optimum virtualization mechanism and suitable management infrastructures, depending on the scheme of service-providing such as SaaS, PaaS, or IaaS. ・ It is required to prepare the service menus acceptable and suitable to the assumed users, and construct the operation and management infrastructure (including management portal, monitoring / statistics system) to realize them. ・ It is required to keep watching the utilization situation of each tenant. ・ It is required to implement a system that can scale-in or scale-out dependent on demand. ・ It is required to take care of and eliminate a point-of-failure. ・ It is recommended to, for functions such as monitoring, back-up, job-execution, logging, or authentication, employ models sharable in the entire cloud system, whenever possible. ・ It is required to, in the case of a hybrid cloud composed through the combination of several cloud environments, consider the implementation of functions for authentication / user-management / billing-management, etc. ・ It is necessary to present the responsibility-divides and SLAs to the users. 66 ・ It is required to set-up suitable and acceptable SLAs for users, and implement monitoring / controlling systems for satisfying them. ・ It is necessary to, for the successful transfer of cloud-service environments, which is expected in future, prepare clearly defined validation criteria of transfer-completion. ・ It is required to pay attention to the necessity of checking security situations of the VM images or the environment to be provided. ・ It is necessary to, in case of resource-pool sharing by more than one user, properly execute performance designs / expansion plans / security designs. ・ Note that, in some cases, attentions must be paid on external constraints — domestic or foreign legal constraints such as the EU directive for data-protection or the U. S. Patriot Act, geographical situations including earthquakes or weather conditions, power cost and capacity, power-grid margin rate and reliability, and network-bandwidth. 67 4.10. Security Issues Information security entails not only the security capability of information systems, but also ensuring the “safety and reliability” of the social system and businesses: the objective of information security is ensuring confidentiality, integrity, and availability of information through the construction of ISMS (Information Security Management System). Information systems are facing not only external “threats” such as computer virus, unauthorized intrusions, or denial of service attacks, but internal “threats” such as lack of security capability, and inappropriate software operation / management. “Vulnerability” refers to the possibility of problems raised by those threats: completely eliminating vulnerability from an information system is impossible. Threats exploit vulnerability, which is impossible to eliminate, raising “incidents” such as system troubles. Such troubles give unfavorable “influence” to information systems, social systems, and businesses. That is the chain reaction caused by insufficient security protection. Cares for security-protection measures are necessary from the following three standpoints: ・ Technical Measures for Security Protection Embed security protection capabilities, including those in the individual technology domains and security factors in non-functional elements, in the systems to be implemented. ・ Organizational Measures Prepare the organizational structure for security protection. ・ Operational Measures For protecting security, proper operations of information systems through utilizing the organizational structure mentioned above are required: the points for the protection of security are those described with regards to the common procurement of services, or those described with regard to the categories of procurement of service. Also note the following two security measures for avoiding security chain-reactions. ・ Security measures eliminating threats and vulnerability to avoid security incidents, ・ Security measures to prevent incidents from leading to damages, even if the occurrence of an incident could not be prevented. Security could be enhanced as completely as possible if cost and operability is not taken into consideration. However, to what extent the security is enhanced should be determined by the balance of cost and operability in the employment of measures and also the following two issues: ・ The probability of the chain reaction — “incident” resulted from “vulnerability” exploited by a “threat.” ・ The severity of “influence” resulted from an “incident.” 68 4.10.1. Recent Changes in Threats to Information Security and Problems It is necessary to pay attention to changes as shown below in threats to information security and the problems, which can be seen in the trends in information systems and communication networks in recent several years: ・ More diversified, sophisticated, and complex attacks to information systems and communication networks Attacks to information systems and communication networks that had, although they had already existed in the early days of the internet, have recently changed in their mechanisms and the sophistication levels. In comparison with past cyber attacks such as the defacing of the web-pages of governments or large corporations for the purpose of a demonstration of technical excellence, or a publication of political propagandas, as well as an intrusion into corporate internal networks just for pleasure — the attack mechanisms are comparatively simple the attacks in these days aim to steal money using information obtained by deception and are executed in more coordinated ways. The following are descriptions of such recent attacks (also refer to the Figure 4.10-1): Attacks raising the attack-success probability by flexibly up-dating multi-staged attack means according to the target. Attacks using virus-subspecies for degrading virus-detection accuracy of protection software using pattern matching. Zero-day attacks exploiting unknown vulnerabilities to others, which are difficult to detect or difficult to analyze due to the complexity of influence, or selective attacks picking off specific targets. Although the actions against security breaches have been executed simultaneously among organizations inside or outside by sharing damage information, as for the attacks described above, because of the difficulties of disclosing and sharing damage information, it becomes difficult to apply effective measures by a single method. 69 2000 2004~ 2006~ Coordination (Botnet) Unauthorized Intrusion / Defacing 2009~ Multi-staged Attack (based on Botnet) Exploiting Authorized Services as Cyberattack Base Exploiting Authorized Sites/Services Explosion of Virus Sub-species Sequential Malware (Multi-staged Attack) Using Zero-Day Vulnerability Virus Production Using Tools Targeting Information Systems Single-attack to Single-vulnerability Victimizing PCs and Defacing Homepages Coordination among Attackers Single Separated Attacker Destruction of PC, Defacing of HP Building Attack-Bases Tactical Attack Multi-Intension Attack(Information Deception) Changes in Aspects of Damages (Impact on Job-Operations) Object: PC or Server Information Deception, etc. Impact on e-Market Business or Settlement Business, etc. Deception of Account Collection Inf ormation, etc: Impact on Supply-chain Risk Management Target: Information Systems (of Organizations or Businesses) Countermeasures using Security Products (Available on Market) Design Methodology based on Security Products ? Unchanged Design Methodology Age of Less-Visible Full Aspect and Points of Threat Inf ormation Protection by Established Inf ormation-Operation Structure (Inf ormation Collaboration) Design Policy: Avoiding deep-level intrusions even allowing shallow-level ones Embedding Protection Mechanisms in System Designs or Network Topology Designs Figure 4.10-1: Comparison of Cyber Attacks; Traditional and Recent ・ Growing Ambiguity of Influence on Organizations and Responsibility Divides These days, when information systems take critical roles as a business infrastructure participating in various aspects in business processes, and the entities involved in information systems are widely distributed having different and complicated relations to each other, it is not easy to know who should take the responsibility on the occurrences of troubles, or what frameworks should be employed to take actions. Therefore, there exists an increasing necessity for a new approach for resolving problems. ・ Diversified meaning of security These days, in a similar way that the meaning of information systems to the society has been beyond a simple technology, the information-security field has been related to various social systems or business processes. In addition, what the information process means is understood differently depending on the standpoints of the involved social systems or business processes: it means that the diversification of the meaning of information security is going-on along with the diversification of understanding of security issues. In addition, the position of information security has been diversified as well as it is different depending on the responsibilities and purposes of the involved job-positions, 70 (Refer to the Figure 4.10-2). Therefore, in discussing information security, it is necessary to sort-out the acceptance-and-delivery processes of information, clarify the standpoints of the discussion, and make a consensus. Judgment of Organizational Measures (Assessment of Influence on Organizational Operations) Internet Security Communication-Carrier (ISP), Service Investigations of Public Security Crime-Prevention, Criminal Investigations Inf ormation Integrity Communication Integrity National Security Protection of Critical Infrastructures Legal Compliance Academic Research Audit Business Organizational Technical Challenge Challenge Challenge Protection of Intellectual Property of Private Businesses, etc. Safety of Manufacturing Line and Cost What are your organizational objectives? Efficiency What is your role? What influence is predicted to what extent? Security Rating Who attacks and for what? Management of System Design (including security functions) Intelligence Standards, Guidelines, etc. Economy Compliance and Information-management Business Continuity Management Judgment Products and Solutions Security Business Incidence Report (CSIRT) Figure 4.10-2: Related Fields to Information Security Much attentions has been paid to CND (Computer Network Defense) fields, as the changes in threats and problems about information security have been widely noticed. 71 4.10.2. Treatment of Security in Separation Procurement of Services It is necessary, in procurement of services, to make a security assessment and determine security measures for each procurement-of-service category, where the points of assessment of security are as follows: ・ Planning Phase Predict the severity of risks through making assessments of threats, vulnerability, and the severity of influences, and then determine the level of the countermeasures required for complying with the results of the assessments.. ・ Requirement Definition Phase Define the requirements for security corresponding to the severity of risks and the level of the required counter-measures determined in the Planning Phase. ・ Development Phase Break-down of the requirements for security defined in the Requirement Definition Phase and define the requirements for security in operation / maintenance. ・ Operation / Management Phase Execute the security counter-measures defined in the Development Phase, and also, pay attention to new threats, new vulnerability, and changes in influence across the ages. 4.10.3. Outline of Measures for Ensuring Information Security in Planning / Design Phase (SBD) For implementing security measures, it is desirable to note that actions in the up-stream of projects have influence the down-stream, and take actions for ensuring security in the earlier stages of a project so that integrity of security policies and traceability is ensured, and that re-run of work from earlier processes is avoided in every stage of procurement of service. If security requirements are not explicitly specified in procurement specifications, disadvantages both to the procurer and to the provider could be produced. Examples are as follows: (1) Possibility of financial damages due to re-run of work or extra procurement as a result of a lack of consensus between procurers and providers in the stages from procurement to operation / maintenance caused by ambiguity or unfairness in procurement specifications of information systems. (2) Possibility of disadvantages due to improper — excessive or dissatisfying — security measures implemented as a result of a lack of clear requirements for proper security. For resolving such problems, in all the stages, even in the planning phase, flawless implementation of proper security measures is ensured through reducing the disadvantages on both of procurers and providers. For such purposes, in addition to this Technical Reference Model, on the request of the Information Security Policy Conference, the National Information Security Center published, at the end of FY 2010, the “Manual for Defining Requirements of Information Security in the Government Organizations Related to Information Systems” as a result of discussions in the “Discussion Group for 72 Measures for Ensuring Information Security in Planning / Design Phase (SBD)” (hereinafter referred to as “SBD Discussion Group”) The manual, covering procurement jobs for information systems including “up-dating” and “new development,” is expected to be used especially by the administrative job-operators in charge of the procurement of information systems to define security requirements on their own responsibilities and write them down in procurement specifications. Also, the Manual is expected to be used by providers of information systems to obtain information (including information on the process of building the Manual) supporting their understanding on security requirements specified in procurement specifications. It is expected that security measures matching the necessities are ensured by preferentially and clearly writing essential and effective requirements in procurement specifications paying attention to information-protection measures in information systems and measures against security breaches. 4.10.4. Outline of Risk Factor Reference Model (RM) 4.10.4.1. Fields of Security Covered by Risk Factor Reference Model (RM) Security measures of information systems are categorized into IA and CND as follows (refer for the Figure 4.10-3): IA (Information Assurance): The actions to be taken to manage the risks in data use / process / preservation / transmission or the risks of systems / processes using data. This document specifically uses the term (information assurance) as the protection measures against leakage or falsification of information through managing information according to formalized guidelines or standards. CND (Computer Network Defense): The actions to be taken for protection / monitoring / analysis / detection of misconducts, and actions for responding to them (response). This document specifically uses the term (computer network defense) as the actions to be taken against cyber-attacks from the outside, for protecting communication networks and information systems, to keep the systems operating and to prevent information theft. As for IA, since the Standards for Information Security Measures for the Central Government Computer Systems were formalized, the protection measures, including the internal control system as a major protection measure, have been systematically deployed. As well as the deployment of the internal control system, the system requires, in the operation phase, the execution of PDCA (Plan-DO-Check-Act) cycle and the management of information of a level higher than predetermined. As for CND, security protection measures have been deployed on a particular-system basis, such as the implementation of firewalls, employment of secure communication-protocols, or the employment of virus-detection mechanisms, partly because the departments in charge of security have put their power entirely on the task of preventing the individual cyber-attacks which are constantly being changed and sophisticated. In these days, when the threats and problems of information security have changed, more 73 systematic approaches are required for CND. For such purpose, it is essential that the early stages of the procurement of information systems such as planning or design contain work for embedding security measures. CND (Cyber-Attack Protection) IA (Information Assurance) Target Field of Cyber-Attacks Target Field of Information Assurance Type 3: Information Management Functions Type 4: Factors in management, etc. (human, facility, rules, etc.) Type 1: Attack Issues Protection from state-of-the-art attacks What should be protected: Type 2: Information theft issues “Information leakage by cyber-attack (theft)” Organizational Capability Business Trustworthiness Threats and risks emerge in the organization Threats and risks come from outside of organizations CND (Cyber-attack defense) and IA (Information assurance) have different objectives (different operations) Figure 4.10-3: Field Covered by RM In order to figure out effective measure in the cyber-attack field (CND) as described above, it is essential to apply the “Design of Counter-measures Based on the Correct Knowledge on the Present Attacks” based on the Risk Factor Reference Model (RM). 4.10.4.2. Philosophy of Risk Factor Reference Model (RM) The “Risk Factor Reference Model (RM)” is an approach that enables judgment, based on the shared knowledge of present threats and issues of influence to organizations in the sophisticated CND fields, of the necessity of measures in system design, and the application of the effectiveness-proven design of counter-measures. The conventional “measures by management,” which generally requires the application of uniform measures in design, have problems in the confirmation of the necessity and effectiveness of the measures, and in addition is prone to lead to an escalation of cost for measures. On the other hand, the RM is an approach that makes the necessity and effectiveness of measures clear, and to intensively apply measures by system design to the essential parts found through the impact analysis. 74 Furthermore, since the emergence of these new-types of cyber-attacks, the measures based on the conventional design approach of installation of security-solution products have become less effective without the aid of other means. In order to solve such problems, the RM has employed a new design approach so that the necessity and effectiveness of measures is judged based on precise knowledge of the aspect of actual attacks and the impacts on job-operations (refer to the Figure 4.10-4). The approach of analysis based on the RM is as follows: (1) Analyze and categorize the actual cyber-threats in detail, define “attack patterns” based on the analysis and categorization, and predict specific attack scenarios. (2) Formulate the information system design models for each type or characteristic of systems. (3) Attack the model system on a desktop using the attack scenarios and trace the attack (simulated desktop-attack). Then, analyze impacts of the attack and the effectiveness of the designed measures. (4) Document the results of traced attacks (simulated desktop attacks) as “System-Design Measures.” The results of analysis based on the RM is assumed to be used by both the procurer and the provider of information systems for sharing the consciousness of problems and specifying the necessary requirements of procurements based on the “System-Design Measures.” Analysis of Object Systems of Protection Analysis of Threats of Attack (2) Categorization of System/design Model (1) Analysis of Attack Patterns and Formulation of Attack Scenario Impact / Risk Analysis (3) Attack Trace (Simulated Desktop Attack) a. Intranet Model b. Closed Area Model Classification of Severe Threat models and Analysis of Attack Specifications Analysis of Inf luence of Attack and Ef f ectiveness of Measures Taking Jobmission Impact into Consideration c. iDC Model d. SaaS Model Classification of object Systems of Protection into the Four Categories shown above Analysis of Measures (4) Formulate System-Design Measures from Trace of Simulated Attack Figure 4.10-4: Analytic Approach Based on the RM The basic models of cyber-attacks assumed in the RM, used as the basis of counter-measure design concepts, are the following: Analysis of various modeled patterns of attack has revealed that any attack consists of more than one stage, the first to the third, and the success or failure of the third attack is, almost commonly to 75 any pattern, deeply involved in the mission-impacts. Therefore, the RM has, taking into account the limited effect of measures in the first stage, included in to the scope of the conventional measures, proposed the measures by design-management, focusing on the avoidance of the attacks in the third stage. The RM has, in addition to the conventional measures, categorized such measures as measures by design for “Avoidance of the Final Impact on the Mission of the Organization.” For avoiding the organizational influence (mission impact) caused by the current cyber-attacks, re-definition of threats and re-analysis of design philosophy and organization-operation policy is necessary. Basic Model of Tactical Attack Philosophy of Measures by Design ★第2、3段階の阻止により組織インパ ★Avoiding the mission-impact by blocking クトを回避 the second / third attack Preliminary Stage: Object / Motivation / Attack Base The ultimate impact on organizations (systems) is avoidable by preventing the invasion of main attack units and attackobjectives (information theft) even for attack tactics on which vulnerability-patch or AV pattern measures is not effective. Formulation of Attack Plan First Stage: Initial Invasion to System (by various means) (1) Initial Attack by Malware attached to Selective-attack e-Mail (2) DL Server Inducement by Web Attack (3) Initial Media-Mediated Malware etc. Abuse of vulnerability Blocking the communication with DL servers executed in the second / third stage. ★Blocking the attainment of the final attack objective, and then destroying the threats Dropping Initial Attack Unit Avoid the ultimate damage by blocking the attacks in the second / third stage, and then clean viruses and execute anti-vulnerability measures. Second Stage: Induction to DL Servers and Drop of Attack Malware Dropping Main Attack Unit Use of attackbases Identification and Trace of Attack Pattern Third Stage: Information Theft by Deception and Handing-over to Attack Commander ★Figuring-out of the Entire Tactical Attack ★戦術的攻撃バターンの全体像の把握 Pattern and Watching for the Appearance of とパターン監視 Tactical Patterns Execution of Attack on Final Destination Extract the characteristics of the attacks, which will be the keys to measures by design, by tracing attack patterns (behaviors) The Ultimate Threat to Organizations Figure 4.10-5 Common Basic Models of Cyber-attack assumed in the RM 76 4.11. Policies for Employment of Green-IT Green-IT refers to a philosophy of applying information technologies giving considerations to the environment. In Japan, on the framework of the Basic Act for the Promotion of a Recycling-Oriented Society, enacted in January 2001, the laws and regulations regarding the recycling of resources and improvement of energy-consumption efficiency have been established or revised. The government procurement of information systems, as well as contributing to the realization of environmental-load reduction through proactive actions, which should be a model to the society, is expected from now on to contribute to the reduction of power consumption through consolidation of equipment, employment of low-power-consumption equipment and energy-saving technologies, and the optimization of cooling and power-supply. The Philosophy of Green IT generally consists of the “Consideration of Environment in IT” (Green of IT) and “Consideration of Environment by IT” (Green by IT). The former is about the reduction of environmental load imposed by the equipment installed for information systems: it is a subject to be discussed mainly in the procurement of goods. The latter is about the reduction, by the proactive use of information systems, of environmental load imposed by the existing job-operations, social activities, and the social systems: it is a subject to be discussed mainly in the planning processes of the government procurement of information systems. 4.11.1. Application of Green IT to Procurement of Goods As for the application of Green IT to procurement of goods, the “Consideration of environment in IT” is the main subject. Especially, as for the activities covering the entire purchase and procurement, the “Act on Promotion of Procurement of Eco-Friendly Goods and Services by the State and Other Entities (Act No. 100, May 31, 2000)” and the “Basic Policy for the Promotion of Procurement of Eco-Friendly Goods (Revision to Cabinet Approval on February 5, 2010)” (hereinafter referred to as “Act on Promoting Green Purchasing”) have been in effect. According to those acts, in the procurement of specified goods for procurement by the government, independent administrative agencies, etc., local governments, and local independent administrative agencies, the compliance to the compatibility conditions stipulated in the Act of Promoting Green Purchasing is required as procurement conditions. Relations of the specified goods for procurement to the technology domains in this Technical Reference Model are shown below; the conditions stipulated in the Act on Promoting Green Purchasing are described in Ch.5 as the basic items of non-functional requirements for each technical domain, and, if there exists standardized green IT technologies in a technology domain other than those specified in the Act on Promoting Green Purchasing, they are described in Ch.5 as basic or desirable features. 77 Specified Goods for Procurement in the Act on Promoting Green Purchasing, FY 2009 Technology Domain, Technical Reference Model for the Government Procurement of Information Systems (TRM), FY 2010 Computers 5.6.3. Server hardware 5.8.2. Personal Computer Magnetic Disk Drive 5.7.1. Disk Storage Printer 5.8.6. Printer Shared in Office Digital Printer 5.8.6.2. Multi-Functional Printer Copy Machine(Multi-Functional Printer) 5.8.6.2. Multi-Functional Printer Display 5.8.2. Personal Computer 4.11.2. Application of Green IT to Procurement of Service By the “Consideration of Environment in IT (Green in IT),” the essentially a concept in the procurement of goods, although the short-term effects on reduction of environmental load is expected, the long-term and significant effects on the reduction of environmental load is difficult. On the other hand, the idea of “Consideration of Environment by IT (Green by IT),” is expected to contribute to significant reduction of environmental load necessary for the realization a of low-environmental-load society, because it aims for the reduction of environmental load through the reformation of the existing job-operations, social activities and social systems. Therefore, much more effort should be put into the field. More specifically, reduction of the consumption of paper (reduction of environmental load by the reduction of paper) required in the existing job-operations through the utilization of BI, etc, reduction of geographical transportation of workers (reduction of environmental load by the reduction of automobile-run) through the utilization of electronic conferences will be the realization-examples of the “Consideration of Environment by IT.” Also, the use of cloud services has an advantage for the reduction of IT equipment on the side of the “Consideration of Environment in IT,” and, at the same time, an advantage in the reduction of the procurement or operation-load on side of “Consideration of Environment by IT.” In addition, as for the use of data centers, the consideration of both of the energy efficiency of IT equipment and the energy efficiency of incidental facilities such as cooling systems is required in procurement. 78 4.12. Notes on Employment of IPv6 The reservoir of IPv4 global addresses necessary for the Internet connection has dried-up , and the allocation of new addresses has been impossible (newly allocated global address will be IPv6). Therefore, addition of servers with IPv4 global addresses, or new construction of DMZ with IPv4 is difficult in normal situations. In addition, because IPv6 has no compatibility with IPv4, IPv6-based networks or servers are unable to communicate with those based on IPv4 by simple means: special schemes are required, such as co-existence or parallel use of IPv6-based environments with the existing IPv4-based environments. As for the equipment, such as networks, servers, or PCs connecting to the internet, in order to properly achieve such co-existence or parallel use, preparatory consideration must be made for the details of operation / management / monitoring / maintenance and security measures as well as those for design or procurement. Refer to “Guidelines for IPv6 Support in e-Government Systems” http://www.soumu.go.jp/menu_news/s-news/2007/pdf/070402_5_bt1.pdf 79 5. Descriptions of Technological Domain This chapter describes the Technology Domains from the standpoint of procurers, showing representational examples of requirements to specify in procurement specifications. Note that, on the application to the actual procurement specifications, the words and phrases shown in the examples have to be modified according to the actual situations, as follows: The words or phrases parenthesized in “{},” curly brackets, are variable elements dependent on the systems to be procured. Replace them with the appropriate words in accordance with the requirements of the actual information systems. The words or phrases parenthesized in “[],” square brackets, are exemplifications for clearer understanding. Replace them with appropriate information in accordance with the requirements of the actual information systems. Many of those will refer to product-names or trademarks, etc. They must be replaced with more than one product-name or trademark followed by “etc,” for clearly showing that they are exemplifications, in order to avoid specifying particular products, unless there are no proper reasons for explicitly referring exactly to particular products in cases where the assets procured in the past are intentionally used. If such proper reasons exist, describe in detail the information identifying the particular products. In the tables in the following sections, which list requirements, the requirement items labeled as “Basic” are fundamental requirements — normally available products will satisfy these requirements. In the evaluation-by-total-score based procurement, it is allowable to use them as the indispensable requirement technical points items. On the other hand, the label “Additional” indicates that the requirement item is not always necessary, or not always satisfied by normally available products. As for the evaluation-by-total-score based procurement, those items should be used as additional technical point items, unless they are indispensable to the system to be procured. The label “Selective” indicates that more than one of the items listed in the description is required to be satisfied. Note that, because those labels used in the sample requirement tables are given to the assumed ordinary requirement items in the technology domain, it is necessary, when they are referenced for creating actual procurement specifications, to consider which requirement items should be labeled as “basic” or “additional.” Pay attentions on how the items in the examples are labeled as “basic,” “additional,” or “selective. Also, note that, because some of the requirement items labeled as “basic” might be over-specifications for small-scale systems, it is necessary to select the requirement items carefully in the design or implementation phase. In addition, it is necessary to make adjustments so that unnecessary items for the actual information system to procure are eliminated, and the requirement items necessary for the actual systems are included, even if they are not listed in the sample requirement tables. 80 The technologies listed in the table “Related Technology” are those supposed to be referenced in procurements, or the related open-standards. Referencing them in procurement specifications requires sufficient care and sufficient knowledge about those technologies. Simple copy of items listed in the sample requirement items would in some cases lead to less possible procurement realization — strikingly reduce the room of choice of products to be procured —, or lead to difficulties in the utilization of the existing assets due to the discrepancies between versions of open-standards. Therefore, in the reference of the sample tables, attention must be paid to total consistency in relation to the procurement. 81 5.1. BI/DWH/ETL 5.1.1. Definition BI / DWH / ETL collectively refers to a system that provides proper information in a proper style, at a proper time, and to a proper user: it is a mechanism for referring to or analyzing data in job-operations through searching, referencing, operating, transforming, and archiving in a integrated and multi-purpose way. In addition, it contributes to the reduction of person-months required for the development of screens for analytic-operations or job-forms. Figure 5.1-1 Elements and Usage in Job-Operations of Business Intelligence Selectively combining the functions or services of BI / DWH / ETL listed in the table below, enables the functions or services shown below. (Note that they are examples). ・ Business Performance Management 82 The objective is to realize productivity improvement — by measuring and monitoring the effectiveness of job-operations, and making predictions through applying quantitative or qualitative benchmarks — and to enable prompt detection of trends or risks. It will support job-operators in every situation, by seamlessly connecting a series of job-management activities, such as assured delivery of tactically important information of job-operations or events, predictions on job-operations and problem-resolution, enabled by integrating relational databases existing in data-marts, spreadsheets, and tools for analysis such as data-mining, into a single large system. ・ Integrated Financial Analysis Integrated Financial Analysis enables financial analyses such as a cost-effectiveness analysis through providing all the decision-makers with the critical financial information on job-operations in a secured and effective manner,. It serves as an analysis tool in job-operations executed in a systematic and integrated way on the platform consisting of data warehouses, ODSs or spreadsheets, and OLAP. Therefore, it also requires correctness of data and high-level security. In addition, it contributes to the effectiveness-improvement of the existing various job-operations involving statistics. Functions and Services of BI / DWH / ETL Functions and Services Definition / Description Business Intelligence Refers to the following: an approach to utilizing a (BI) large-volume data output from job-operation systems, etc.; a mechanism or an activity enabling job-operations and predictions, based on a philosophy of establishing knowledge or insight available for making decisions through systematically and methodically storing, classifying, searching, analyzing, and processing factual data; and a system or technology supporting such activities. It aims to flexibly analyze the required information on job-operations and be utilized to provide improvement for various kinds of job-operations. Data Warehouse(DWH) Refers to the following: a collection of time-series data organized and integrated in groups according to the objectives of use, without mechanisms for deleting or updating, where transaction data is extracted from job-operation systems, re-organized, and stored there to be used for information analysis or decision-making; and a decision support system based on large-scale databases, or an integration concept of such systems. ETL — Extract / Refers to a series of data processes that extracts data, 83 Transform / Load (Functions for data extraction, process and saving) Data Mart OLAP — Online Analytical Processing (Tools for data collection or analysis) ODS — Operational Data Sore (temporal data saving system) Data Mining Information dashboard Reporting tool (Reporting service) Spreadsheet transforms it so that it is easily used in a data warehouse, etc, and then loads it into target systems such as data warehouses, etc.; and a software function that supports such a series of processes. Refers to a database, in comparison with the central data warehouse integrating and managing the entirety of job-operation data, composed of data extracted from data warehouses, edited, and stored for specific departmental or private purposes; and a subset of data extracted for the use of specific departments or users. Refers to a philosophy and the realization of an analytical application so that end-users directly search / tabulate data existing on a database for finding problems or actions to take: it is generally categorized in the following three ways: ROLAP using databases, MOLAP using multi-dimensional data bases, and HOPLS combining the two. Refers to a collection of job-operation data, extracted and temporarily stored for auxiliary purposes such as search etc. Refers collectively to knowledge-finding methods or processes, by which, through the analysis of huge amount of data by different analytical techniques, the hidden knowledge on how the data links to each other or what the data indicates is uncovered. The models created through such processes will be available as the foundation of predictions or simulations. Refers to a personalized software tool for accessing information on portals, or sharing information such as outputs of analysis: it is available for consolidating communication paths. Refers to a tool for providing a variety of viewpoints for data generated through job-operations, by summarizing, classifying, prioritizing, and display: it supports creation, management, or delivery of written or interactive web-based reports. Refers to application software for tabulating or analyzing numerical data, by interpreting numerical data or mathematical expressions written in a cell at a cross section of a row and a column of a table, automatically executing the calculations, and putting the results into designated cells. Being equipped with interactive cross-tally tables, it is available as a front-end of BI by standardized open-formats or interfaces to web-services. 84 5.1.2. Business Intelligence (BI) BI refers to an approach of utilizing an enormous amount of job-operation system output data, etc, for decision-making, by storing, classifying, searching, analyzing, and transforming factual data: it also refers to a scheme or an activity for realizing the idea of extracting useful knowledge or insights in a systematic way and enabling business predictions, or systems and technologies supporting such activities. Its objective is to utilize information for improving job-execution efficiency through flexibly analyzing the required information. In comparison with conventional data-analysis, which is closed in individual stand-alone systems, along with the implementation of system-linkage infrastructure such as SOA, the cross-system analysis of data separately stored in individual systems after being homogenized has become necessary, and the mechanisms for the management and transformation of meta-data has been implemented. Note that the corresponding mechanism (meta-data registry) has almost the same functions as those of the combination of ETL and DWH. Functional Requirement 1 Basic Capability of storing / classifying / searching / analyzing / transforming data in a systematic and integrated way. 2 Basic Mechanisms for enabling the production, through analysis, of useful knowledge or insights. 3 Additional Capability of combining [data-warehouse, ETL, data-mart, OLAP, data-mining] methods according to the needs. 4 Additional Capability of visualizing the results of analysis on [BSC, information dashboard, reporting-tool, and spreadsheet, etc.] according to the needs. 5 Additional Mechanisms for interactively selecting various forms or graphs. 6 Additional Mechanisms for raising an alert for proper users triggered by a predefined threshold. 7 Additional Mechanisms of meta-data registry (transformation of meta-data or homogenization of data-quality at the exchange of data between systems), effective on the analysis of linked data on a system-linkage infrastructure. Non-functional Requirements (write only when individually required) Backup Additional Functions of data-backup or data-recovery. Security Additional Permission for the explicitly authenticated users by IDs to execute processes of data-search / data-check. Related Technologies Format of ISO / IEC 11179ISO Meta-Data JIS X4181-3 (JIS X4181-1, JIS X4181-2) — JIS standards Registry fully-compatible with the international standard, ISO / IEC 11179) 85 5.1.3. Data Warehouse A Data Warehouse refers to a collection of time-series data integrated and edited according to purposes, which basically, have no mechanisms for data deletion or staying up-to-date: it is used for information analysis and decision-support through extracting, re-organizing, and archiving transaction data generated by job-operation systems. It also refers to a decision-support system based on a large-scale data base, or the system-construction concept of such systems. Functional Requirement 1 Basic Configuration as a collection of time-series data integrated and arranged according to purposes. 2 Basic Capability of archiving, for a long time, raw data (detail data), not yet transformed into forms suitable for analysis. 3 Basic Capability of extracting, re-configuring, and archiving transaction data. 4 Basic Application of independent development of business application systems. 5 Basic Deletion or updating of data is prohibited under normal conditions. Related Technologies Interfaces for SQL DB Access 5.1.4. ETL — Extract / Transform / Load (Data Processing Capability) ETL refers to a series of data processing that extracts data stored in job-operation systems, etc (Extract), transforming into forms suitable for being used in data warehouses, etc (Transform), and loading into target systems such as data warehouses, etc. (Load). It also refers to functions supporting such data processing. ETL enables data-cleansing, etc. Functional Requirement 1 Basic Capability of extracting data from various types of data-sources [standard-format files, data bases, or FTP, etc.]. 2 Basic Provision of selections for consolidation / transformation of data available [filtering, tabulation, division, binding, conditional branching, or derivation (creating row-values according to the formula embedded in the input row, and storing of the results as a new row or replacing an existing row)]. 3 Basic Capability of loading data from target systems [data warehouse, or data mart, etc.]. 86 4 5 Basic Capability of exception-handling, for such cases as error events in various types of data-flows. Additional Capability of setting / executing [various types of operations of data or flow-controls, etc]. Related Technology Interfaces for SQL DB Access 5.1.5. Data Mart A Data mart refers to a database consisting of the data extracted and reorganized, for departmental or private purposes, from the archives in the data warehouse: it is a subset of data extracted according to the operational needs of particular departments or users, while the central data warehouse manages, in an integrated way, the entire job-operation data. Functional Requirement 1 Basic Employment of databases consisting of the data extracted according to purposes separate from the data archived in the data warehouse. 2 Additional Employment of a database of summarized data for efficiently responding to requests of search or analysis. Related Technology Interfaces for SQL DB Access 87 5.1.6. OLAP — Online Analytical Processing (Data Tabulating / Analyzing) OLAP refers to a philosophy and a system realization of an analytical application, allowing end-users to directly search / tabulate data existing on a database for finding problems or actions to take. It is generally categorized in the following three ways: ROLAP (Relational OLAP) using relational databases, MOLAP(Multidimensional OLAP) using multi-dimensional data bases for aggregating and tabulating data, and HOLAP (Hybrid OLAP) with high-speed preprocessing and scalability. Figure 5.1-2: Elements and Usage in Job-operations of OLAP Functional Requirement 1 Basic Assurance of end users’ direct search / tabulation of data existing in databases. 2 Basic Employment of a relational database or pre-optimized data-management system. 3 Basic Provision of multi-dimensional conceptual views. 4 Basic Accessibility from a reporting function or a spreadsheet through [pivot-table service (PTS), etc.]. 5 Basic Assurance of users’ easy access to data without the knowledge of physical storage-structure of the data. 88 6 7 8 9 10 11 12 13 Basic Capability of providing any dimension or cell with functions of [slicing, dicing, or drilling, etc] with the equal performance. Basic Uniformity of structure and operations in every dimension. Basic Capability of executing dynamic matrix-processing. Basic Accessibility by multiple-users simultaneously. Basic No functional limitations of software in cross-dimension processing. Basic Capability of flexible reporting. Basic No limitations on the number of dimensions or members Basic Capability of individually executing each processing [slicing, dicing, or drilling, etc] without the help of menus. Related Technology Interfaces for SQL DB Access Query MDX (Multi-Dimensional Expressions) — used in obtaining or Language manipulating multi-dimensional data. 5.1.7. ODS — Operational Data Store (System for Temporarily Preserving data) ODS refers to a collection of data which consists of job-operation data extracted from job-operation systems and temporarily stored for additional purposes such as search etc. Functional Requirement 1 Basic Function as database for extracting and temporarily storing data from the job-operation system. 2 Basic Capability of storing volatile real-time data. 3 Basic Capability of the short-term preservation of data Related Technology Interfaces for SQL DB Access 89 5.1.8. Data Mining Data mining collectively refers to knowledge-finding methods or processes, by which, through the analysis of huge amounts of data by various analytical techniques, the hidden knowledge on how the data links to each other or what the data indicates is uncovered. The models created through such processes will be available as the basis of predictions or simulations. Figure 5.1-3: Elements, Processes, and Usage in Job-Operations of Data Mining Functional Requirement 1 Basic Mechanism for, through the analysis of huge amount of data, finding the hidden relationships of data or knowledge. 2 Basic Mechanism for visualizing relationships of data or knowledge. 3 Basic Mechanism for creating prediction-models from relationships or knowledge, and functions for making predictions through the application of such models to a new data-set. 4 Basic Mechanism for assessing the accuracy of predictions. 5 Basic Mechanism for selecting algorithms [correlation rules, clustering, decision-trees, naive Bayes, neural nets, etc.] to apply to the analysis. 6 Basic Mechanism for repeating analysis in a trial-and-error way aided by a GUI. 90 7 Additional Functions for data-access or output through [reporting tools or spreadsheets, etc]. Related Technology Interfaces for SQL DB Access 5.1.9. Information Dashboard The Information Dashboard refers to a personalized software tool for accessing portals, or sharing information such as analysis outputs: it is used for the purpose of consolidating communication paths. Functional Requirement 1 Basic Capability of constructing portal sites without difficulty, satisfying specific requirements from target users, based on the integrated portal framework. 2 Basic Capability of constructing more than one type of web site [private site, departmental site, intranet site, extranet site, internet site, etc.]. 3 Basic Employment of authoring tools enabling easy content posting. 4 Basic Capability of allowing the owner of information to specify, through the built-in functions, how and when to deliver the information to the specified users. 5 Basic Capability of personalizing the information to be delivered. 6 Basic Employment of a framework for comprehensively-integrating applications, enabling construction of composite-applications. 7 Basic Functions for application-governance to detail-control the application-execution environment. 5.1.10. Reporting Tool (Reporting Service) A Reporting tool refers to a tool for providing a variety of view points for data generated through job-operations, by summarizing, classifying, prioritizing, and displaying: it supports creation, management, or delivery of written or interactive web-based reports. 91 Figure 5.1-4 Elements and Usage in Job-Operations of Reporting Tools Functional Requirement 1 Basic Capability of providing user-friendly visualized information through [summarizing, classifying, or prioritizing, etc. 2 Basic Capability of allowing users to select data-sources and access methods. 3 Basic Provision to users of report-creation functions, report-templates, and report-management screens. 4 Basic Functions for assisting the creation of written or interactive web-based reports [creation and management of forms]. 5 Basic Capability of allowing users to specify the viewers in the publication or delivery of reports. 5.1.11. Spreadsheet Spreadsheet refers to application software for tabulating or analyzing numerical data, by interpreting the numerical data or mathematical expressions stored in a cell at a cross section of a row and a column of a table, automatically executing the calculations, and storing the results in the 92 designated cells. Being equipped with interactive cross-tally tables, it is available as a front-end for BI through standardized open-formats or interfaces to web-services. Functional Requirement 1 Basic Capability of serving as a front-end of OLAP or data mining (or others categorized in BI). 2 Basic Capability of embedding automatic-execution mechanisms or constraint conditions. Note: Also, refer to “5.8.5 Definitions of Common Operations,” and “5.8.5.8 Functional Requirements for Table Calculations.” 93 5.2. EAI 5.2.1. Definition EAI (Enterprise Application Integration) collectively refers to functions, middleware / application packages, or integration technologies for linking / integrating different computer systems or business application packaged products by means of a hub-and-spoke architecture, and providing strategically enhanced functions or enriched information. Conventionally, data-exchange between servers has been executed by means of a file-transfer or messaging technologies. However, as the number of servers requiring data-exchange has increased, the idea has emerged that it will be more efficient, if the development and maintenance cost is taken into consideration, to establish such a data-exchange function as a standard function than to individually develop and maintain each data-exchange mechanism. In EAI, which has emerged out of such ideas, data-exchange is generally executed asynchronously (loosely coupled) for the purpose of preventing ripple effects of EAI processing-delays to the inter-connected servers by allowing the servers to execute processes independently and asynchronously. Figure 5.2-1 Schematic Diagram of EAI Definition of EAI Function and Service Name of Function or Definition Service EAI Function It links / integrates, in a organic way, different computer systems and business-packaged software products by means of a hub-and-spoke type architecture, and provides them as more strategic information resources. In addition, it provides more than one adapter for the purpose of inter-system connection, such as an application adapter enabling easy 94 connections to business packages, a technology adapter for enabling easy connections through standard protocols, and a mainframe adapter enabling easy connection to main frame computers. 5.2.2. Functional Requirement Functional Requirement 1 Basic Capability of format-transformation — transforming data or characters written in individual formats or character-codes used in a system or an application connected to the EAI to other different formats or codes. 2 Basic Capability of routing — delivering data to more than one recipient according to the contents of the data. 3 Basic Employment of more than one connection support mechanism (adapter) prepared to reduce the interface development work on the side of servers to be connected to the EAI. 4 Basic Capability of process-control — enabling automatic job-execution by combining different functions such as routing and format-transformation. 5 Basic Capability of data-item-mapping — mapping a data-item used in a system to a data-item used in other system. Non-functional Requirement (write only in a case of individual-purchase) Meta-Data Additional Employment of meta-data definitions in an industry Definition standard format, such as SWIFT, FIX, or EDIFACT: by using the prepared format, users are able to greatly save the cost of developing meta-data from a scratch. Development Additional Functions of EAI middleware products preparing GUI Environment development environments where “drag & drop” or built-in functions enables “intuitive” development, instead of coding in a programming language: it will ensure high development-efficiency and maintainability (easy maintenance), because members without programming expertise can participate in the development. 95 5.3. iDC Facility 5.3.1. Definition iDC (Internet Data Center) Facility refers to a highly-secured and quake-resistant facility equipped with high-speed telecommunication lines, power generators, and high-power air-conditioning systems that hold servers, network-equipment, etc. (hereinafter referred to as “equipment,” etc.) on which job-operation systems run. It is used for operation-work such as monitoring and troubleshooting of the equipment, etc and the applications. The services provided by an iDC are categorized generally into housing services and hosting services. In the housing service, users install the equipment of their property in the iDC, and receive services such as the internet connection or operation of that equipment. On the other hand, in the hosting service, users use the equipment (dedicated to the user or shared) connected to the internet of the providers’ property and receive the service of operational work: generally, the hosting service is used for web servers or mail servers. Note that, because in the case of a housing service, equipment etc is generally purchased separately, therefore procurement specifications for such equipment are necessary. In normal cases, because equipment, etc. is provided installed in a rack, the procurement specification should be for such racked equipment, etc, where the items of the specification are as follows: rack-size; number of racks; rack-weight (total weight of rack and equipment); power (maximum power consumption after equipment-installation); amount of heat generation (total for all equipment installed); and power-supply (voltage, shape of receptacle, and number of receptacles). Also, note that purchase of telecommunication lines (including monitoring service) is categorized as a separate-purchase, and is not included in the purchase of an iDC. Functions and Services of iDC Facility Functions and Services Definition Location Requirement Refers to requirements for the location such that the iDC will not lose the ability of providing services even in a situation caused by a natural disaster such as an earthquake where the iDC is damaged. Facility / Machine-room Refers to a requirement for facility-structures such as Requirement quake-resistance of the building or duplexing of communication equipment such that the iDC will not lose the ability of providing services. A machine requirement refers to a requirement for installation-environments (sites) of the racks loaded with equipment, etc. Power / Air-conditioning Preservation of redundancy such as duplexing of power / Requirement air-conditioning system such that the equipment, etc. (or the services) will not lose the ability to run due to problems in the power / air-conditioning system. 96 Security Requirement Operation Requirement Physical security measures preventing illegal intrusions / interferences / destruction, or illegal access to the properties in the iDC that are closed to public, excluding work on implementing security measures on equipment, etc. which are categorized as operational services separately purchased. As for such operational services, refer to “5.9. System-Operation Management / Security.” Maintenance / management of iDC facility, excluding monitoring, configuration, malfunction-control, or storing backup equipment, etc., which are categorized as operational services separately purchased. As for such operational services, refer to “5.9. System-Operation Management / Security.” 5.3.2. Location Requirement A location requirement refers to a requirement of location for an iDC. Functional Requirement 1 Basic An iDC shall be located in a place where earthquake damage is expected to be minimal. (Be sure to avoid places close to active faults pointed-out in documents, or places pointed-out in documents that have suffered liquefaction damage in the past.) 2 Basic An iDC shall be located outside of dangerous zones designated in hazard-maps, etc. publicized by the MLIT or the local governments 3 Basic An iDC shall not be located in a place where a flood caused by tsunamis, high-tides, or torrential rains is expected. 4 Basic An iDC shall not be located in a place within {100 meters} of which the total number of hazardous-material producing facilities or high-pressure-gas producing facilities located exceeds that designated by the Fire Defense Law. 5 Basic An iDC shall be located in a place accessible by maintenance-service providers within {30 minutes}. 5.3.3. Facility / Machine Room Requirement A facility requirement refers to a requirement for a facility, such as quake-resistant structure of a building or duplexing of telecommunication equipment. A machine room requirement refers to a requirement for the installation environment for racks or equipment, etc. Functional Requirement 1 Basic Employment of a quake-resistant or quake-absorbing structure against an earthquake of intensity 6 upper. 2 Selective Employment of a fire-alarm (fire-protection) system compliant with the Building Standard Act and the Fire Defense Law, or a system capable of sensitively catching changes in the room environment to detect early signs of a fire. 97 3 4 5 6 7 8 9 10 11 12 Selective Employment of fire-extinguishing equipment that is water-proof against the floods caused in fire-fighting activities, and of zero-ozone-depleting coefficient. Or, employment of nitrogen-fire-extinguishing equipment for the purpose of protection against the floods caused by fire-fighting, environmental protection, and the avoidance of influence on human bodies. Basic Buildings with more than {2} doorways for ensuring more than one evacuation route available. Basic Capacity for installing more than {2} provider-independent telecommunication lines running on different routes. Basic Structure of machine rooms protecting the rooms from being viewed from outsides, such as a windowless structure. Basic Free-access floor that resists against more than {500} gals of maximum of acceleration. In the case where the building is of quake-absorbing structure, the building or the quake-absorbing equipment shall resist against the acceleration mentioned above. Basic Machine-room with ceiling height of more than {2,400} millimeters, excluding the height of a free-access floor. Basic Free-access floors able to resist against more than {600} kg / m2 of the floor load including the equipment separately purchased and the racks implemented with equipment. Basic Machine-rooms compartmented against fire. Basic Provision, for security reasons, of individual compartments separated from the spaces for other users. Or, the racks are able to be locked user by user for the separation of users. Basic Provision of the installment environment (functions) specified in the specification of racks or equipment separately purchased. Non-functional Requirement (write only when individually specified) Environmental Basic Certification of compliance with the international standards of Requirement environmental management systems, ISO14001. 5.3.4. Power / Air-conditioning System Requirement A power / air-conditioning system requirement refers to a requirement for power / air-conditioning systems for redundancy-ensuring such as duplexing of those systems. Functional Requirement 1 Basic Full-non-interruptive access to electricity even during periods of legal inspection. 2 Basic Employment of uninterruptible power supply systems (UPS), constant voltage and constant frequency units (CVCF), and power generators. The generators shall be operative fully-undisrupted, by re-fueling through all the period they are used, 3 Basic Availability of more than {2} external power-supply routes / methods, and redundancy of electricity ensured in the facility by duplexing, etc. 98 4 Basic 5 Basic 6 Basic Employment of air-conditioning systems with redundancy ensured by duplexing, etc. Such systems shall be continuously operable for more than {24} hours in a situation where water supply is lost due to natural disasters. Capability of providing the power supply systems (functions) specified in the procurement specifications of racks or equipment separately purchased. Capability of providing the air-conditioning systems (functions) specified in the procurement specification of racks or equipment separately purchased. 5.3.5. Security Requirement A security requirement here refers to a physical security requirement. Functional Requirement 1 Basic Authentication-for-security mechanisms for the entry to the building and for entry to the machine room are independent to each other; and in addition, security measures at the entrances, by such means as the stationing security guards. 2 Basic Automatic security systems [such as intrusion detectors, surveillance cameras, or entry / exit management systems, etc.] 3 Basic Management of entry / exit operating on a 24 hour / 7 day basis. 4 Basic Employment of Identification systems, such as IC card systems or biometric identification systems for managing entry / exit to / from the rooms inside the iDC, and monitoring cameras in shared spaces or server rooms. Non-functional Requirement (write only when individually specified) Assessment / Basic Certification of compliance with “Information Security Certification of Management System (ISMS) Compliance Evaluation System Security (JIS Q 27001, ISO / IEC27001),” and a permission as a business operator to use the privacy mark. 5.3.6. Operational Requirement An operational requirement refers to a requirement for maintaining / managing the iDC facility Functional Requirement 1 Basic Development of a management unit on a 24 hour / 7 day basis of iDC facilities and a contact office for problem management, etc. 2 Basic Execution of inspections of the iDC facilities based on time table, etc. 5.3.7. Compatibility with Virtualized Systems Functional Requirement 1 Basic Capability of implementing the software products used in the physical-server environment in the environment realized by virtualization mechanisms, etc., which consist of virtualized guest-servers and virtualized networks, so that such software products work in the same way as they do in the physical environment. 99 5.4. SOA Related Functions 5.4.1. Definitions 5.4.1.1. SOA(Service Oriented Architecture) SOA is an architecture that enables “services” — software functions corresponding to the individual job-operations — to be accessible and linked to each other on a network by the standardized protocols and work as an integrated system. At present, such architectures are generally compliant with the Web service technical specifications. The architecture also ensures prompt system constructions and high maintainability, by defining interfaces between services and linking them on the network. Management Mashup Portal Service Intermediation, Security / Policy Management Providing Mashup Service as the FrontGateway Business Activity Management Application Monitoring, Management of SLA and KPI Development Environment Providing IDE or ApplicationDevelopment Framework Business Process Management Organizing Business Processes Compatible with Standards, Workflow Management Enterprise Service Bus Messaging, Connection, Information Delivery Adapters Web Services Protocol Service Repository / Registry Centralized Management of Information on SOA Services Providing Connections to Web Services, Legacy Infrastructure Systems, Data Bases, ERPs, Security, HighReliability Message, banckback-end Systems, Custom-Application & Transaction Service, or JCA Web Service ERP / Legacy Application Business Intelligence Custom Application / Service Figure 5.4-1 Major Components in SOA Functions and Services of SOA Function / Service Definition Business Process Supports the execution of business processes through defining Management combination and flow control for different services. Enterprise Service Bus Realizes the integration of services by enhancing the independency of services from others and assuring the message reliability by means of encapsulation of interfaces between the applications distributed. Management Intermediates services and manages security and policies. 100 Mashup Portal Business Activity Monitoring Works as a front gate way and provides the mash-up services. Monitors job-operations and processes, associates SLA or KPI (Key Performance Indicators) with the actual business processes, and visualizes them. Development Provides IDE for the development of SOA services and a framework Environment for the development of applications. Service Repository / Enables the life-cycle management of services through registering, Registry publicizing, and searching the information on SOA services, and at the same time enables job-applications to call services dynamically. Adapters Provide connections to web services, legacy systems, databases, ERPs, back-end systems, custom applications, and services. Web Services Protocols Enable integration of applications existing on the different platforms using the internet technical standards. For details, refer to “Function / services of web service protocols.” Note that the following are additional descriptions on some of the functions or services in the table above: An Enterprise Service Bus provides messaging or data-conversion functions for the realization of the integration of applications; Business Process Management, which manages individual services, realizes job-applications by combining services and controlling their execution by use of adapters (through web service protocols); Business Activity Monitoring collects the performance data and alert information from the Business Process Management, and displays it as job-process information in a visualized form; Mashup Portal Service receives information-contents or data from the Business Process Management, and provides the users of the system with the contents or data in a mashed-up form; Service Repository / Registry will support the environment for easy mash-up development through providing the SOA information. System administrators and developers on the provider side also benefit from the SOA functions for management in the collection of service-log information or statistical monitoring information. In addition, from the development, they benefit from the development environment because it provides an integrated environment for the development of applications with resistance to changes because of the separation of services and interfaces. 101 Figure 5.4-2: SOA Components and Their Relations 5.4.1.2. Web Service Protocol Web Service Protocol collectively refers to technologies for linking applications distributed on networks: it is a mechanism enabling collaboration with applications on a different network, or a mechanism enabling the creation of new applications or services by linking web-services realized on the basis of web service protocol. Figure 5.4-3: Fundamental Component of Web Service Technology 102 Functions / Services of Web Service Protocol Function / Service Definition Base Technology Publicizes descriptions of services — what functions the web-service has, or what requests are required for using them. In addition, it authenticates a service published for use to exchange messages. Security Service A Service component, selective and usable with others: it enables a Component web service to enhance its function to realize the integrity and confidentiality of a message. High-Reliable Service components, selective and usable with others: They enable Messaging Service a web service to enhance its function to improve message-reliability Component in the communications with applications distributed on networks. Transaction Service Service component, selective and usable with others: it enables a Component web service to enhance its function to realize transactions to applications distributed on networks. 5.4.1.3. Common Technology Standard It refers to a standardized technology, commonly used as the basis of SOA or web service protocol: it ensures the realization of highly-interoperable functions or services. Function / Service of Common Technology Standard Function / Service Definition Common Technology Technology standard used as a basis of SOA or Web service Standard protocol 5.4.2. Business Process Management Functional Requirement 1 Basic Provision of data-manipulation functions for defining data or control-flows for business process 2 Basic Capability of defining processes by combining and using functions such as service-calls, data-manipulation, malfunction notification, exceptional processing, or process-termination 3 Basic Capability of executing management jobs according to the standards for communicating with services (Web service protocol, etc.) or implementation-rules. Non-functional Requirement (write only when individually required) Backup Additional Saving backup of business process configuration information 5.4.3. Enterprise Service Bus Functional Requirement 1 Basic Provision of a common back-bone with a configuration independent from particular network-transport technologies for linking different systems 2 Basic Capability of transforming data or communications based on one protocol to that based on a different protocol 103 3 Basic Capability of converting data in one format to that of other format 4 Basic Capability of routing messages according to their contents 5 Basic Capability of sending messages without loss between remotely-distributed applications in a situation when malfunctions in applications or the network occurs, in order to enable roll-back transactions to notify errors, or re-sending transactions after the problems have been resolved 6 Basic Capability of being used independently from, or without disturbing, the processes of other components using the bus Non-functional Requirement (write only when individually required) Backup Additional Saving for backing-up the setting information of service linkage Related Technology XML Query X Query: Query language of XML data Language XML XSLT: language for specifying transformation scheme of XML data Transformation Language 5.4.4. Management Functional Requirement 1 Basic Capability of defining policies for controlling service-operations (access-policies, logging-policies, or contents-verification, etc.), or monitoring schemes for access or execution of services 2 Basic Capability of applying policies without modifying existing services 3 Basic Capability of centrally managing and visualizing statistics of monitored information Non-functional Requirement (write only when individually required) Backup Additional Saving backup of policy-settings and statistical monitoring information 104 5.4.5. Mashup Portal Functional Requirement 1 Basic Provision of functions for combining more than one service interface into one portal application 2 Basic Capability of modifying UI without needing to modify the business logics of existing applications Non-functional Requirement (write only when individually required) Backup Additional Saving backups of settings related to the configuration of portal applications 5.4.6. Business Activity Monitoring Functional Requirement 1 Basic Provision of functions for monitoring job-operations or processes and visualizing them 2 Basic Provision of functions for analyzing the actual business processes in comparison with an SLA or KPI, and visualizing them 3 Basic Provision of functions for monitoring job-operations and processes and raising alerts Non-functional Requirement (write only when individually required) Backup Additional Saving backup of information obtained through business process monitoring 5.4.7. Development Environment Functional requirement 1 Basic Provision of the Integrated Development Environment (IDE) for developing SOA services 2 Basic Provision of an application development framework for developing SOA services 3 Basic Capability of supporting the entire life-cycle of SOA service development (modeling, program-development, debugging, testing, profiling, tuning, deployment). In addition, to be executable from the IDE Non-functional Requirement (write only when individually required) Backup Additional Saving backup of source-codes and configuration settings used in the SOA service development Related Technology Design Notation UML (Unified Modeling Language): an unified notation for program-design used in the software development phase, developed by OMG and based on the object oriented method 105 5.4.8. Service Repository / Registry Functional Requirement 1 Basic Provision of a mechanism for registering, publishing, and searching of information on SOA services, based on the standards 2 Basic Capability of imposing access-permission of search, acquisition, modification, or deletion on any component 3 Basic Provision of management-interfaces for registering, publishing, or searching published SOA services Non-functional Requirement (write only when individually required) Backup Additional Saving backup of settings on service repository / registry 5.4.9. Adapter Functional Requirement 1 Basic Connections to [web services, legacy systems, databases, ERPs. Back-end systems, or custom application systems] 2 Basic Capability of allowing synchronous-calls of application- transactions, work-flows, query-application data 3 Basic Capability of allowing transmission or receipt of events to or from central-job-application Non-functional Requirement (write only when individually required) Backup Additional Saving backup of connection settings Related Technology Web Service WSDL (Web Service Description Language): a specification of description of Description web-service interfaces in XML language Language Industry Industry standards used in business fields, such as XBRL (eXtensible Standard Business Reporting Language: XML vocabulary for financial data description, UN / CEFACT CCL (Core Component Library): coded information-items used in various industry segments), or the government standard 5.4.10. Web Service Protocol 5.4.10.1. Web Service Protocol (Base Technology) Functional Requirement 1 Basic Use of internet-standard communication protocols (TCP / IP or HTTP) 2 Basic Provision of a mechanism for realizing message-exchange or procedure-call based on XML 3 Basic Provision of an environment for developing and deploying web services 4 Basic Provision of a mechanism for realizing data-transmission or receipt to or from web services 106 5 Basic Capability of defining what function a service has or what request is required for using the service Non-functional Requirement (write only when individually required) Performance Additional Configuration with a sufficient processing power for avoiding an unallowable delay of the processing of the existing programs, while a web service protocols are being processed Backup Additional Saving backup of settings of web service interfaces Related Technology Web Service SOAP (Simple Object Access Protocol): XML-based protocol for calling data Communication or services existing on other computers Protocol Web Service WSDL (Web Service Description Language): specifications for describing Description web-service interfaces in XML format Language Web Service WS-I Basic Profile: a guideline for the enhancement of the interoperability of Interoperability SOAP-message-exchange or WSDL descriptions. The V1.1 agreed in WS-I Profile is the present ISO standard as follows ISO / IEC 29361::2008 — WS-I Basic Profile Ver. 1.1 ISO / IEC 29362::2008 — WS-I Attachments Profile Ver. 1.0 ISO / IEC 29363::2008 — WS-I Simple SOAP Binding Profile Ver. 1.0 5.4.10.2. Web Service Protocol (Security Service Related Component Functional Requirement 1 Basic Provision of a mechanism to assure the integrity and confidentiality of message content 2 Basic Ensuring of the availability of [the attachment of a digital signature, the attachment of user-authentication data (token), or the encryption of messages]. In addition, the capability of protecting the security of them. 3 Basic Configuration allowing any standard signature or encryption algorithm 4 Basic No requirements of modifications on the processes of components related to other web-service protocols Non-functional Requirement (write only when individually required) Performance Additional Configuration with sufficient processing power to prevent running programs from disturbance during signature processing or encryption processing. Backup Additional Saving backup of settings for message integrity and confidentiality of a message Related Technology Web Service WS-Security: technology base for realizing the security of web-services, by Security specifying the method of implementing the existing security technologies such as XML-signature or XML encryption into a header of a SOAP message, and providing a common base for integrating security 107 Secure Communication Protocol technologies. SSL (Secure Socket Layer): protocol for transmitting or receiving encrypted data on the internet 5.4.10.3. Web Service Protocol (High-Reliability Message Related Service Component) This sub-section stipulates here only the title, because more discussions are expected to be required before such an item is actually procured. 5.4.10.4. Web Service Protocol (Transaction Related Component) This sub-section stipulates here only the title, because more discussions are expected to be required before such an item is actually procured. 5.4.11. Common Technical Standard Related Technology XML XML (eXtensible Markup Language): a markup language for describing Description structured data or documents Language XML Schema W3C XML Schema: a schema language for defining structures or data-types Language of XML documents 108 5.5. Maintenance Environment 5.5.1. Definition Maintenance Environment refers to a physical work-environment for maintenance or management of systems: it is, after systems’ cut-over, used for functional enhancement of application programs, or verifications of version-ups, required on the expiration of the support contract, of software, such as an OS, commercial software packages, or open-source software, etc. More specifically, it contains maintenance process manuals for methods and maintenance procedures of systems including the (actual) operation-environment, hardware / software used in maintenance work, maintenance tools (development tools), and automatic test tools. The maintenance environment is completely independent of the “development environments” installed in vendor sites and used for software development: it consists of the following; the Software Engineering Environment used for support works such as software maintenance, modification, or correction, etc.; and the Software Testing Environment used for software tests. Maintenance Environment Software Engineering Environment Software Test Environment Firewall (or Router) Test LAN Development LAN Development Tool (Maintenance Tool) Test Tool ( for unit-test or functional test) PCs f or Developmentwork in Maintenance Test Tool (for Stress Test) Version Management (Configuration Management Tool) Build Tool Conf iguration Management Server Test Environment (f or Acceptance Test) Firewall (or Router) Inter network (Bridge) LAN PCs f or LAN System Operator Job-Operation (actual) Servers Job-Operation (actual) LAN Figure 5.5-1 Schematic Diagram of Maintenance Environment 109 Test Tool (for Vulnerability Test) Staging Environment The following table describes the definition of functions or services in the maintenance environment. Function / Service Maintenance Process Definition Refers to methods and procedures for correcting or modifying system configuration items (CI) such as hardware or software, etc. Audit Process Refers to methods and procedures for confirming that the information security rules have been applied compatibly and properly. Development Tool Refers to methodologies, processes, and tools for design / development / maintenance, or an aggregation of tools (Integrated Development Environment: IDE) Configuration / Version Refers to a tool for managing versions of application programs or Management Tool documents — design documents or procedure manuals — expected to be updated frequently: it is used for, controlling and recording modifications on hardware, software, or firmware throughout systems’ lifetimes., By collectively managing the information of configuration items (CI) used in development or operational environments, it provides configuration information for maintaining the integrity of the system. Development LAN Refers to an internal LAN used by the software engineering environment: for the security reasons, it is physically and logically separated from the job-operation (actual) environment. Test LAN Refers to an internal LAN used by the software test environment: for the security reasons, it is physically and logically separated from the job-operation (actual) environment Inter network (Bridge) Refers to an internal LAN used for connecting the development LAN LAN and the job-operation (actual) LAN: in some cases where those LANs are separated logically, the inter network (Bridge LAN) is replaceable with equipment such as switches or routers, etc. Test Environment (for Refers to an environment for verification work such as builds, Acceptance Test) connection tests, system tests, or regression tests of the application programs after completion of a unit test by the vendors Test Tool Refers to a test tool used in the maintenance environment, for the system deterioration or purpose of preventing performance-degradation accompanying system modifications, to ensure efficient execution of regression tests or performance tests Staging Environment Refers to a test environment of a similar scale of system configuration (both hardware and software) to that of the job-operation (actual) environment: it is used for checking security-patches or bug-fix patches before the application to the job-operation environment for confirming that the application of those patches causes no troubles. In some cases, it is constructed on visualized servers and storages. 110 5.5.2. Functional / Non-functional Requirements for Maintenance Processes The Maintenance Process defines the actions, methods, and procedures required in a case of hardware or software malfunctions or functional modifications, in job-operation (actual) environments or development environments. Functional Requirement 1 Basic Complete definition of methods or procedures of works to be done in the phase starting at the completion of development and the beginning of system operations, and ending at the termination of operations and abolishment of system 2 Basic Clear definition of rules such as a rule of request for modification or a rule of approval of modification 3 Basic Definition of maintenance process for each of the job-operation (actual) environment and the maintenance environment Non-functional Requirement (write only when individually required) Integrity Basic Definition of the maintenance process consistent with the system-lifecycle and the requirements defined in procurement plans, procurement specifications, and basic system design documents. Related Technologies IT Service Refers to a mechanism for executing the management and operations of IT Management services matching the level of customer-requirements, and continuously improving the service quality. ISO / IEC 20000, JIS Q 20000, ITIL v. 3 Software Refers to a series of modification-work of codes and documents of software Maintenance for resolving malfunctions, or satisfying requests for improvement or requests for compatibility to new environments. ISO / IEC 14764, JIS X 0161 Software Refers to a framework on which the parties involved in software Lifecycle development define the details of various works to prevent mutual Process misunderstanding among them. (SLCP) ISO / IEC 12207, JIS X 0160, Common Frame 2007 Information Refers to a management method of establishing, implementing, operating, Security monitoring, reviewing, and improving / maintaining information security in Management accordance with polices for avoiding business risks. ISO / IEC 27002, JIS Q 27002 Software Refers to activities for improving software or its development / maintenance Engineering work, through using theories, methods, and software development or maintenance expertise. SWEBOK2004 (ISO / IEC TR 19759) 111 5.5.3. Functional / Non-functional Requirements for Development Tools Development Tools consist mainly of an IDE used for upgrading or functionally enhancing software, and test tools for automatically testing application-programs under development. Functional Requirement 1 Additional Capability of debugging programs source codes 2 Additional Capability of assisting source-code-refactoring in a case where object-oriented languages are used 3 Additional Capability of, in coordination with test tools, automatically executing tests and automatically generating templates of test-programs suitable for test targets in a case where object oriented languages are used 4 Additional Capability of automating code-generation processes in coordination with build-tools 5 Additional Capability of assisting team-development through the coordination with the configuration management / version management tools 6 Additional Availability of stand-alone development terminals in a local environment or alternatively, a team environment which allows access to the resources of the development environment through network connections 7 Additional Capability of coordinating with configuration / version management tools 8 Basic Capability of compiling source-codes to binary codes, and packaging the compiled codes 9 Additional Capability of automating build-work or preparing scripts for build-work, for the purpose of improving quality and productivity Non-functional Requirement (write only when individually required) Compatibility Basic Version-level-compatibility with the languages such as [C#, Java, C++, etc.], and the development frameworks such as [OSS such as Struts, Turbine, Spring, Hibernate, Seasar2, etc., or compatible commercial products], used in the development phase Related Technologies Development C# JIS X 3015 2006, ISO / IEC 232702006 Language JAVA TRX X 0005-1: 2006 COBOL85 JIS X 3002. 1992, ISO / IEC 1899: 1985 COBOL2002 ISO / IEC 1989: 2002 FORTRAN77 JIS X 3001:1982, ISO / IEC 1539: 1980 FORTRAN90 JIS X 3001. 1994, ISO / IEC 1539: 1997 FORTRAN95 JIS X 3001-1: 1998, ISO / IEC 1539: 1997 C++ JIS X 3014: 2003, ISO / IEC 14882: 2003 C JIS x 30102003, ISO / IEC 9899: 1999 Development Apache Struts (1.2.x, 1.3.x.), Apache Struts2 (2.0.x.): Application Framework framework designed based on MVC design Jakarta Turbine: Application framework based on servlet. Version 2.3.x. and its derivatives are mainly used. Spring 2.5.x: Application framework composed by small components framework Hibernate 3.3.x: Object-Relation Mapping framework 112 5.5.4. Functional / Non-functional Requirements for Configuration / Version Management Tools The Configuration / Version Management tool manages modifications on the following in the entire system life-cycle, from development to abolishment, through the collective management: all information of the configuration items (CI) used in the system; hardware configurations; and versions of application-source / execution files. Functional Requirement 1 Additional Capability of recording all information on modifications on the configuration items (CI) used in the system — including why, what, and by whom the modifications were executed, through the coordination with back-tracking tools 2 Basic Capability of centrally managing versions of the entire system 3 Basic Capability of simultaneously allowing more than one vendor to implement the modifications, and merging differences in any revisions resulted from such parallel development 4 Basic Authentication function for prohibiting non-authorized users from system access 5 Additional Capability of permitting checking-in or checking-out, in coordination with the integrated development environment (IDE) included in the maintenance tool 6 Additional Capability of finding what and how, according to which specification-modification, files have been modified by collectively managing all the revision information preserved in the configuration management repository Non-functional Requirement (write only when individually required) Availability Additional Employment of a hardware configuration with enhanced availability by means of redundant hard-disk drives Security Basic Employment of a configuration protective against security risks such as illegal access, information leakage, or falsification of settings, etc. Performance Additional Configuration ensuring sufficient processing power satisfying the derived from predictions of performance-requirements processing-peaks or maximum number of users, etc. Expandability Basic Configuration allowing flexible performance enhancement for catching up with the expansion of target systems or the contents Back up Basic Capability of backing-up all the preserved data and the entire environment Related Technology Software Configuration Management Process Refers to activities of keeping records of changes in software configurations or configuration items throughout the software lifecycle, for the purpose of re-creating any of the situations in the past as required. ISO/IEC TR 15846 ・The chapters or sections shown below of the Operation Manual describe what mentioned is above: 3.(2){3}a Management of Source-Code Modification History, etc. (pp.49), Chapter 3 Procedures of Separated Procurement; 4(3) Source Code Related Matters (pp. 66), Chapter 4: Management of Project on Separated Procurement 113 5.5.5. Functional / Non-functional Requirements for Test Environments (Acceptance Test Environment) Test Environment (Acceptance Test Environment) refers to an environment for executing builds, integration tests, and system tests for applications produced on the development environments of contracted venders. Functional Requirement 1 Basic Capability of executing builds of program sources generated on development environments 2 Basic Capability of executing integration tests, system tests, and software validation tests 3 Basic Capability of creating and maintaining more than one environment in a physical test environment (Acceptance Test Environment) by means of creating more than one AP server, or utilization of virtual environments, etc. 4 Basic Authentication function for prohibiting un-authorized users from access Non-functional Requirement (write only when individually required) Availability Additional Employment of a hardware configuration with enhanced availability by means of redundant hard-disk drives Security Basic Employment of a configuration protective against security risks such as an illegal access, an information-leak, or a falsification of settings, etc. Performance Additional Configuration ensuring sufficient processing power satisfying the performance-requirements derived from predictions of processing-peaks or maximum number of users, etc. Expandability Basic Configuration expandability for keeping up with the expansion of target systems or contents preserved there Back up Additional Capability of backing-up all the preserved data and the entire environment 114 5.5.6. Functional / Non-functional Requirements for Test Tool The Test Tool refers to a system for testing: it consists of tools for automatically executing procedures for individual test cases, and management tools for preserving test-results in databases. Functional Requirement 1 Additional Capability of automating tests by means of automatic execution of test scripts (test cases) or test tools 2 Additional Capability of managing test-results in conjunction with test-cases through coordinating with configuration management tools 3 Additional Capability of managing, in an integrated way, information on testing such as requirements (specifications), test-cases, test-scripts, or test-results, etc. 4 Additional Capability of automatically collecting, summarizing, and analyzing test-result data generated by automatic-test tools 5 Additional Capability of allowing the Integrated Development Environment (IDE) to integrate and use the test-tools for unit-tests or function tests 6 Additional Employment of stress-test tools with a capability of generating large amounts of transactions by multiple servers, and functions for collecting test-results generated by the servers-on-test onto test-control terminals, so that functions for distributing loads, such as load balancing, are testable 7 Additional Capability of executing regression tests Non-functional Requirement (write only when individually required) Availability Additional Employment of a hardware configuration with enhanced availability by means of redundant hard-disk drives, etc. Security Additional Employment of a configuration protective against security risks such as illegal access, information leakage, or falsification of settings, etc. Performance Additional Configuration ensuring sufficient processing power satisfying the performance-requirements derived from predictions of processing-peaks or maximum number of users, etc., in addition, a hardware-software configuration with performance and functions equivalent to those of the operation-environment in the case of performance tests. Expandability Additional Configuration with flexible expandability for keeping up with the addition of test-tools or updates Back up Additional Capability of backing-up test environments and test data 115 5.5.7. Functional / Non-functional Requirements for Staging Environment The Staging Environment refers to an environment used for checking whether software modifications will cause troubles or not, such as the application of patches on OSs or software, etc. for the enhancement of security levels. Note that the Government Standards recommends that the verification of those patches should be executed on the environments such as a Staging Environment for evaluation in advance of their application to the job-operation environment. Functional Requirement 1 Additional Employment of hardware and software configuration equivalent to that of the operation (actual) environment with the equivalent functions and performance 2 Additional Capability of constructing staging environments on the basis of virtual servers and storages realized by virtualization software products, in a case where the equivalent hardware devices to those used in the operation(actual) environment are not available. In the staging environment realized in the virtual environment, the equivalent software products equivalent to those used in the operating environment shall be installed and perform the equivalent functions to those in the operating environment. 3 Additional Availability for users’ education / training of procedures inexecutable in the operation (actual) environment including updating processes 4 Additional Capability of executing performance-tests or stress-tests, etc. with same level of data or load as that of the operation (actual) environment in cases of constructing the staging environment without using virtual environments 5 Basic Implementation on a different physical environment or on a virtual environment existing on a different physical environment from the operation (actual) environment, so that evaluations of patches required in advance of the application to the operation (actual) environment, or tests by re-creations of malfunctions on the operation environment are executable. 6 Basic Authentication function for prohibiting un-authorized users from access Non-functional Requirement (write only when individually required) Availability Additional Employment of a hardware configuration with enhanced availability by means of redundant hard-disk drives Security Basic Employment of configuration protective against security risks such as illegal access, information leakage, or falsification of settings, etc. Performance Additional Configuration ensuring sufficient processing power for executing final tests estimated by clearly defining performance requirements in-advance Expandability Additional Configuration with flexible expandability for keeping up with enhancement or upgrading of operation-environment Back up Additional Capability of backing-up the entire staging environment, including backing-up the entirety of each server in the case when virtual servers are used. 116 5.5.8. Functional / Non-functional Requirements for Development LAN, Test LAN, Inter network LAN (Bridge LAN) The Development LAN and Test LAN are internal networks closed off in a building and dedicated to the maintenance environment. An Inter Network LAN (Bridge LAN) is a network to connect a Development LAN and Test LAN to the operation (actual) LAN. The government standards requires the clear separation of the maintenance environments from the operation environment. Functional Requirement 1 Basic Separation of Development LAN / Test LAN from the operation (actual) LAN by physical configurations or by VLAN, etc. 2 Additional Implementation of communication equipment such as switches or routers, at the connection points of the Development LAN or Test LAN to the operation (actual) LAN, for the purpose of blocking communications except for those between permitted terminals or servers. 3 Additional Dedication of the Development LAN, Test LAN, or Inter network LAN (Bridge LAN) for internal use without connections to external networks such as the internet. Non-functional Requirement (write only when individually required) Availability Additional Capability of redundantly installing network-equipment according to situations Security Basic Capability of controlling communications between the maintenance environment and the operation (actual) environment by means of filtering functions of routers or switches, etc. Performance Additional Configuration ensuring sufficient processing power as a test environment for the maintenance environment, by clearly defining the performance requirements in advance Expandability Basic Configuration that allows flexible enhancement of processing power for keeping up with functional enhancement or version-up of the maintenance environment Related Technology Refer to “Related Technology” in 5.15. WAN, Ministry’s internal LAN. DNS / DHCP / Proxy. 117 5.5.9. Audit Process Audit Process refers to a process for verifying / evaluating how properly the risk control is prepared / executed in accordance with the risk assessment. Auditing activities include internal audits by the internal-auditing department, and third-party audits by external organizations. Functional Requirement 1 Additional To periodically execute internal audits and external audits (third-party audits) on the operation environment, the development environment, and the test environment according to the “System-Audit Standards” prepared by the Ministry of Economy, Trade and Industry 2 Additional To confirm that proper actions have been taken according to the advice and recommendations by auditors. 3 Additional To be compatible with the “System Audit Standards” (revised on October 8, 2004), “Information Security Management Standards” (formulated on March 26, 2003), and the operational guidelines, prepared by the Ministry of Economy, Trade and Industry. 4 Basic To prepare medium-to-long term plans for system audits in order to effectively and efficiently check and evaluate information strategies and information systems for the fulfillment of business objectives. Such plans shall be approved by the person responsible for information systems belonging to the individual organization of the government. 5 Basic To prepare basic plans for system audits annually according to the medium-to-long term plan. Such plans shall be approved by the person responsible for information systems belonging to the individual organization of the government. 6 Basic To prepare individual plans for system auditing according to the medium-to-long term plan and the basic plan. Such plans shall be approved by the person responsible for information systems belonging to the individual organization of the government. 7 Additional To, give a contract to experts outside the government for a part of the audit in accordance with the situation. 8 Basic To audit according to the individual audit plan 9 Basic To confirm that the design / development / operation / maintenance of the target-system of the audit has been executed properly from the standpoint of reliability, safety, and efficiency Non-functional Requirement (write only when individually required) Independency Basic The auditor shall not have strong position of interest with the audited entity. Expertise Basic The auditor shall have the proper education and experience for auditing, and have the knowledge and expertise for auditing. Authority / Basic The authority and responsibility of the auditor shall be clearly Responsibility defined in documented rules or contract agreements. 118 Related Technology IT Internal Control Framework IT Internal Control Framework refers to an IT-based mechanism for managing, monitoring, and assuring evidence that the job-operations are, according to rules and procedures of the organization, executed without illegal activities, irregularities, mistakes, or errors,. ISO/IEC 38500:2008、COBIT(R)4.1 CORBIT (R) is a trademark of the Information System Audit and Control Association: ISACA / IT Governance Institute: ITGI). Descriptions on the contents of COBIT (R) are protected by the copyright of ITGI (R). 119 5.6. Servers 5.6.1. Definition A Server refers to a computer that provides functions, data, and services on the common platform system, etc. Because servers process requests from the terminals connected to the ministry’s internal LAN / WAN or the individual business systems and return the results of processing, the server hardware and the network, as well as its configuration, responsible for communications between servers, is required to have high reliability, availability and maintainability. Servers work for different roles (Web server, DB server, AP Server, etc.) according to the services and functions they provide. The proper configuration or placement of such different types of servers is indispensable: especially for the purpose of stable provision of services or for the preparation for the future increase in system load, the expansion / enhancement method matching the server type must be available, such as a scaling-up method (server configuration method enabling performance increase by enhancing the performance or adding the number of the CPUs, etc. into a chassis) or a scaling-out method (server configuration method enabling performance enhancement by adding a server-chassis for parallel processing). In addition, functions provided by servers are required to be allocated or configured so that a group of servers providing the individual services can, by the application of virtualization software, be implemented in a single physical server. Virtualization software, which refers to software that enables a single hardware server to run more than one virtual machine, enables more than one operating system to run on single server hardware with minimum loss of performance: the individual operation system is allocated virtual CPUs, network interfaces, and storages. (Refer to Figure 5.6-2.) Highly reliable, highly available, and highly maintainable servers, collaborating with storage mentioned in Section 5.7, are able to realize distributed processing, and are expected to be further visualized, consolidated, or integrated because of their adaptability to centralized and integrated management. Note that this subsection describes the servers installed in server rooms, and the network on the server firmware access-layer (server LAN). For the descriptions on the core edge access layer such as the ministry’s internal LAN / WAN, or the network as a whole, refer to the subsection 5.15. Function / Service of Servers Function / Service Definition Server hardware Refers to server devices to process functions or services available on the common platform system: it is required to have functions and configurations with high efficiency, reliability, availability, flexibility, and maintainability so that those functions and services work well even in a situation where operating systems, middleware, or applications are added, or changed, or the volume of information to 120 process is increased. Refers to LANs or network equipment for communication between servers on the common platform system Refers to software responsible for web-based information delivery or hardware configured for the execution of such information delivery: it provides services for saving the data such as HTML documents or images, or retrieving and arranging, and delivering such data to the client on the request from web-browsers, etc. Refers to programs that provide the services of saving and retrieving master-data or transaction data processed by the functions and services available on the common platform system, or the hardware configured for the execution of such services: it has the capability of high-speed processing of queries written in query languages. Note that the information on DB servers should be arranged so that it is available to queries made by the services or functions on the common platform system in such a way that the performance requirements (response time, throughput, capacity) are satisfied. Refers to programs that execute and manage business logics contained in the services available on the common platform system, or the hardware configured for the execution of such logics: it works for providing interfaces to web services available on the common platform system, executing business logic, managing transactions, and connecting to databases, etc. Server LAN Web Server DB Server AP Server 5.6.2. Schematic Diagram The diagram below shows the allocation of functions or services (server hardware, Server LAN, Web Server, DB Server, and AP Server) in the infrastructure configuration model. DB Server Server LAN Legacy Integration Storage Individual JobOperation Web Server Technology Domain Channel Region the Internet Remote PC AP Server Bac k (Indiv idual) Serv er ERP Server Workflow Server Application Software Region Legacy System System Linkage Common JobOperation Pers onnel and Pay ment Sy s tem Doc ument Management Sy s tem Budget Implementation Management Sy s tem (SEABIS) EAI External Linkage Operation Management Server Process Region Communication Equipment Load Balancer Load Balancer Authentic ation Serv er Minis try Web Serv er Public Web Server Portal Server Mail Server Directory Server Web-Service-Related Function Job-Operation PC Workflow BAM Minis try Mail Serv er Dev elopment Serv er Communication Equipment Server Hardware Applic ation-Core Serv ic e Information (Data) Region Tec hnic al Support Maintenance Environment DB Server DWH Server Data Exchange Server SOA-Related Functions (ESB, BPM, UDDI / Service Directory, Service Management) Application Platform Region Operation Management Security Server / Storage (AP Server, Web Server, DB Server, etc) Server Legacy System Common Element Region Figure 5.6-1: Allocation of "Server" Services or Functions in the Infrastructure Configuration Model 121 Figure 5.6-2: Virtualization of Server Environment by Virtualization Software 5.6.3. Server Hardware Functional Requirement 1 Basic Capability of allowing the following to run; an execution-basement for application programs operating on servers; and operating systems able to provide interfaces between the application programs and the execution-basement [Linux, Windows, and Commercial Unix, etc.] 2 Basic Capability of booting the operating system [Linux, Windows, and Commercial Unix, etc.] from the embedded disk-drive or an external disk-drive 3 Basic Network-equipment interfaces [Ethernet (IEEE 802.3) and RS-232C, etc.], and, in a case where connections to peripherals are required, [Serial ATA, PCI, SCSI2, SCSI3,iSCSI, SAS, Infiniband, FibreChannel, etc. 4 Additional Capability of collecting information for problem-management (including protection or detection) and providing information for that purpose, and the features of [e-mail delivery of failure point information, or failure-notification by SNMP trap, etc.] 5 Additional Capability of monitoring configuration or status-information of the server through interfaces compatible with the standard specification [SNMP or CIM, etc.] 6 Basic Operating system having a capability of providing the application programs with services and functions through APIs (Application Program Interfaces): the API shall be compatible with standardized and widely accepted specifications. 7 Basic Operating system is to be compatible with standardized and widely accepted specifications or equipped with command-utility functions based on CUI (Character-based User Interface), which is widely accepted 8 Basic A program (devise-drive program) that is able to control all the devices and executable on the operating system shall be available. 122 Non-functional Requirement (write only when individually required) Install Space Basic The following shall be included in the server chassis, when it (Chassis) is referred to: processors (CPUs), memory, main boards, internal disk-drives (not required in case of servers where no internal disk-drives are necessary), peripheral interfaces, and power supplies, etc. • A server chassis shall have a configuration of [rack-mount, blade, tor tower, etc.] • In the case of a rack-mount configuration, each server shall be installable in a 19-inch server-rack {4U} compatible with EIA (Electronic Industry Alliance) standards. • In the case of a blade configuration, up-to six blades shall be installable in a 19-inch server rack {7U} compatible with EIA standards. • In other configurations than those mentioned above, the foot-print is {190 cm W x 200 cm D x 220 cm H} and the maximum weight per unit area shall be less than {100 kg / m2}. Performance of Processors Processor Instruction-set Architecture Expandability of Processor The load capacity of an ordinary office is around 100 kg /m2. However, because the load capacity over 1,000 kg / m2 is not extraordinary for data centers, server-equipment with the weight per unit of over 1,000 kg / m2 will be purchased under the condition that it is installed in a data center. Therefore, on the application of the specifications here, especially the exemplifications in {}, pay sufficient attention, and modify the value in {}, according to the facilities where the servers will be installed. If the facilities where such equipment will be installed are not determined, use the above-mentioned load capacity of office or of data center as a reference value. Basic Sufficient power for satisfying requirements of job-operations. The processor power shall exceed {64 bit, operating frequency of 2 GHz, and 4 cores}, or satisfy the following: • The performance value in {SPECint 2006 base} shall be {30} or more. • The performance value in {SPECweb 2006 base} value shall be {5,000} or more. • The performance value in {SEPCfp 2006 base} value shall be {30} or more. Basic Executable instruction-set architecture already made public, allowing third parties to develop application. [x86, x64, IA64, POWER, or SPARC, etc.] Additional Capability of expanding processors by adding processors or upgrading the processing power, in preparation for the expected performance-enhancement requirements of the future. However, in a case where the software running on the server is required by specifications to be expandable in 123 Backup Basic Memory Capacity Basic Memory Expandability Basic Memory Availability Basic Additional Expandability of I / F transmission capacity Additional I / F Availability Additional I / F Maintainability Additional Capacity of Internal / External Disk Drive Availability of Internal or External Disk Drive Expandability of Disk Area Capacity of Power Basic performance by means of scaling-out, the expandability on the side of servers is unnecessary. Configuration that allows each of the operating systems used in the server to back-up the system or data stored in the internal or external disk drives. Sufficient memory capacity to satisfy job-operation requirements or to process data: the volume of the mounted memory shall be {4 GB} or more, or {4 GB} or more of memory per a core processor shall be mountable. Capability of expanding the memory capacity in order to satisfy the processing requirements, to {16GB} or more at maximum, except for the cases where the software running is, according to its specification, capable of expanding its processing capacity by means of scaling-out. Capability of, on the occasion of single-bit-errors, not depending on the operating system, automatically correcting the error in data without stopping hardware functioning, to continue processing Capability of, on the occasion of multi-bit-errors, not depending on the operating system, automatically correcting the error in data without stopping hardware functioning, to continue processing Capability of expanding the data-transmission capacity by means of combining more than one I / F card, etc. in a situation where the required data-transmission capacity is not attained, except for the case where the software running is specified to have a capability of expansion of processing power by means of scale-outing, the expandability of I / F transmission capacity of the server is unnecessary. Capability of automatically continuing processing by the other healthy I / O interfaces of the same type when an I / O interface is in trouble due to a failure Capability of allowing the replacement of the troubled interface during system operation, or a capability of, by means of clustering, etc., allowing the replacement of the troubled interface without stopping the services provided by the system Disk area capacity more than {100MB}, where the capacity means “physical capacity.” Basic Capability of combining more than one [disk drive, or SSD, etc.] so that it works as a single device, for the purpose of preventing a loss of data a or stop of job-operations Additional Capability of allowing the replacement of disk drives without stopping the server Basic Capability of expanding the data area up to {200 GB} maximum Basic Capability of supplying sufficient power to keep the server 124 Supply Maintainability of Power Supply Availability of Power Supply Additional Additional Availability of Power Additional Duplexing of Power Lines Additional Fault-tolerance Capability of Uninterruptable Power Supply System Maintainability of Uninterruptable Power Supply System (UPS) Battery Additional Redundancy of Hardware Module Additional Procurement Lead-Time Basic Addition of Hardware Components Additional Maintainability of OS / Middleware Additional Additional running Capability of allowing power supplies to be replaced without stopping the server. Duplex configuration of power supplies to keep supplying the necessary power even in a situation where a single power supply is in trouble due to a failure • Capability of keeping the server running for {longer than five minutes} by means of using an uninterruptible power-supply systems (UPS, etc.), in cases of problems in the power-lines such as an electricity outage • Capability of automatically putting the system in normal termination, in a situation where the abnormal state continues for longer than {five minutes} Power-line configuration of two power lines to supply power to the server for operation even in the case of maintenance / construction of the facility Capability of, even on the occasion of UPS malfunctions, continuing power supply by means of by-passing the UPS circuit, or a capability of the equivalent level of backing-up by means of a two power-line configuration, and notifying the system administrator of troubles. • Capability of self-diagnosing during running and notifying the administrator of abnormalities • Capability of sending a message to recommend battery replacement to the system administrator in advance before the system fails to continue normal operations • Capability of automatically executing battery checks every period of less than {two weeks} • Capability of raising battery alarms by an SNMP trap Configuration to enable a single or a combination of more than one hardware chassis to duplex the major components [CPU, Memory, Hard-disk Drive, Power Supply, and Fan, etc.] for the purpose of continuing job-operations in a situation of failures on a single component. Not that, in the case where such redundancy is ensured by software functions, the requirement is unnecessary. Time required for the addition of servers or implementation of new servers (Procurement Lead-Time) is less than {eight weeks} in normal situations. Capability of executing the addition of hardware components of server — specifically, [processors, memory, physical disk-drives, or peripheral interface-boards, etc.] — without stopping the server, or to have a system configuration allowing the addition of hardware components without stopping services of the system by means of clustering. The following features are for maintenance: • Down time of the system service required for the application 125 H/W Maintenance Term Green Procurement International Energy Star (Green IT) of security patches to the system is shorter than {two hours}. • Time to the expiration of maintenance / support is longer than {five} years. • Down time of the system service required for the application of correction patches is less than {two hours}. • In a situation where the service-down-time required for the application of security or correction patches is predicted to exceed {two hours}, the down time of job-operations for longer than {two hours} shall be prevented by the manual operations of allocating the job-operations to an auxiliary server in the system with a redundant server configuration such as clustering, etc. Basic Term of support for the failures of hardware composing the server longer than {five} years. Basic Compatibility with the basic polices based on the “Act on Promotion of Procurement of Eco-Friendly Goods and Services by the State and Other Entities,” — compatible with the basic policies stipulated in the “Computer” of the “Basic Policy for the Promotion of Procurement of Eco-friendly Goods” Additional Compatibility with the International Energy Star Program Related Technology Protocols for Monitoring and Control / Standard Interface Specifications for Server Management Network Interface, or Peripheral Interface EIA “Basic Policy for the Promotion of Procurement of Eco-friendly Goods” SPEC SNMP (Simple Network Management Protocol) CIM (Common Interface Model) Serial ATA, PCI, RS-232C, Ethernet (IEEE 802.3), Fiber Channel, SCSI2, SCSI3, iSCSI, FC-AL, FC-SW, and Infiniband Electronic Industries Alliance http://www.env.go.jp/policy/hozen/green/g-law/archive/bp/h19b p.pdf SPEC (Standard Performance Evaluation Corporation) SPECint, SPECfp Kernel API Standard POSIX API Standard (ISO / IEC 9945-1) Linux Standard Base Operating System Command / POSIX Command Standard (ISO / IEC 9945-2.1993 Utility Standard Information Technology, IEEE Std. 1003.2) Specifications of Battery JEMA (Japan Electrical Manufacturers' Association) Failure Notification / UPS http://www.jema-net.or.jp/Japanese/standard/ups/ Abnormality Notification Criteria, etc. for Decisions of Criteria, etc. for Decisions of Manufacturers, etc. on Manufacturers, etc. on Improvement of Performance of Electronic Computer, 126 Improvement of Performance of Electronic Computer Announcement No. 194, Ministry of International Trade and Industry, March 31 1999, Final (Complete) Amendment, Announcement No. 50, Ministry of Economy, Trade and Industry, March 29 2006 5.6.4. Server LAN Functional Requirement 1 Basic Capability of communicating based on TCP / IP 2 Basic Capability of packet-switching in the data-link layer / network layer 3 Additional Network equipment with management-interface functions 4 Additional Function of traffic-control for setting or modifying bandwidth-limitation 5 Basic Function of a fire-wall, and to be equipped with communication lines with the maximum effective-performance of {1 Gbps} or more and the maximum number of packets of {2 Mpps} or more 6 Basic Function of intrusion-detection and protection for the purpose of detecting and blocking an illegal access, with the maximum bandwidth of the connection being {1 Gbps} or wider 7 Basic Function for detecting falsification with a performance — the packet processing performance of the detector — of {2 Mpps} or more 8 Basic Function of virus-detection with a performance — the packet processing performance of the detector of {2 Mpps} or more 9 Basic Capability of configuring load balancers redundantly by means of implementing more than one load balancer; and, in a situation where a load balancer is experiencing problems, letting another pre-determined load balancer take over the sessions held by the troubled server in order to keep the users’ accesses undisturbed. 10 Basic VLAN feature for, creating virtual groups in the data-link layer independent of the physical connections: the group-creation capability of the VLAN feature is {16} or more. Non-functional Requirement (write only when individually required) Bandwidth Basic Capability of realizing the communication speed of {1 Gbps, theoretical} or higher Availability of Additional Redundancy ensured by full-duplex internal-configuration of Router / Switch routers or switches or duplexing devices Maintainability of Additional Capability of completing the update of routing information or Router firmware held in a router within {five minutes} or less, or switching the network connection to redundant equipment, so that said up-date will not disturb the job-operations. Easiness of Basic Capability of managing routers / switches via the network. In Maintenance addition, operations required in a problem situation, such as Activity of Router / deactivation of ports or re-writing of routing information are Switch Operators executable via a different network reserved for maintenance. Maximum Down Additional Down-time of the LAN in the common platform system — the Time monthly longest time-span while the LAN is not available — is {one hour} or less. 127 Average Response Time Availability of Routing Function Availability (Duplexing LAN) Basic Monthly average of node-to-node round-trip delay time (node: communication equipment or server) shorter than {100 ms}. Note that an assumption is available here that the network usage rate is within {30 %}. Additional Capability of redundantly configuring paths in the data-link / network layer Additional LANs have redundant configurations. Related Technology Communication Protocols LAN Standard Virtual LAN (VLAN) Monitoring / Control Protocols Green Procurement TCP/IP Ethernet IEEE 802.1Q SNMP(Simple Network Management Protocol) “Basic Policy for the Promotion of Procurement of Eco-friendly Goods” http://www.jkiss.or.jp/green/siryo2.pdf 5.6.5. Web Server Functional Requirement 1 Basic Capability of, in return to a request from client PCs such as web browsers, delivering the contents preserved on the Web server by HTTP or a compatible protocol; and creating and returning HTML data by executing programs 2 Basic Function of session-management for controlling log-in states or screen-transition 3 Basic Capability of, by means of IP authentication or user authentication, etc., authenticating web sites to give permissions (approval) to the sites; and collaborative authentication or permission with external directory services 4 Additional Capability of logging access-related information: IP address of the origin of access, time and date; accessed file names; destination page of link; name of the web browser used for access, or name of the OS; time consumed for processing; number of bytes received; number of bytes transmitted; and the service status code, etc. 5 Additional Capability of notification of an audit event: notifying, on a real-time basis, the administrator of an event of access-denial or non-authorized access. 6 Additional Capability of preparing audit reports: preparing summaries of log information as a report reviewable and browsable 7 Basic Capability of encrypting WWW-communication data, using protocols such as SSL or TSL, etc. — for the purpose of protection against data-spoofing, data-falsification, or spoofing) 8 Additional Capability of monitoring the services or functions provided by web servers for confirming that they are functioning normally; and, on the detection of performance degradation, notifying the integrated management tool of the problematic events, and saving data for later analysis and identification of the type and cause of problems. 128 9 10 11 Additional Capability of managing configuration information of servers through PCs placed in remote sites Basic Capability of load-balancing — collectively receiving processing requests bound for servers, managing the requests, allocating the requests to more than one server-group, and transmitting the requests to the allocated servers Basic Capability of selecting the load-balancing method from the round-robin method and the response-time-based load-balancing method; and, in either method, terminating the allocation of processing to the servers that have failed to send-back responses within a predefined response-time Non-functional Requirement (write only when individually required) Processing Power Basic Sufficient processing-power (number of requests processable per second) estimated on the basis of the assumed service-request-level and peak value of usage Server Basic Capability of enhancing processing efficiency by means of Expandability balancing the load on more than one server for multiplex-processing Server Basic Capability of executing enhancement-work — addition or Expandability enhancement of web servers — without interrupting job-operations Availability Basic Capability of, in the event of a problem on a single server, letting web-server software run on more than one server-hardware in order for the other healthy servers to take over the acceptance of requests coming after the event Service Hours Basic Capability of providing web-services during the following service hours; {from 8 a.m. to 10 p.m. on weekdays} Related Technology Mark-up Language Directory Service Dynamic Web-page Generation HTML LDAP JSP (Java Server Pages) Java Servlet ASP.NET 5.6.6. DB Server Functional Requirement 1 Basic Composed of systems that manage databases of relational-type data-representation (relational database management system) or XML database systems with a capability of handling XML data 2 Basic Capability of defining a database, accessing data, and controlling access, by executing programs written in a query language (Data Definition Language: DDL), a data manipulation language (DML), or data control language (DCL) 3 Basic Capability of transaction-processing 129 4 5 6 7 Basic Authentication and Permission: Capability of authentication and permission — by an identifier, identifying a user trying to access databases, and permitting the access when the user is authorized or denying otherwise Capability of, according to the user’s job-assignment, restricting user actions on each type of database object (table, view, or column) Basic Capability of encrypting or decrypting data that is managed and maintained in a database; and choosing encryption scheme Basic Audit: Function for auditing databases — logging the execution history of SQLs by users, notifying the management-tools, etc. of unauthorized accesses beyond the range of permission, or preparing a reviewable or browsable report summarizing the information saved in the logs Basic Performance Management: Function for managing performance — monitoring the performance indicators of server components (transaction-processing throughput, and response-time, etc.) to confirm the normal provision of services, and, on the detection of evidence of performance degradation, optimizing processes automatically or manually. Non-functional Requirement (write only when individually required) Availability Basic Configuration of one or the combination of the following to, in a case of a malfunction, automatically detect abnormalities, and resume DB accesses in {ten minutes} or shorter:; • Fault tolerant • Hot-standby • Clustering • Mirroring Processing Power Basic Sufficient processing-power to satisfy the performance requirements for databases (such as throughput or response time) Data Capacity Basic Sufficient capacity to store the data handled in the common platform system with a volume of {2 TB}. Expandability of Basic Capability of improving processing efficiency of database Processing Power access by load balancing on more than one server by multiplexing processes, or by adding computational resources inside the database server Database Basic Means for recovering the database-system and the data Fault-Tolerance handled in the data-base system in a problem situation such as the destruction of data Backup Basic Capability of online back-up Basic Capability of backing-up the difference or entirety of a table or database Additional Capability of backing-up a whole storage medium (device) Service Hours Basic Capability of providing database-functions during the following service hours; {from 8 a.m. to 10 p.m. on weekdays} 130 Related Technology DB Query Language Directory Service Data Encryption Technology SQL92 SQL99 SQL2003 XQuery Xpath LDAP DES AES RC4 5.6.7. AP Server Functional Requirement 1 Basic Capability of providing web services, based on web-service technologies such as SOAP or WDSL, etc. 2 Basic Employment of an infrastructure on which component applications made of Java components or .NET components, etc. are created and executed 3 Basic Function and interfaces for the application programs running on the AP server to connect to a database on the DB server for accessing data, 4 Basic Distributed Transaction: Capability of distributed transaction-processing — processing a data-update request involving more than one database or server, as a single transaction 5 Basic Distributed Object: Function for enabling distributed-objects — programs located in remote-servers — to exchange messages with each other 6 Basic Security: To have security functions for protecting the AP server and the applications against the following threats: • Network Spoofing (between a Web server and an AP server, between an AP server and a DB server) • Illegal Access Where the protection functions are not necessarily implemented in the AP server it is possible such network spoofing functions are realized as a function of the entire system by using functions provided by network equipment, etc.; that protection against network spoofing does not necessarily require the encryption of communication if there is no possibility of AP communication packet-flows except for those between a Web server and an AP server or between an AP server and a DB server; and that, if the accesses to APs are limited to those from a Web server by address-restriction, the requirement for protection against illegal accesses is considered to be satisfied. 7 Basic Performance Management: Capability of managing performance with functions for monitoring the performance of DB-server components (transaction-processing throughput, and response-time, etc.) to confirm the normal provision of services; and, automatically or manually, optimizing performances on the detection of signs of performance degradation. 8 Basic Capability of delivering and broadcasting application programs and services to AP servers, and activating those applications and servers into a ready-to-use state 131 9 Basic Capability of authenticating and permitting (approval) process-requests to an AP server; and executing such activities in collaboration with directory services outside the AP server. Non-functional Requirement (write only when individually required) Processing Power Basic {Average number of transactions processed per second} {30} or more. Server Multiplexing Basic Capability of improving processing efficiency by distributing (Load Balancing) processes to more than one server Function Multiplexing Basic Capability of improving the overall efficiency by creating and Threads executing more than one thread in the server (Mulithread Processing) Reliability of Basic Capability of, in a situation where the processing requests to the Request under AP server are increasing (Heavy Load), queuing requests in wait System Overload on the AP server for preventing the loss of requests Server Expansion Basic Configuration that ensures server expansion, and execution of the and Dynamic expansion while the system is running — without interrupting the Re-configuration system AP Server Basic Capability of monitoring the services and functions for confirming Availability whether they are functioning normally (Alive Monitoring); and automatically detecting and recovering from malfunctions Service Hours Basic Capability of providing services of an AP server for the following service hours; {from 8 a.m. to 10 p.m. on weekdays} Related Technology Web Service Related Technology Component Program Execution Infrastructure Database Access Technology Distributed Transaction Technology Directory Service Technology Basic SOAP WSDL Basic J2EE .NET Basic OLE DB ODBC JDBC ADO.NET Basic Java Transaction API (JTA) COM+ Basic LDAP 132 5.6.8. Preparation for Virtualization 1 Basic Capability of installing the software equivalent to that in the physical server environment, and allowing it to perform the equivalent functions in the virtualized environment composed of virtual guest servers, virtual storages, or virtual networks, realized by virtualization mechanisms 133 5.7. Storage 5.7.1. Definition Storage refers to an external memory device to store the information handled in the common platform system. The device assumed as storage in the common platform system is a hard-disk drive or tape drive. High reliability and high performance is required for storage because it is used for storing data on the requests from the terminals connected to the ministry’s internal LAN / WAN or the individual business systems. Storage must enable distributed processing through having high reliability, availability, and maintainability in close linkage with the server described in 5.6. At the same time, because storage is well controlled in an integrated way, further virtualization, consolidation, or integration will be expected. Functions and Service of Storage Function / Service Definition Disk Storage Refers to an external memory device for storing mainly the data, database, and system data handled in the common platform system: here, a hard-disk drive is assumed as storage. Tape Storage Refers to an external memory device for backing-up/ archiving / migrating / data-exchanging mainly the data, database, and system data handled in the common platform system. 5.7.2. Disk Storage Functional Requirement 1 Basic Capability of activating operating systems [Linux, Windows, or Commercial UNIX, etc.]. 2 Basic Capability of combining more than one disk drive to make it work as a single device for the prevention of data-loss or job-operation interruption in the case of a malfunction in a single drive 3 Additional Employment of a means of handling a situation of simultaneous malfunctions on more than one drive 4 Basic Space in an array device to install more than one spare disk 5 Basic Capability of access-controlling through zoning features [Fiber-channel switches], or settings on the disk-drive 6 Basic Access control function of shared storages — a capability of denying accesses from the unnecessary servers by using logical unit numbers [LUN] 7 Additional Employment of redundant configuration and sufficient capacity of power supplies for preventing service-shutdown in a situation of a malfunction on a single power supply 8 Basic Employment of an I /O interface on a storage device, such as [TCP / IP, FC, FCIP, FCoE, SCSI, SAS, Infiniband, etc.] 134 9 10 11 12 Basic Function for assisting adjustment work such as access-performance tuning inside the storage, or optimization or expansion of configuration Additional Capability of realizing malfunction management features for the proper management of storage — through the collection of information for fault detection and protection on the configuration modules (physical disk-drives, tape-drives, power supplies, cooling fans, I / O, control-devices and interfaces, cache memories, or I / O ports, etc.), using the functions owned by the storage, or operation management tools, etc. Basic Function for remote-controlling — preserving configuration information and status of the storage, sending such information to the remotely-located integrated-management system or tools, or receiving requests for configuration changes from the remote sites Additional Employment of, for the purpose of remote data-recovery, functions for saving the coherent data in a remote site to be recovered in the situation of a disaster for resuming job-operations or businesses Non-functional Requirement (write only when individually required) Availability of Basic Capability of accepting data-accesses continuously in a Array Device situation of a failure in disk drives through RAID technology, etc.; and automatically recovering data-redundancy. Maintainability of Additional Capability of adding or replacing disk-drives without Array Drive interrupting the operation of the storage Configuration Additional Capability of enabling the operating systems, which use the Change of Logical storage, to modify the configuration of the logical disk-volume, Disk Volume and add or replace logical disk-volume, without interrupting the system operation Availability of I / O Additional Interfaces [TCP/IP, FC, FCIP, FCoE, SCSI, iSCSI, SAS, or Interfaces Infiniband, etc.] of storage should have redundant configurations. Bandwidth of Basic Employment of maximum data-transmission capacity between Storage Data server and storage of {100 Mbytes / sec} or more Expandability of Additional Capability of expanding data-transmission capacity by binding Channel / Host more than one interface of the same type, for a case where Interface the required data-transmission capacity is unattainable Transmission Basic Data-transmission capacity of I / O channels or host interfaces Capacity of {100 m bytes / sec} or more. Channel / Host Interface Data Capacity Basic Sufficient capacity to store {2 TB} of data handled in the common platform system Data Volume Basic Capability of allocating an area of {1 GB} or more per user at Allocatable to maximum when users request allocation of memory-areas in User NAS or file servers, etc. Modification of Basic Capability of enabling operation systems, which use the Volume of Data storage, to dynamically enlarge the allocated memory volume Allocation of the server where the operating system is installed 135 Back-up Availability of Power Multiplexing of Power Line Fault Tolerance of Uninterruptable Power Supply System (UPS) Maintainability of Batteries in Uninterruptable Power Supply System Procurement Lead Time HW Redundancy System Performance Value Expansion of Storage Capacity Term of HW Maintenance Green Procurement (Green IT) Additional Capability, as a feature of the storage device, of making a copy of a volume, independently of the operating system. Additional • Capability of keeping the storage alive {for five minutes or longer} by using uninterruptable power supply systems (UPS), etc., in the case of failures of power lines such as a power outage • Capability of automatically putting the storage in normal termination after {five minutes} or longer have passed since the abnormal event occurred Additional Configuration of two-power-line-electricity-acceptance for holding power to keep the storage alive even during inspection / construction works Additional Capability of continuing the supply of power in the case of UPS failure by bypassing the UPS circuit; or by a configuration enabling the of two-power-line-electricity-acceptance equivalent effect to that of USP-by-passing; and notifying the system administrator of the failure. Additional Capability of making a self-diagnosis during operation; and notifying the system administrator of the detected failures. • Capability of sending a message of recommendation about battery replacement in advance before the system falls into a state unable continue the normal operations • Capability of automatically executing battery checks every {two weeks} • Capability of raising battery alarms by an SNMP trap Basic Time required for addition of storages or implementation of new storages (procurement lead-time) less than {eight weeks} in normal situations. Additional Hardware components composing a storage unit shall have redundant configurations, except for an emergency stop switch, back-boards, or a chassis, etc. Basic I / O performance value of the storage operations {larger than 10,000 SOC-1 bench mark} or equivalent. Basic Basic Basic Capability of allowing post-installation expansion of storage capacity up-to {5 TB} in total Term of warranty for failures of storage hardware is longer than {five years}. Product compatible with the basic policies based on the “Act on Promotion of Procurement of Eco-Friendly Goods and Services by the State and Other Entities” (specifically, a product compatible with the requirements stipulated in “Disk-Drive” of the “Basic Policies for the Promotion of Procurement of Eco-friendly Goods”). 136 Related Technology Technologies for Reliability Improvement of Disk Drive Storage Interface RAID, and Grid Storage Fibre Channel (FC-AL, FC-SW), SCSI, LAN (iSCSI / NAS), SAS, and Infiniband Monitoring / Control Protocol SNMP (Simple Network Management Protocol) “Basic Policy for the http://www.env.go.jp/policy/hozen/green/g-law/archive/bp/h19bp. Promotion of Procurement pdf of Eco-friendly Goods Battery Alarm Specifications JEMA (Japan Electronic Manufacturing Industry) / UPS Alarm Specification Refer to http://www.jema-net.or.jp/Japanese/standard/ups/ Criteria, etc. for Decisions of Criteria, etc. for Decisions of Manufacturers, etc. on Manufactures, etc. on Improvement of Performance of Magnetic Disk-Drive, Improvement of Announcement No. 195, Ministry of International Trade and Performance of Magnetic Industry, March 31 1999, Final (Complete) Amendment, Disk-Drive Announcement No. 51, Ministry of Economy, Trade and Industry, March 29 2006 5.7.3. Tape Storage Functional Requirement 1 Additional Employment of a redundant configuration and sufficient power-capacity for preventing failures of a single power supply from causing service-interruptions 2 Basic Employment of I / O interfaces such as [SANFC、SCSI、or SAS, etc.] 3 Basic Capability of, by using features of the storage device or operation management tools, etc., enabling malfunction-management functions for the proper management of failures through collecting information necessary for the detection and protection from failures on the configuration modules [tape-drive, power- supply, cooling-fan, control device and interface, cache memory, and I / O port, etc.] 4 Additional Function of automatically detecting or eliminating data-duplications on the occasion of data-saving Non-functional Requirement (write only when individually required) Data Bandwidth of Basic Maximum data-transfer volume between server and tape-storage Tape Storage {80 M bytes / sec} or more Channel Transfer Basic Data transfer capacity of I / O channel / host interface {100 M Capacity bytes / sec} or more. Equipment Basic Time required for the addition of storages or implementation of Lead-Time new storage procurement lead-time) shorter than {eight weeks} in normal situations.. Data-store Basic Maximum volume of data storable in the tape-storage {10 TB} or Capacity more. 137 Related Technology Storage Interface Fibre Channel (FC-AL, FC-SW), SCSI, LAN (iSCSI / NAS), SAS, Infiniband Monitoring / Control Protocol SNMP (Simple Network Management Protocol) 5.7.4. Preparation for Virtualization 1 Basic Capability of installing the equivalent software to that used in the physical environment and allowing it to function equivalently in the virtual environment composed of virtual storages and others realized by virtualization software 138 5.8. Shared PC / Office Printer 5.8.1. Definition A Shared PC / Office Printer refers to a terminal used by individuals for the purpose of accessing information systems, or executing office-work such as the preparation of documents. In this section, the computer software providing the operational environment, etc. and used by the shared PCs is referred to as the common operation-environment. Shared PCs are categorized into two ways; personal computer, stand-alone and able to access the common operation-environment; and thin-client, working as a client of a thin-client-server, able to access the common operation-environment through the thin-client-server. The items of Shared PC / Office Printer are defined as follows; Shared PC / Office Printer Item Definition Personal Computer Refers to a stand-alone terminal able to use the common-operation environment Thin-Client Refers to a terminal connected to a thin-client server, etc. Office-Printer Device Refers to a computer peripheral that prints information, etc. on sheets of paper, according to the instructions by information systems Note that a thin-client server is defined as a server that provides thin-clients with the common operation environment and accepts their connection requests through network. 5.8.2. Common Functional Requirements for a Shared PC / Office Printer The following are the common functional requirements for a Shared PC / Office Printer: Common Functional Requirement for Shared PC / Office Printer 1 Basic Accessibility via the network by terminals that are operative (Note that the requirement mentioned above should be applied to terminals operative inside the ministry building. The condition “operative” should be eliminated for the terminals that have been carried out on a business trip.) Common Non-functional Requirement for Shared PC / Office Printer Term of Basic Term of warranty for hardware components (maintenance Hardware term) is longer than {five years}. Maintenance Contract 139 Related Technology Accessibility JIS X 8341 Series ISO 9241-20 ISO / IEC 10779 5.8.3. Functional / Non-functional Requirement for a Personal Computer Functional Requirement 1 Basic Capability of using the common operational-environment 5.8.3.1. Desk-top Computer Non-functional Requirement (write only when individually required) Performance Basic Operating frequency of CPU higher than {1.0} GHz. On-chip cache memory shall have a capacity larger than {4} MB. Capability of execution of more than {two} threads simultaneously. Basic Employment of internal memory for main memory of a volume larger than {1} GB Basic Employment of an internal disk-drive of a capacity larger than {80} GB Expandability Basic Employment of more than {one} LAN port compatible with 1000 BASE-T, 100 BASE-TX, and 10 BASE-T embedded Basic Employment of more than {three} USB 2.0 ports embedded Basic Keyboard connected through PS2 or USB. Additional Modem functions unavailable to an isolated — stand-alone — personal computer. Size Basic Body / keyboard, etc. fitting in a space (referred to as “body size”) of {60} cm wide, {40} cm high, {40} cm deep; and with a weight less than {10} kg. Display Basic Screen size of {14} inches — {35.56} cm — or more with a resolution of {1024} pixels or more in horizontal direction, and {768} pixels or more in vertical direction. [Conventional-type screen] Aspect ratio — width: height — of 4:3 or 5:4 [Wide-type screen] Aspect ratio of 8:5 or 16:9 Security Additional Capability of attaching a theft-protection lock or wire Additional Feature of BIOS password lock Additional Feature of hard-disk password lock Green Basic Compatibility with the basic polices of the “Act on Promotion of Procurement Procurement of Eco-Friendly Goods and Services by the State (Green IT) and Other Entities,” — compatible with the basic policies stipulated in the “Computer” of the “Basic Policy for the Promotion of Procurement of Eco-friendly Goods” 140 Basic Procurement of products compatible with the International Energy Star Program (Ver. 5.0), notified to the government lead office, and registered Internal Drive Additional Employment of an internal DVD super multi double drive (compatible with DVD-R {8x speed} or faster, DVD-RW {4x speed} or faster, CD-R {24x speed} or faster, or CD-RW {10x speed} or faster, or a capability of attaching such a drive externally Mouse Additional Employment of a USB connectable two-button optical mouse with scrolling feature and 400-count resolution or finer Key-Board Basic Bundling with the following features: JIS Standard Key-Arrangement (109 key), or OADG-compatible (109 key) or equivalent; Connectable to the PC through PS2 or USB 5.8.3.2. Note-Book Computer Non-functional Requirement (write only when individually required) Performance Basic Operating frequency of CPU shall be higher than {1.0} GHz. Cache memory on the chip shall have a capacity larger than {4} MB. Execution of more than {two} threads simultaneously. Basic Employment of internal memory of a volume larger than {1} GB, used as main memory Basic Employment of an internal disk-drive of a capacity larger than {80} GB Expandability Basic Employment of more than {one} LAN port compatible with 1000 BASE-T, 100 BASE-TX, and 10 BASE-T embedded Basic Employment of more than {two} USB 2.0 ports embedded Additional Unavailability of modem functions to an isolated — stand-alone — client PC. Size Basic Body / keyboard, fitting in a space (referred to as “body size”) of {60} cm wide, {5} cm high, and {40} cm deep, with a weight less than {5} kg. Display Basic Screen size of {14} inch — {35.56} cm — or more with a resolution of {1024} pixels or more in horizontal direction, and {768} pixels or more in vertical direction. Availability Additional Drip-proof Security Basic Capability of attaching a theft-protection lock or wire Additional Feature of BIOS password lock Additional Feature of hard-disk password lock Battery Additional Operability for more than {two} hours measured according to Capacity JEITA Battery Operation Hour Measurement Method 141 Green Procurement (Green IT) Basic Basic Drive Mouse Key-Board Compatibility with the basic polices based on the “Act on Promotion of Procurement of Eco-Friendly Goods and Services by the State and Other Entities,” — compatible with the basic policies stipulated in the “Computer” of the “Basic Policy for the Promotion of Procurement of Eco-friendly Goods” Compatibility with the International Energy Star Program (Ver. 5.0), notified to the government lead office, and registered Additional Employment of an internal DVD super multi double drive (compatible with DVD-R {8x speed} or faster, DVD-RW {4x speed} or faster, CD-R {24x speed} or faster, or CD-RW {10x speed} or faster, or capability of attaching such a drive externally Additional Employment of a USB connectable two-button optical mouse with scrolling feature and 400-count resolution or finer Basic JIS Standard Key-Arrangement (87 key), or OADG-compatible (86 key) or equivalent, embedded in the body of the computer 5.8.3.3. Portable Note-Book Computer Non-functional Requirement (write only when individually required) Performance Basic Operating frequency of CPU higher than {1.0} GHz. Cache memory on chip with a capacity larger than {4} MB. Capability of executing more than {two} threads simultaneously. Basic Employment of internal memory of a volume larger than {1} GB, used as main memory Basic Employment of an internal disk-drive with a capacity larger than {80} GB Expandability Basic Employment of more than {one} LAN port compatible with 1000 BASE-T, 100 BASE-TX, and 10 BASE-T embedded Basic Employment of more than {two} USB 2.0 ports embedded Additional Unavailability of modem functions by an isolated — stand-alone — client PC. Size Basic Size containing the body / keyboard, etc. in a space (referred to as “body size”) of {40} cm wide, {5} cm high, and {40} cm deep, with a weight less than {5} kg. Display Basic Employment of a display with a resolution of {1024} pixels or more in horizontal direction, and {768} pixels or more in vertical direction. Availability Additional Drip-proof Additional Capability of attaching a theft-protection lock or wire Security Additional Feature of BIOS password lock Additional Feature of hard-disk password lock Battery Additional Operability of more than {two} hours measured according to Capacity JEITA Battery Operation Hour Measurement Method 142 Green Procurement (Green IT) Drive Mouse Key-Board Basic Compatibility with the basic polices based on the “Act on Promotion of Procurement of Eco-Friendly Goods and Services by the State and Other Entities,” — compatible with the basic policies stipulated in the “Computer” of the “Basic Policy for the Promotion of Procurement of Eco-friendly Goods” Basic Procurement of products compatible with the International Energy Star Program (Ver. 5.0), notified to the government lead office, and registered Additional Employment of an internal DVD super multi double drive (compatible with DVD-R {8x speed} or faster, DVD-RW {4x speed} or faster, CD-R {24x speed} or faster, or CD-RW {10x speed} or faster, or a capability of attaching such a drive externally Additional Employment of a USB connectable two-button optical mouse with scrolling feature and 400-count resolution or finer Basic A keyboard having the following features: JIS Standard Key-Arrangement (85 key), or OADG-compatible (85 key) or equivalent Related Technology Hardware OADG Technical Reference (Hardware) Power Saving International Energy Star Program (Ver. 5.0) Peripheral USB 2.0 Connection Display Analog RGB (D-Sub 15 pins), DVI-D, HDMI, Display Port Connection Wired LAN 1000 BASE-T / 100 BASE-TX / 10BASE-T Wireless LAN IEEE 802. 11 a / b / g / n Bluetooth Bluetooth 2.1+EDR 5.8.4. Functional / Non-functional Requirements for Thin-Client / Thin-Client Server 5.8.4.1. Thin-Client A Thin-client refers to a terminal that uses functions belonging to the other systems on the network for a part of its functions executed by its configuration items. In some types of thin-clients, only the storage function is executed on the network, and in other types, the entire processing excluding screen-display-processing or user-key-entry processing, is executed by a server on the network. Functional Requirement 1 Basic Capability of connecting to thin-client servers 2 Basic Capability of using the common operation environment through functions on the server — in some cases, some of the features of the client might 143 3 help Basic Employment of no recordable medium — hard-disk drive, etc. — embedded in the body and available to users 5.8.4.2 Thin-Client Server Thin-client server refers to a server that provides the common operation environment, and accepts, via the network, connection requests to the environments from thin-clients. The configurations of a thin-client server are categorized in a configuration where a single OS instance accepts more than one session, a configuration where a virtual machine is created for each session, and a blade configuration where an individual hardware is assigned to an individual session. Functional Requirement 1 Basic Capability of accepting accesses from personal computers or from thin-clients 5.8.5. Definition of the Common Operation Environment The Common operation environment refers to a system composed of software that executes hardware management, application execution, and file manipulation. The environment is available to personal computers or thin-clients. The following are functions and services of the common operation environment. Common Operation Environment Function / Service Definition OS Through working operations of the system, executes the fundamental functions, such as the management of resources — CPU or memory, etc. — or the management of accesses to such resources, etc. Virus Protection To periodically scan memory devices to detect virus infections, continuously monitor inputs / outputs of files or communications on the network, and to take the necessary actions such as virus-cleansing on the detection of virus infections Web Browser Web browser refers to a program for browsing the WWW. Personal Fire-wall Quarantine To monitor inbound or outbound communications and give permissions only to the communications from authorized applications Image Processing To create or modify images Document Creation To create or modify documents Presentation To create or modify slides for presentation Spreadsheet To create or modify tables, or to execute calculations 144 Mail Client Viewing Video Web Page Creation Creation of Electric Printed Document Command-line Environment Japanese Character Input (Kana-Kanji Conversion) Reception of Software Collection of Inventory Information Encryption Protection against Information Leakage on tables To send or receive electronic mails To view video files To edit HTML and post on a web site To create an electronic printed document through virtual printers using the application print function To execute file-manipulation or configuration-modification using command-lines or batch-processing Conversion of Japanese characters entered by the alphabet-entry-method or kana-entry-method, to kanjis Function for receiving software or corrections delivered from the software management server To create a list of software, correction programs, signatures of anti-virus software, or user-saved files, etc. installed in the terminal and send it to the server To encrypt the system, files, or passwords, etc. To restrict copying and delivering information via USB memory devices, etc. Related Technology Web Browser HTTP, FTP, SSL/TLS, Java Script HTML 4.1 Document ISO/IEC 26300 Open Document Format (ODF) Creation, ISO/IEC 29500 Office Open XML Format (OOXML) Presentation, Spreadsheet Still Image JPEG, GIF, PNG Video MPEG-1, MPEG-2, MPEG-4/H.264, SMPTE VC-1 Printed Adobe Portable Document Format Version 1.7 (PDF) Document ECMA-388 XML Paper Specification (XPS) Document ZIP Compression 5.8.5.1. Functional / Non-functional Requirements for OS OS, through working operations of the system, has the role of executing the fundamental functions, such as management of resources — CPU or memory, etc. — or management of accesses to such resources, etc. Functional Requirement 1 Basic Capability of collecting CPU utilization on a real-time basis 2 Basic Capability of collecting usage rates of physical hard-disk drives 3 Basic Capability of collecting information on input / output performance of physical hard-disk drives 145 4 5 6 7 8 9 10 11 12 13 14 15 Basic Capability of collecting information on free space in physical memory devices Basic Capability of collecting information on free space in virtual memory devices Basic Capability of collecting information on the number of processes in the active state simultaneously Basic Capability of collecting the utilization of CPU and usage rate of virtual memory devices for each process Basic Capability of collecting input / output information on network interface cards Basic Capability of recording and monitoring system events Basic Capability of monitoring the statuses of services (daemon processes) active on the OS Basic Capability of preserving data for a term sufficient for internal control audits Basic Capability of allowing usage in multi-user mode (ordinary users and administrators, etc.) Basic Capability of browsing device information [CPU, memory, physical disks, logical disks, MAC address, and external devices, etc.] Basic Capability of browsing information on installed software Basic Capability of browsing information about the OS [OS, version, computer name, and network information such as IP address, etc.] Non-functional Requirement Back-up Basic Capability of saving collected data into external storage devices according to the situations in such a way that it can be recovered at any time required 5.8.5.2. Functional / Non-functional Requirements for Virus Protection The Virus protection function periodically scans memory devices to detect viral infections, continuously monitors inputs / outputs of files or communications on the network, and, on the detection of viral infections, takes necessary actions such as virus-cleansing. Refer to 5.9.7.1 for the requirements. 5.8.5.3. Functional / Non-functional Requirements for Web Browser The Web browser has functions for browsing the WWW. Refer to 5.9.7.2 for the requirements. Functional Requirement 1 Basic Capability of having communications with web servers to obtain information from the designated URL 2 Basic Capability of displaying the web contents created by using only the functions compatible with the W3CHTML Standard and the ECMA Script Specifications, and accepting inputs through input forms 3 Basic Capability of displaying images with the data-format of JPEG, GIF, or Adobe Flash 146 4 5 6 7 Basic Basic Basic Basic Capability of controlling automatic data-downloading Capability of controlling pop-up windows Capability of controlling access to the URLs of phishing sites Capability of selecting encoding 5.8.5.4. Functional / Non-functional Requirements for Firewall Quarantine A Firewall has a capability of monitoring inbound and outbound communications to permit only the communications from the authorized applications to pass. Functional Requirement 1 Basic Capability of controlling communications to permit or deny access according to port numbers 2 Basic Compatibility with both of the protocols of IPv4 and IPv6 3 Basic Capability of saving logs Non-functional Requirement Performance Basic Capability of continuing processing normally on the receipt of a large amount of packets Availability Basic Not to lose functioning due to piled-up logs 5.8.5.5. Functional Requirements for Image Processing Image Processing has functions for creating or editing images. Images here refers to images built in a format compatible with one of the standard formats mentioned in the sections relating to standard formats. Functional Requirement 1 Basic Capability of reading image files 2 Basic Capability of creating images 3 Basic Function of image-editing such as [cut, copy, paste, edit-color, and scaling, etc.] 5.8.5.6. Functional Requirements for Document Creation Document Creation has functions for creating or editing a document. Functional Requirement 1 Basic Capability of creating a document 2 Basic Capability of editing a document, such as [cut, copy, paste, or edit-color, etc.] 3 Basic Capability of starting addition from any line in the document without a sequence of operations for changing lines 4 Basic Capability of creating, reading or editing a document written vertically 5 Additional Capability of reading image files 6 Additional Capability of saving a document in a standard format 5.8.5.7. Functional Requirements for Presentation Presentations have functions for creating or editing slides. 147 Functional Requirement 1 Basic Capability of creating a slide 2 Basic Capability of editing a slide, such as [Cut, copy, paste, or edit-color, etc.] 3 Basic Capability of executing a slide show 4 Additional Capability of reading image files 5 Additional Capability of reading audio files 6 Additional Capability of reading motion-image files 7 Additional Capability of saving a slide in a standard format 5.8.5.8. Functional Requirements for Spreadsheets Spreadsheet has functions for creating, calculating, or editing a table. Functional Requirement 1 Basic Capability of creating a table 2 Basic Capability of calculating a table (including applications of mathematical operators or basic functions) 3 Basic Capability of editing a table, such as [cut, copy, paste, edit-color, or insert / delete line, etc.] 4 Basic Capability of creating a graph from data in a table 5 Basic Capability of editing a graph, such as [setting of an axis, etc., or edit-color, etc.] 6 Additional Capability of reading image files 7 Additional Capability of saving a sheet in a standard format 5.8.5.9. Functional Requirements for Mail Clients A Mail Client has functions for sending or receiving electronic mail messages Functional Requirement 1 Basic Capability of having connections through protocols commonly used in mail servers (SMTP, POP3, and IMAP) 2 Basic Capability of full-text-searching mails using a combination of sender name, address (destination), title, body, and date 3 Basic Capability of setting of mail-transfer 4 Basic Capability of setting a notice of absence 5 Basic Capability of controlling the automatic downloading of images to be displayed in the body of an e-mail for the purpose of protecting against web beacons, 6 Basic Capability of encrypting data saves locally 7 Basic Capability of blocking attached-files with a file-extension raising suspicion of virus infection 8 Basic Capability of encrypting mail body or attachment files and restricting available functions for the mail (printing, etc.) 9 Basic Capability of applying SMTP authentication 10 Basic Capability of displaying an address book using LDAP 11 Basic Capability of auto-complete function for address, such that a part of address entered is automatically completed 148 12 13 14 15 16 17 18 19 20 21 22 Basic Capability of using encrypted mailboxes or address books Basic Capability of accepting and responding to a mail requesting a read receipt Basic Function for reading an HTML mail in text or rich-text format Basic Capability of displaying an HTML mail without help help of browsers Basic Function for filtering out SPAM mails Basic Capability for allowing a user to easily know whether a mail has an attachment or not Basic Capability of sorting a mail into folders according to a pre-defined character string included in the mail-body or title, or sender information, etc. Basic Capability of sorting mails in order of title, date, or sender, etc. Basic Capability of exporting a mail message in a text format or in other commonly used format Basic Capability of exporting or importing an address-book in CSV format or another commonly used format such as vCARD Basic Capability of optimizing a mail box 5.8.5.10. Functional Requirement for Viewing Video Viewing Video has a function of viewing video files. Functional Requirement 1 Basic Capability of viewing video and still images, and playing audio compatible with MPEG1, MPEG2, and MPEG4 5.8.5.11. Functional Requirements for Web Page Creation Web Page Creation has a function for creating and editing HTML pages, and posting them on web sites. Functional Requirement 1 Basic Capability of editing a HTML page 2 Basic Capability of posting a HTML page on a web site 5.8.5.12. Functional Requirements for the Command-Line Environment The Command-Line Environment has functions for manipulating files or modifying settings through command lines or batch processes. Functional Requirement 1 Basic Capability of manipulating files or modifying settings through command lines 2 Basic Capability of batch-processing 5.8.5.13. Functional Requirements for Japanese Character Entry (Kana-Kanji Conversion) Japanese Character Entry has functions for entering Japanese characters by the alphabet-entry method or the kana-entry method, and converting them to kanji. 149 Functional Requirement 1 Basic Employment of the basic functions necessary for entering Japanese words, such as consecutive clause conversion, learning features, and alphabet / kana entry, etc. 2 Basic Function for converting a word to kanji 3 Basic Capability of entering at least the JIS X 0208 Character-set 4 Additional Capability of showing differences of meaning or example sentences for homonyms 5 Additional Function for assisting conversion of zip code to addresses, and entry of date 5.8.5.14. Functional Requirements for the Receipt of Delivered Software The Receipt of Delivered Software has functions for receiving software and correction programs delivered by the software-management server. Functional Requirement 1 Basic Capability of receiving software and correction programs (including virus-pattern files) 2 Basic Capability of confirming the results of the installation of the received software and correction programs 3 Basic Capability of, in a case where restarting the computer after the completion of receiving and installing is required, displaying a prompt-message requesting restart, to a user working at the display 4 Additional Capability of suppressing or hiding GUI displays while installing received software or correction programs in order to avoid disturbance to a user working at the display 5 Additional Capability of allowing ordinary installers to execute set-up jobs 5.8.5.15. Functional Requirements for Collection of Inventory Information Collection of Inventory Information has functions for creating and sending to the server, a list of software installed in the terminal, correction programs, signature files of anti-virus software, and user-saved files. Functional Requirement 1 Basic Capability of creating and sending to the server, a list of software installed in the terminal, correction programs, signature files of anti-virus software, and user-saved files 5.8.5.16. Functional / Non-functional Requirements for Encryption Encryption has functions for encrypting a file or a password, etc. Functional Requirement 1 Basic Capability of automatically encrypting a hard-disk and managing it by the decryption key, collectively in collaboration with the authentication authority 2 Basic Capability of encrypting file by file, in collaboration with the authentication authority 150 3 4 5 Basic Capability of encrypting folder by folder, in collaboration with the authentication authority Basic Capability of executing encryption / decryption by a simple operation Basic Capability of easily encrypting a file when stored in an external medium Non-functional Requirement Back-up Basic Capability of recovering an encrypted file with a backed-up decryption key in a situation of a failure of the terminal where the encryption was executed 5.8.5.17. Functional Requirements for Protection against Information Leakage Protection against Information Leakage has functions for protecting information against leakage. Functional Requirement 1 Basic Capability of controlling access to classified documents (review, print, or up-date, etc.) on a file-by-file basis in collaboration with the authentication authority 2 Additional Capability of inhibiting the making copies onto external devices such as USB memory devices 3 Additional Capability of inhibiting transmission or transfer, etc. of files attached to an e-mail, in collaboration with the authentication authority 151 5.8.6. Functional / Non-functional Requirements for an Office Printer Device An Office Printer Device refers to a printing device installed and used in an office environment. Among them, a printer that is shared, works as a data-processing machine and has no other functions than printing characters, graphics or photos, etc. onto sheets of paper is defined as an office printer; a printer that is dedicatedly connected to an individual PC is defined as a small printer; and a printer that, in addition to functions for printing, has functions of copy machine, scanner, or fax-machine, etc. is defined as a multi-functional printer. 5.8.6.1. Functional / Non-functional Requirements for Printer A Printer refers to a printing device that is shared, works as a data-processing device, and records characters, graphics, or photos, etc. on paper. Functional Requirement 1 Basic Capability of printing data on a sheet of paper according to instructions from a terminal 2 Basic Capability of sorting pages and stapling, in the case of printing a multiple-page document 3 Additional Capability of, by electronic means, sorting pages, or collating pages, etc. in the case of printing more than one copy of document 4 Basic Printing options, independent of the style of a document, for printing multiple pages on a single page (n-up printing, both-side-printing, or monochrome-printing, etc.) in the case of making more than one copy of a document 5 Selectable No limitations on printing functions or options available for thin-clients (sheet selection, number of copies, both-side-printing, page-arrangement in book style, or sorting, etc.) 6 Additional Function for restricting network band-width available for print-data transmission Non-functional Requirement (write only when individually required) Printing Basic Capability of printing {30 pages in monochrome, or 30 pages in Speed color} or more A4 pages per minute Sheet Size Basic Capability of printing a sheet up-to the {A3, A4} size Color Selectable Capability of {multi-color / color} printing Printing Basic Capability of printing with a resolution equivalent to {1200} dpi or Resolution finer Printing Basic Employment of laser printing, LED printing, ink-jet printing or 152 Method Maximum Basic Power Consumption Size Basic Weight Power Basic Basic Tray Capacity Interface Basic Basic Basic Security Additional Additional Additional Additional Management Additional Additional Additional Additional Green Procurement (Green IT) Basic Basic Additional sublimation / thermal transfer printing Less than {2.0 K} W Size, excluding attachments, smaller than {1,200} mm wide x {1,000} mm deep, and {1,500} mm high Weight, excluding attachments, of lighter than {300} kg Requirement of no other special power arrangement than ordinarily available (AC 100 V, 50 / 60 Hz compatible, maximum power of 1.5 kW or less per an outlet, in Japan) Capability of using an auto sheet-feeder and feeding {500} sheets or more Employment of an interface of standard parallel or USB connection, or both Employment of interfaces (10BASE-T, 100BASE-TX, or 1000BASE-T, etc.) for connecting to information systems Capability of restricting the taking-out of printed sheets Capability of restricting the receipt of data (printing) using IP addresses Capability of authentication for access to setting information Capability of deleting print-data saved in the equipment in order to prevent the data from being re-used Capability of confirming or modifying settings remotely Function for the realization of an integrated management method including status-monitoring or settings, or page-count management or monitoring of multiple devices Capability of restricting available functions by user groups [color-printing] Capability of installing driver programs through a single install program Product compatible with the basic policies based on the “Act on Promotion of Procurement of Eco-Friendly Goods and Services by the State and Other Entities” (specifically, a product compatible with the requirements stipulated in “Printer” of the “Basic Policy for the Promotion of Procurement of Eco-friendly Goods”). Product compatible with the International Energy Star Program, notified to the government lead office, and registered Eco-mark certified product 5.8.6.2. Functional / Non-functional Requirements for Small Printers A Small Printer refers to a printing device that is dedicatedly used and prints characters, graphics, or photos, etc. onto sheets of paper. 153 Functional Requirement 1 Basic Capability of printing data on a sheet of paper according to instructions from a terminal 2 Basic Printing options, independent on the style of documents, for printing multiple pages on a single page (n-up printing or monochrome-printing) in the case of printing a document 3 Additional Printing options, independent on the style of documents, for printing two pages on the both sides of a sheet in the case of printing a document 4 Selective No limitations on printing functions or options available for thin-clients (sheet selection, number of copies, etc.) 5 Additional Function for restricting network band-width available for printing data Non-functional Requirement (write only when individually required) Printing Basic Capability of printing {10 pages in monochrome, or 10 pages in Speed color} or more A4 pages per minute Sheet Size Basic Capability of printing a sheet up-to the {A3, A4} size Color Selectable Capability of multi-color / color printing Printing Basic Capability of printing with a resolution equivalent to {1200} dpi or Resolution finer Printing Basic Employment of laser printing, LED printing, ink-jet printing or Method sublimation / thermal transfer printing Maximum Basic Less than {30} w for a portable type, or {450} w for a stationary Power type Consumption Size Basic Size, excluding attachment, smaller than {350} mm wide x {180} mm deep, and {85} mm high for a portable type, and {450} mm wide x {450} deep x {450} high for a stationary type Weight Basic Weight, excluding attachments, lighter than {2.2} kg for a portable type, and {20} kg for a stationary type Power Basic Requirement of no other special power arrangement than ordinarily available (AC 100 V, 50 / 60 Hz compatible, maximum power of 1.5 kW or less per an outlet, in Japan) Additional Capability of operating using AC (100-240)V. Power plugs compatible with the receptacles used in other countries should be available Tray Basic Capability of using an auto sheet-feeder and feeding {30} sheets Capacity or more Interface Basic Employment of an interface of standard parallel or USB connection, or both Additional Employment of interfaces (10BASE-T, 100BASE-TX, or 1000BASE-T, etc.) for connecting to information systems Security Additional Capability of restricting receipt of data (printing) using IP addresses Additional Capability of deleting print-data saved in the equipment in order to prevent the data from being re-used 154 Management Additional Additional Green Procurement (Green IT) Basic Basic Additional Function for the realization of an integrated management method including status-monitoring or settings, or page-count management or monitoring of multiple devices Capability of installing driver programs through a single install program Product compatible with the basic policies based on the “Act on Promotion of Procurement of Eco-Friendly Goods and Services by the State and Other Entities” (specifically, a product compatible with the requirements stipulated in “Printer” of the “Basic Policy for the Promotion of Procurement of Eco-friendly Goods”). Product compatible with the International Star Program, notified to the government lead office, and registered Eco-mark certified product 5.8.6.3. Functional / Non-functional Requirements for Multi-Functional Printers A Multi-Functional Printer refers to a device that has the functions of a copy-machine, a scanner, and a fax-machine, in addition to printer functions. Furthermore, it is able to save an original as an electronic image. Functional Requirement 1 Basic Capability of printing data on a sheet of paper according to instructions of a terminal 2 Basic Capability of making a photo-copy of a paper document 3 Basic Capability of sorting pages and stapling, in case of printing a multiple-page document 4 Basic Capability of scanning a document and storing it as an electronic-data file 5 Basic A combined machine with fax-functions connectable to a telephone, with a capability of sending or receiving facsimile signals. 6 Basic Capability of temporarily saving electronic copies of an original, scanned or sent, to retrieve, read, or be deleted later by manual operation 7 Basic Printing / copying options, independent on the style of a document, for printing / copying multiple pages on a single page (n-up printing, both-side-printing, or monochrome-printing, etc.) in the case of making more than one copy of a document 8 Selective No limitations on printing functions or options available for thin-clients (sheet selection, number of copies, both-side-printing, page-arrangement in book style, or sorting, etc.) 9 Additional Function for restricting network band-width available for print-data transmission Non-functional Requirement (write only when individually required) 155 Printing Speed Sheet Size Color Printing Resolution Printing Method Maximum Power Consumption Size Weight Power Tray Capacity Copy Function Automatic Document Feeder Fax Functions Scanning Function Basic Capability of printing {30 pages in monochrome, or 30 pages in color} or more A4 pages per minute Basic Capability of printing a sheet up-to the {A3, A4} size Selectable Capability of {multi-color / color} printing Basic Capability of printing with a resolution equivalent to {1200} dpi or finer Basic Employment of laser printing, LED printing, ink-jet printing or sublimation / thermal transfer printing Basic Less than {2.0 K} W Basic Size, excluding attachments, smaller than {1,200} mm wide x {1,000} mm deep, and {1,500} mm high Basic Weight, excluding attachments, lighter than {300} kg Basic Requirement of no other special power arrangement than ordinarily available (AC 100 V, 50 / 60 Hz compatible, maximum power of 1.5 kW or less per an outlet, in Japan) Basic Capability of using an auto sheet-feeder and feeding {500} sheets or more Selectable Capability of selecting color / monochrome copying Basic Basic Basic Basic Basic Basic Basic Basic Interface Basic Basic Security Additional Additional Additional Additional Capability of automatically feeding a document consisting of more than one page (single-sided, double-sided, different sized), in the case of scanning, facsimile-sending, or copying Capability of registering or managing the fax-destination phone numbers Capability of attaching scanned-data files to an e-mail Capability of storing scanned-data files into private folders or shared folders on the network Capability of viewing, loading or deleting the tentatively saved data by operations on terminals through the network Capability of selecting color-scan, or monochrome-scan Capability of scanning with a pre-defined resolution [200dpi, 400dpi, or 600dpi, etc.] Capability of selecting a format for saving scanned data (PDF, XPS, JPEG, or TIFF, etc.) Employment of an interface of standard parallel or USB connection, or both Employment of interfaces (10BASE-T, 100BASE-TX, or 1000BASE-T, etc.) for connecting to information systems Capability of restricting the taking-out of printed sheets Capability of restricting the receipt of data (printing) using IP addresses Capability of authentication of access to setting information Capability of deleting [copy, fax, scan, or print, etc.] data saved in the device, in order to prevent the data from being re-used 156 Management Additional Additional Additional Additional Green Procurement (Green IT) Basic Basic Additional Capability of confirming or modifying settings remotely Function for realization of an integrated management method including status-monitoring or setting, or page-count management or monitoring of multiple devices Capability of restricting available functions [copy, fax, scan, or print data, etc.] by user groups Capability of installing driver-programs through a single install program Product compatible with the basic policies based on the “Act on Promotion of Procurement of Eco-Friendly Goods and Services by the State and Other Entities” (specifically, a product compatible with the requirements stipulated in “Copy Machine” of the “Basic Policy for the Promotion of Procurement of Eco-friendly Goods”). Product compatible with the International Energy Star Program, notified to the government lead office, and registered Eco-mark certified product 5.8.7. Preparation for Virtualization Functional Requirement (Preparation for a virtualized environment) 1 Basic Capability of installing the software equivalent to that in the physical server environment, and allowing it to perform the equivalent functions in the virtualized environment composed of virtual guest servers, virtual storages, or virtual networks realized by virtualization mechanisms 157 5.9. Operations Management/Security Operations management represents the activities needed to maintain unerring control of the environment, thus enabling the various systems running, mainly on computers, to provide various services to their users without interruption that may be triggered by unexpected external causes. Security refers to the construction and maintenance of environments that safeguard information assets from internal/external threats, such as viruses or unauthorized access, thus ensuring a safe and secure computer environment for all users. Management screen Management server Incident Help desk Client PC management Connection control Security Network devices Various data Agent Agent Agent Agent Anti-virus software Anti-virus software Anti-virus software Anti-virus software Client PC Figure 5.9-1 Schematic Overview of Operation Management (Client PC system) 158 Management screen Internet protocol response time measurement server Management server Agent Incident Symbols Help desk Availability/performance management Response time measurement Network management Storage management Viability monitoring Server management Network devices Various data SAN storage Agent SAN Agent Agent Agent Web server AP server DBMS OS OS OS OS Objects of management (Web server, AP server, DBMS, etc.) Figure 5.9-2 Schematic Overview of Operation Management (Server system) Internet content/spam filter Spam mail filter Mail server Intrusion detection/ protection Anti-virus gateway Contents filer server Anti-virus gateway server Server room DMZ IDS/IPS FW VPN Internal segment Proxy server Encryption (VPN) Trail management Business server アクセスログ Access log Log collection server Operation/ management segment Internet Virus pattern distribution server Floor segment Floor segment Encryption (file) Virus protection f unction (of fice PC) Measures against information take-out Office room Figure 5.9-3 Schematic Overview of Security System 159 External hub The functions and services provided by the operation management and security are defined as follows. Function and service Performance management Client PC management Server management Network management Storage management Service desk Definition Performance management provides centralized administrative control over availability information of OSs and applications, and, when a failure takes place, supports causal investigation based on the gathered data Client PC management provides centralized gathering and administrative control of information of the client PCs (hardware configuration, OSs and applications running on them) deployed in the network compatible environment. It also provides resource distribution functions – configuration management and introduction/deletion of software to/from the networked PCs – as well as remote controlling of the PCs. Server management monitors operational status and loading conditions of the business servers that constitute the information system within the Cabinet Office and the Ministries, takes measures against data destruction in case of disaster (installation of a duplicated system in a remote location, storage of backup media in a remote location), and manages ancillary facilities (uninterrupted power systems, rack temperatures) in the server installation environment. In all, the server management assumes the job scope usually covered by the system operation administrator, or its equivalent. Note, however, that it leaves out consideration for a case in which the operation of the servers within the Cabinet Office and Ministries is outsourced to external service providers. Nor does it take into consideration requirements imposed on the data center business operator (e.g. business size). Network management assumes the following functions: (1) Operation of the network within the Cabinet Office and Ministries consisting mainly of L2-L3 equipment (switches, routers, etc.) (2) The functions normally covered by the information system operator within the Cabinet Office and Ministries from the viewpoint of ICT system administration (3) The functions required to enhance quick recovery from a network failure, and to minimize business disturbances caused by it, as well as to provide effective preemptive measures against it Note, however, the requirements for the following business operators are not taken into consideration: NI/SI business operators that act as a maintenance proxy, and iDC business operators. Storage management provides functions for effective centralized management of external memory unit resources (storage devices) used to store data and programs, including such additional functions for performing configuration display, performance/state monitoring, and various event notification. Service desk provides such functions that enable it to work as the one-stop center for accepting problem notifications and various usage inquiries regarding the information system. The events are accepted through telephone or e-mail and their contents will be registered to a database, which is open to user access. Through linkage with other system’s fault 160 Security Job management control and configuration management capabilities, these functions can be utilized for resolving problems when they occur. Security provides functions for detecting unauthorized access to computers and viruses, and for monitoring the status of information security – e.g. frequency of access denials performed by the contents filtering server. It also provides the hazardous event notification function that issues an appropriated level of alarms depending on the severity of the event. In addition, it includes such functions as giving graphically-represented statistical reports for monitoring results that include analysis and improvement proposals. Job management provides functions to compile procedures for routine tasks, and execute them regularly at given intervals or link them with particular events for triggering. 5.9.1. Functional and Non-Functional Requirements for Performance Management 5.9.1.1. Centralized management of server availability information This function is used to centralize availability information of the monitored objects for unified control. Functional Requirements 1 Basic Capability to manage both OSs and applications from single screen. 2 Basic All operations for OS and application monitoring must be communalized. 3 Basic The objects to be monitored must have a hierarchy structure for easy localization of failure events. 4 Basic Quick and easy access to the report screen pertaining to the monitored object. 5 Basic Restriction of the scope of operations depending on the user’s authority. 6 Basic Accessibility to operational viability information of the monitored server. 7 Additional Availability of the operations history (operation log) for setting changes, etc. 8 Basic Capability to monitor the operational status of the management server and monitored processes. 9 Additional Centralized management method easily applicable to the management of virtualized resources. Non-functional Requirements (description provided only when relevant requirements are given) Availability Additional Clustered configuration capability of the management servers. Security Basic Availability of login management to avoid unauthorized modification of configuration information etc. Extendability Basic Capability to store necessary amounts of gathered data (sufficient to cover the audit period for internal control). Backup Basic Backup capability of configuration definition information and operational log. 161 5.9.1.2. Information Gathering and Management of Performance Target location for Information gathering and abnormality detection includes the management servers and the units under monitoring. Functional Requirements 1 Basic Provision of default monitoring items (threshold valued included). 2 Basic Capacity for creating monitoring items freely. 3 Basic Functionality that allows e-mail dispatch and command execution in case a measurement value exceeds a given threshold. 4 Additional Setting option not to store data (i.e. threshold monitoring only) 5 Basic Capability to consolidate the gathered data regularly (on hourly, daily, weekly, and monthly basis). 6 Basic Capability to automatically delete old data when a given storage period expires. 7 Basic Capability to gather arbitrary measurement data as defined by the user. 8 Basic Functionality to avoid data loss even in the case of communication failure between the management server and monitoring agent. Non-functional Requirements (description provided only when relevant requirements are given) Backup Basic Capability to backup monitoring definitions. Extendability Basic Capability to store necessary the amount of gathered data (sufficient to cover the audit period for internal control). 5.9.1.3. Report Management Report management provides methods to create graphical representation of the gathered operation qualification data. Functional Requirements 1 Basic Provision of multiple graphical format options (bar graph, line chart, pie chart, etc.) 2 Basic Provision of report templates as a default report format. 3 Basic Provision of a method to freely create new templates. 4 Basic Capability to display a multiplicity of measurement data - multiple monitoring items of OS and applications – in a single graph. 5 Basic Capability of overwriting large amounts of data from different points in time (current data and past data from any given point in time). 6 Additional Provision of a report saving function on the display screen. 7 Basic Capability to save reports and measurement data automatically. 8 Basic Capability to freely adjust the time window of the graphical display. 5.9.1.4. OS Performance Management This function provides methods for gathering information regarding the performance of OSs. Functional Requirements 1 Basic Capability to gather operation data of CPU utilization. 2 Basic Capability to gather operation data for each CPU (in case of a multi-CPU system). 162 3 Basic 4 5 6 7 8 9 Basic Basic Basic Basic Basic Basic 10 Basic 11 Basic 12 Basic Capability to gather operation data for each CPU core (in case of a multi-core CPU system). Capability to gather utilization information of physical hard disks. Capability to gather I/O performance information of physical hard disks. Capability to gather free space information of physical memory. Capability to gather free space information of virtual memory. Capability to get the number of concurrently running processes. Capability to gather information of CPU and virtual memory utilization on a process-by-process basis. Capability to gather I/O information of a network interface card. Capability to monitor event log. Capability to monitor the state of services provided by OS (i.e. daemon processes). Non-functional Requirements (description provided only when relevant requirements are given) Extendability Basic Capability to save gathered data in external storage devices on an as needed basis, and restore it when needs arise. Extendability Basic Capability to store the necessary amount of gathered data (sufficient to cover the audit period for internal control). 5.9.1.5. DBMS Performance Management This function provides methods for gathering information regarding performance of DBMSs. Functional Requirements 1 Basic Capability to gather utilization information on a table-by-table basis. 2 Basic Capability to gather information on the SQL statements currently executing. 3 Basic Capability to monitor the state of connections. 4 Basic Capability to obtain the dispatcher IP address and program information of an SQL statement. 5 Basic Capability to monitor the occurrence status of locking. 6 Basic Capability to gather input/output information (number of times, etc). Non-functional Requirements (description provided only when relevant requirements are given) Availability Basic In case of clustered DB servers, the management agent must be able to manage all the servers. Extendability Basic Capability to save gathered data in external storage devices on an as needed basis, and restore it when needs arise. Extendability Basic Capability to store the necessary amount of gathered data (sufficient to cover the audit period for internal control). 5.9.1.6. AP Server Performance Management This function provides methods for gathering information regarding performance of AP servers. Functional Requirements 163 1 2 3 4 Basic Basic Basic Basic Capability to gather access number information. Capability to obtain the number of garbage collections that have taken place. Capability to obtain the execution time required by a garbage collection. Capability to gather information on the heap usage required for running component applications (Java components, NET components, etc.). 5 Basic Capability to gather average response time information of Web services. 6 Basic Capability to obtain the number of sessions. 7 Basic Capability of obtain the number of queuing threads. Non-functional Requirements (description provided only when relevant requirements are given) Availability Basic In case of clustered AP servers, the management agent must be able to manage all the servers. Extendability Basic Capability to save gathered data in external storage devices on an as needed basis, and restore it when needs arise. Extendability Basic Capability to store the necessary amount of gathered data (sufficient to cover the audit period for internal control). 5.9.1.7. Performance monitoring of Internet services This function provides methods for gathering information on operational performance of the services provided by the Internet protocol. Functional Requirements 1 Basic Capability to gather response time information of Web pages (HTTP, HTTPS, etc.). 2 Basic Capability to record the series of events taking place on a Web site, enabling the ability to gather total response time information. 3 Basic Capability to obtain the response time of a particular operation during the course of events described in the item above. 4 Basic Capability to determine the correctness of a Web page’s content during the course of events described in the item above. 5 Basic Capability to gather response time information in mail transmission/reception (SMTP, POP3, IMAP4 etc.) 6 Basic Capability to gather response time information required for address resolution (DHCP, DNS, etc.) 7 Basic Capability of obtain a TCP port connection time. 8 Basic Capability to run a program to measure the response time of a given application, and gather relevant information from it. 9 Additional Capability to gather communication messages between the management server and agents. Non-functional Requirements (description provided only when relevant requirements are given) Availability Basic In case of clustered measurement servers, the management server must be able to operate on the cluster. Extendability Basic Capability to save gathered data in external storage devices on an as 164 needed basis, and restore it when needs arise. Extendability Basic Capability to store the necessary amount of gathered data (sufficient to cover the audit period for internal control). Related technologies Hyper Text HTTP(Hyper Text Transfer Protocol) Transfer A protocol used for transmission and reception of data between Web servers Protocol and clients (e.g. Web browser), capable of transmitting/receiving HTML and other various formatted documents with their attached files (images, sound, and animation) and representation information. IETF standardized HTTP/1.0 as RFC 1945, and HTTP/1.1 as RFC 2616. Dynamic Host Configuration Protocol Domain Name System HTTPS(Hyper Text Transfer Protocol Secure) A protocol derived from HTTP - used for transmission and reception of data between Web servers and clients (e.g. Web browser) - with addition of encryption capability using SSL. It enables secured communication that involves confidential information (privacy information, credit card numbers, etc.) through encryption of correspondence between the server and browser. Major Web browsers (Internet Explorer, Firefox, Safari, etc.) are compatible with this protocol, making it the de facto standard. SSL is an encryption protocol propounded by Netscape Communications. In addition to HTTP, it is also applicable to such protocols as FTP and TELNET. DHCP(Dynamic Host Configuration Protocol) A protocol to automatically assign necessary information (an IP address and others) to a computer connecting temporarily to the Internet. A DHCP server is allocated with a pre-defined range of IP addresses (to be assigned for Gateway servers and DNS servers, and for subnet masks and clients), and it provides necessary information to the computer that is accessing the server through dial-up or through other schemes. When a client terminates its communication, the DHCP server automatically recovers the address for use with other computers. The use of DHCP enables even the casual users – who may not be familiar with network settings - to establish connection to the Internet without difficulties. It also enables the network administrators to manage large numbers of clients in a unified fashion. DNS(Domain Name System) A system to match a host name in the Internet to a IP address. This is a distributed database through which the DNS servers all around the world make concerted operations. A host name can be searched from an IP address, and vice versa. Each DNS server maintains a set of domain information under its control, and registers the domain name and its own address to the route servers (approx. 10 route servers are in operation around the world). A client program (called “resolver”) resolves the conversion by first making inquiries about the domain name (or IP address) with the route server, and then examining the DNS server that manages the domain, followed finally by extracting necessary information from the DNS server. A majority of the DNS servers operating in the Internet use the BIND server, which was developed by UCB (University of California at Berkley). 165 5.9.1.8. Performance Management of the Job Management Server This function provides mechanisms for gathering information regarding performances for job management servers. Functional Requirements 1 Basic Capability to gather the number of jobs currently executing. 2 Basic Capability to gather the number of jobs that have failed. 3 Basic Capability to gather the number of jobs that are staying dormant. 4 Basic Capability to gather the number of jobs that are delayed in their execution. 5 Basic Capability to gather information regarding the operational status of DBMSs in use. 6 Basic Capability to gather latency time information of the jobs. Non-functional Requirements (description provided only when relevant requirements are given) Availability Basic In case of clustered job management servers, the management agent must be able to control all the servers. Extendability Basic Capability to save gathered data in external storage devices on an as needed basis, and restore it when needs arise. Extendability Basic Capability to store the necessary amount of gathered data (sufficient to cover the audit period for internal control). 5.9.1.9. Performance Management of Web Server Management Software This function provides mechanisms for gathering information regarding performance for Web server management servers. Functional Requirements 1 Basic Capability to gather access count. 2 Basic Capability to gather the count of “Not Found” (*) occurrences. 3 Basic Capability to gather throughput information. 4 Basic Capability to gather transfer rate information (transmission and reception). (*)“Not Found” count: the number of times when the Web site is not located using the given URL. Non-functional Requirements (description provided only when relevant requirements are given) Availability Basic In case of clustered Web servers, the management agent must be able to control all the servers. Extendability Basic Capability to save gathered data in external storage devices on an as needed basis, and restore it when needs arise. Extendability Basic Capability to store the necessary amount of gathered data (sufficient to cover the audit period for internal control). 166 5.9.1.10. Performance Management of Business Applications This function provides mechanisms for gathering information regarding performance for business applications. Functional Requirements 1 Basic Capability to gather response time information, and to detect occurrences of response time-out. 2 Basic Capability to gather dispatcher latency time information. 3 Basic Capability to gather DBMS request time information. 4 Basic Capability to gather the number of logged-in users. 5 Basic Capability to gather log information. 6 Basic Capability to gather working process information. Non-functional Requirements (description provided only when relevant requirements are given) Availability Basic In case of clustered business application servers the management agent must be able to control all the servers. Extendability Basic Capability to save gathered data in external storage devices on an as needed basis, and restore it when needs arise. Extendability Basic Capability to store the necessary amount of gathered data (sufficient to cover the audit period for internal control). 5.9.1.11. Performance Management of Groupware This function provides mechanisms for gathering information regarding performance for groupware. Functional Requirements 1 Basic Capability to gather information regarding mail transmission/reception. 2 Basic Capability to gather network information (i.e. data transmission and reception). 3 Basic Capability to gather mail server queue information. 4 Basic Capability to gather file information of the database in use (cache hit ratio, disk capacity, etc.). 5 Basic Capability to monitor the state of service provisioned by groupware. Non-functional Requirements (description provided only when relevant requirements are given) Availability Basic In case of clustered groupware servers, the management agent must be able to control all the servers. Extendability Basic Capability to save gathered data in external storage devices on an as needed basis, and restore it when needs arise. Extendability Basic Capability to store the necessary amount of gathered data (sufficient to cover the audit period for internal control). 167 5.9.1.12. Performance management of distributed transactions This function provides mechanisms for gathering information regarding performance for distributed transactions. Functional Requirements 1 Basic Capability to gather performance information related to RPC (Remote Procedure Call). 2 Basic Capability to gather the number of accesses done to files. 3 Basic Capability to gather the number of commits/rollbacks. 4 Basic Capability to gather communication status information of the distributed transaction servers. 5 Basic Capability to gather information relating to the queue manager’s operational status. 6 Basic Capability to gather information relating to the handle status. Non-functional Requirements (description provided only when relevant requirements are given) Availability Basic In case of clustered distributed transaction servers, the management agent must be able to control all the servers. Extendability Basic Capability to save gathered data in external storage devices on an as needed basis, and restore it when needs arise. Extendability Basic Capability to store the necessary amount of gathered data (sufficient to cover the audit period for internal control). Related technologies Remote RPC (Remote Procedure Call) Procedure Call A procedure, developed by Sun Microsystems, used to enable processing among dissimilar machines deployed on the Internet. This technology has widespread use in UNIX systems, and is also finding its implementation in Windows NT. The DCOM – Microsoft’s distributed object technology – was developed based on RPC. 5.9.2. Functional/Non-Functional Requirements for Client PC Management 5.9.2.1. Client PC configuration management Client PC configuration management provides functions to gather information regarding the hardware and software implementation of the client environment, thus enabling unified control of it. These functions can also be used as a security measure and serve to detect network connection attempts from unauthorized clients and use of malicious software. Functional Requirements 1 Basic Capability to browse device information – CPU, memory, physical disk, MAC address, external storage devices, etc. 2 Basic Capability to gather information regarding the software implemented on each terminal. 168 3 Basic Capability to browse OS information – type and version of OS, computer name, and network information (IP address, etc.). 4 Basic Capability to gather configuration and other information at any time, on a group-by-group and user-by-user basis. 5 Basic Selectability of the terminals used to gather information. 6 Basic Capability to stop displaying (or hide temporarily) GUI elements while information gathering is taking place (a measure to avoid interrupting user operation). 7 Basic Capability of unifying all management, and browsing and conditional searching of the information gathered. Non-functional Requirements (description provided only when relevant requirements are given) Availability Basic Availability of active client PCs even in the case of management server failure. Performance Basic Capacity of controlling multiple PCs (up to several thousand) through synchronization. Extendability Basic Extendability of the range of control up to several thousand PCs by utilizing distributed servers and other schemes. Security Basic Access authority to the gathered PC configuration information must be assigned only to qualified personnel. 5.9.2.2. Resource Distribution Management Resource distribution management provides the server with the methods to perform software distribution services – e.g. remote installation of common standard software and security patches – to multiple client PCs en block. Functional Requirements 1 Basic Capability to distribute software from the server to the terminals. 2 Basic Capability to distribute to all the terminals. 3 Basic Capability to stop displaying (or hide temporarily) GUI elements while the distribution process is being carried out (a measure to avoid interrupting user operation). 4 Basic In case a system restart is required at the end of the distribution operation, a message must be displayed to prompt the working user to reboot the system. 5 Basic Capability to handle setup operations using major installer formats (msi, exec, etc.) 6 Basic Capability to define the types of software that can be installed/uninstalled for each terminal and for each group. 7 Basic Capability to distribute only to specified terminals and groups. 8 Basic Capability to verify the results of the software distribution. 9 Basic Capability of performing the following cycle: powering-on of a terminal, distribution of software, followed by an automatic powering-off of the terminal. 10 Basic Capability to automate resource distribution operations (user operations from installation to system restart) and scheduled execution of them. 169 11 Basic 12 Basic 13 Basic Capability to allocate distribution load appropriately to minimize its effect on other services, especially in the case of a large scale resource distribution such as a service pack. Capability to detect, after resource distribution, the client PC where normal distribution failed, enabling a retry of distribution. Capability to perform an installation/version upgrade of software without any user operations, even if it does not normally allow silent-mode installation. Note that, this requirement is considered to be met if distribution operation can be performed based on the installation operation log and its modifications on a particular terminal. Non-functional Requirements (description provided only when relevant requirements given) Performance Basic Capacity to control multiple PCs (up to several hundred thousand) simultaneously. Extendability Basic Extendability of the range of controllable PCs up to several million by utilizing distributed servers and other schemes. Security Basic Only the authorized users are allowed to perform distribution operations, and refer to the distribution resources. 5.9.2.3. Remote Operation Remote operation is a part of management functions that enables the server to perform remote client operations to the client PCs. Functional Requirements 1 Basic Capacity of controlling multiple PCs (up to several hundred thousand) simultaneously. 2 Basic Capability to remotely restrict the users that are authorized for connection. 3 Basic Capability of remote connection and file transfer to the connected terminal. 4 Basic Capability of remote connection and restart of the connected terminal. 5 Basic Capability to remotely control a client PC even while it is not logged in. 6 Basic Capability of encrypting communication contents for remote operations, and recording operation details. 7 Basic Capability to record operations, as log information, performed to change the state of operational objects (i.e. terminals) – logon, shutdown, restart, etc. Non-functional Requirements (description provided only when relevant requirements given) Performance Basic Capability to perform operations through the network, which requires the capacity to reduce line load (required band-width) depending on the line speed employed. 5.9.2.4. Others Functional Requirements 1 Basic Capability to record the operations log performed to the client PCs, and the information must be browsable. The operations log must at least include program invocations and file operations. 170 5.9.3. Functional/ Non-Functional Requirements for Server Management 5.9.3.1. Server configuration management Server configuration management includes functions that enable control of hardware and software information required to define the configuration of the server. Functional Requirements 1 Basic Capability of the centralized management of the latest set of configuration information for all servers, including device information, system information (OS, CPU, memory, etc.), software information, network information, and disk information. 2 Additional Capability to display the revision history of server configuration information, and changes before and after a modification. Non-functional Requirements (description provided only when relevant requirements given) Availability Basic Operations, except for those related to server configuration management, must be available to the terminals (console terminals) even while the management server is down. Performance Basic Capacity to control multiple servers (up to several hundred) simultaneously. Extendability Basic Extendability of the range of controllable servers up to several hundred. Security Basic Accessibility to all of the gathered server configuration information (device/system/software/network/disk information) must be appropriately provided. 5.9.3.2. Performance Management Performance management includes management functions to monitor the level of performance required by the server. Functional Requirements 1 Basic Capability to the gather kernel configuration information of each OS. 2 Basic Capability to gather performance information of such system elements as IO, memory, cache, space, deadlock, and database usage (e.g. SQL frequency). Non-functional Requirements (description provided only when relevant requirements given) Availability Basic Any failure in performance management functions must not have an effect on the execution of other services (functions), and methods must be provided for easy restoration. Extendability Basic The performance management must be capable of controlling multiple databases and OSs. Extendability Basic The performance management must have the flexibility to meet the requirements of new versions of databases and OSs. 5.9.3.3. Fault Control Fault control provides functions to detect server failures, and to cope with irregular situations in the servers comprising the business system. 171 Functional Requirements 1 Basic Capability to monitor the output functions of specified log information, and issue a notification (e.g. alarm) to the administrator in case it detects one of the given events. 2 Basic Capability to record operations, as log information, performed to change the state of operational objects (i.e. terminals) –shutdown, reboot, etc. 3 Additional Capability to perform polling on each of the server communication ports under the control of various services and daemons (e.g. HTTP/HTTPS, DNS, SMTP, and any other specified ports). 4 Basic Capability to monitor the operational status of various services, daemons, and processes that are resident on the server. 5 Basic In the event of hardware failures and other abnormal events, the system configuration must have the provision to notify staff members, maintenance contacts, and the administrator in charge by means of e-mail (including e-mailing to mobile phones). This function must cover all the servers installed in a given machine room. 6 Basic Capability, when a failure occurs, to identify and locate the range of the affected area. 7 Basic Capability to manage failure history information. Non-functional Requirements (description provided only when relevant requirements given) Extendability Basic The failure management functions must be compatible with multiple databases and OSs 5.9.3.4. Resource Management Resource management provides management functions to display/notify the utilization information (used/free space) of the hard disks incorporated in the server. Functional Requirements 1 Basic Availability of graphic display and file output of hard disk utilization information (used and free space) incorporated in all server hardware. 2 Basic Availability of a function to monitor disk usage threshold, and automatic notification to the person in charge. 5.9.3.5. Backup Management Backup management provides controlling methods against data destruction that may be caused by disasters and system failures (including human errors). Functional Requirements 1 Basic Capability of online backup (for the software compatible with online backup). 2 Basic Compatibility with scheduled backup. 3 Basic Availability of both full and incremental backup. 4 Basic Capability of monitoring backup operation status (success and failure) 5 Basic Restoring capability on file, folder, logical volume, and server basis. 6 Basic Accessibility to restore operations from other servers than that obtained the backup. 172 7 Basic Capability to create backup media that can be used for system area restoration. 8 Additional Capability of the backup media to start and perform system area restoration operations. 9 Basic Additional implementation of segments dedicated for backup operations, in cases where there are concerns that the backup operations might overload the business use of the network. 10 Basic Capability of the management of backup media generation. Linkage with library equipment is required to archive the given number of data generations in the media. Non-functional Requirements (description provided only when relevant requirements given) Availability Basic Backup must not trigger operational discontinuation of the server, nor produce the need for a system reboot. Security Basic Authority to make a reference to the backup media must be strictly limited only to the authorized users. 5.9.3.6. Inter-Equipment Linkage Inter-equipment linkage provides functions to manage irregular events that may occur in the related set of equipment essential for system operation. Functional Requirements 1 Basic Capability to monitor the status of equipment installed in a given machine room (air-conditioning, power unit, water leakage, temperature, etc.), and to provide notification for the occurrence of irregular events. 2 Basic Provision of assistance functions for the operator/administrator to control and shutdown the equipment installed in the machine room where irregular events are taking place. Non-functional Requirements (description provided only when relevant requirements given) Availability Basic Capability to issue a server shutdown command in no uncertain manner when an equipment failure is detected. Extendability Basic Provision of an interface enabling detection of equipment failures. 5.9.3.7. Resource Distribution Management This function provides the management server with management functions to perform software distribution services – e.g. remote installation of common standard software and security patches – to multiple servers en block. Functional Requirements 1 Basic Capability of the management server to distribute software to target servers. 2 Additional Capability to stop displaying (or hide temporarily) GUI elements while the distribution process is being carried out (a measure to avoid interrupting user operations). 3 Basic In case system restart is required at the end of a distribution operation, a message must be displayed to prompt the working user to reboot the system. 173 4 5 Additional Capability to handle setup operations using major installer formats. Basic Capability to define the types of software that can be installed/uninstalled for each server and for each group. 6 Basic Capability to distribute only to specified servers and groups. 7 Basic Capability to confirm the results of the software distribution. 8 Additional Capability to automate resource distribution operations (user operations from installation to system restart) and scheduled execution of them. 9 Basic Capability to allocate distribution load appropriately to minimize its effect on other services, especially in the case of a large scale resource distribution such as a service pack. 10 Basic Post-distribution capability to locate the server on which normal distribution failed, enabling a retry of distribution. 11 Additional Capability to perform software installation (or version upgrade) without any user operations, even if the software does not normally allow silent-mode installation. Non-functional Requirements (description provided only when relevant requirements given) Performance Basic Capacity of controlling multiple servers (up to several hundred) simultaneously. Extendability Basic Extendability of the range of controllable servers - up to several hundred - by utilizing distributed management servers and other schemes. Security Basic Only the authorized users are allowed to perform distribution operations, and refer to the distribution resources. 5.9.3.8. Others Functional Requirements 1 Basic Capability to record an operations log performed to the servers, and the log information must be browsable. 174 5.9.4. Functional/ Non-functional Requirements for Network Management 5.9.4.1. Network configuration management Network configuration management includes functions that enable the control of network equipment and software information required to define configuration of the network. Functional Requirements 1 Basic Capability to automatically create the network map from network configuration information. 2 Basic Capability to automatically gather arbitrary MIB information from each node. 3 Basic Capability to manage installation and setting information of the network devices. 4 Basic Capability to manage the number of installations of network equipment. 5 Basic Capability to gather network configuration information automatically and each network device must be capable of invoking regular updates of configuration information. 6 Basic Capability to customize the network map, enabling the creation of hierarchical network maps on a hub and floor basis. 7 Basic Browsability of configuration information using a GUI. 8 Additional Capability to display the results of past configuration modifications, as changes before and after a modification. 9 Basic Capability to display configuration information in the way most suited to each hub and section. 10 Basic Capability of a screen-by-screen display of the different types of configuration information. 11 Additional Capability to display types of configuration information based on the VLAN route. 12 Basic Capability to distinguish the state (normal/failed) of devices and line conditions on the screen – for example, by the changing of icon colors. 13 Basic Capability to locate an operational bottleneck (CPU of a network device/server, memory, etc.), which requires tracking of changes in the business throughput and load. 14 Additional Capability to maintain continued operational monitoring – without any delay associated with device switching – even in the cases of device failure in the operational management server. 15 Basic Capability to restrict types of operations allowed to the operator and administrator: a measure to prevent network problems caused by inadvertent operations. Non-functional Requirements (description provided only when relevant requirements given) Availability Basic The servers and client PCs must be able to perform non-networking tasks even while the network is down. Performance Basic Capability to manage multiple PCs (several hundred thousand) and servers (several hundred) simultaneously. Extendability Basic Extendability of the range of controllable PCs (up to several hundred thousand) and servers (up to several hundred). 175 Security Basic Capability to assign the authority of accessing the gathered configuration information of monitored devices only to qualified persons. Related technologies Network SNMP (Simple Network Management Protocol) management In a TCP/IP network, this protocol is used to monitor/control the networked protocol communication devices (routers, computers, terminals, etc.) through the network. The devices to be controlled have a management information database, called MIB, and the controlling device configures the target devices appropriately based on MIB. (Specifications) http://www.ietf.org/rfc/rfc2570.txt?number=2570 (Link & information portal) http://www.simpleweb.org/ MIB MIB (Management Information Base) MIB is the management information contained in a SNMP-controlled device. Two versions are currently available (MIB1 defined by RFC 1156 and MIB2 defined by RFC 1213), of which the latter has become more prevalent. The specifications for this database are standardized by the IETF. (Specification) http://www.faqs.org/rfcs/rfc1213.html 5.9.4.2. Traffic management Traffic management provides methods to control the traffic over the network. Functional Requirements 1 Basic Capability to measure and gather traffic information in real time. 2 Basic Capability to define a threshold on the measured traffic information and to notify the person in charge automatically in case the actual traffic exceeds it. 3 Basic Capability to monitor the traffic passing through the network, and to perform fine bandwidth management (i.e. control of bandwidth and transmission delay) conforming to the policy defined by the user. The locations from where the monitoring/management operation is performed are stated separately. Non-functional Requirements (description provided only when relevant requirements given) Availability Basic Business services must be provided continuously and flawlessly regardless of the running status (on/off) of the traffic management functions. 5.9.4.3. Fault control Fault control provides methods to control network faults. Functional Requirements 1 Basic Capability to monitor if a node/link is down in network devices, as well as to monitor node status using ICMP-echo. 2 Basic Provision of automatic notification and filtering of the events to be monitored. 3 Additional Provision of automatic classification (filtering) for the events to be monitored. 4 Basic Capability of a forced remote-controlled shutdown of the link of connection ports incorporated in central/local node switches. 176 5 Basic 6 Basic 7 Basic Capability of centralized control (e.g. powering On/Off, restart) of network devices located in external hubs (this requirement applies to the network devices capable of remote powering On/Off and restart). Capability to remotely control network devices even in the case of network failure (assuming that communication to those network devices is still available). Capability of historical management of failures, including search function using a keyword. Non-functional Requirements (description provided only when relevant requirements given) Extendability Additional Data saving functions must be compatible with various types of databases and OSs. Availability Basic Provision of multiple notification methods (e.g. alarm light, mail, etc.). These monitoring methods must operate concurrently to guarantee secure notification to the management server. Availability Additional Capability of monitoring and archiving the management of Syslog output from the network devices. 5.9.4.4. Others Functional Requirements 1 Additional Capability to record an operations log performed in relation to network management, and the log information must be browsable. 5.9.5. Functional/ non-functional requirements for storage management 5.9.5.1. Storage configuration management Storage configuration management provides functions to display/notify information regarding storage devices such as the attributes, logical disk configuration, and connection status. Functional Requirements 1 Basic Provision of configuration information gathering functions applicable to storage devices. 2 Basic Provision of an automatic detection function of connected storage devices. 3 Basic Provision of a function to create a map of the connected storage devices. Non-functional Requirements (description provided only when relevant requirements given) Availability Basic The servers and client PCs connected to the storage management server/storage must remain operative without interruption even while the storage is down. Security Basic Access authority to the gathered storage configuration information must be assigned only to qualified operators. 5.9.5.2. Performance management Performance management provides functions to monitor and display the performance status in real time, detecting symptoms, and preventing performance degradation. 177 Functional Requirements 1 Basic Capability to gather and monitor storage devices’ performance information such as Read/Write frequency, data transfer time, average response time, and disk usage rate. 2 Basic Capability to gather and monitor performance information between the server and storage (SAN switch performance, etc.). 3 Basic Provision of a function to monitor the threshold assigned to performance information for storage devices and server-storage operations, and to automatically notify the person in charge. 4 Basic Provision of a graphic display and file output function for performance information. Non-functional Requirements (description provided only when relevant requirements given) Availability Basic Failure in performance management functions shall not hinder continuous operation of storage devices. 5.9.5.3. Resource (capacity) management Resource (capacity) management provides functions to display and notify the usage status (used and free space) in each disk and logical group. Functional Requirements 1 Basic Capability to gather and save the resource (capacity) information of each server connected to the storage (capability to grasp the amount of used and free space in each device, volume and server is required). 2 Basic Provision of a function to monitor the disk usage threshold and to automatically notify the person in charge. 3 Basic Provision of a graphic display and file output function. 4 Additional Capability to grasp current disk usage information (used and free space) for each folder and user. 5 Basic Provision of a function to calculate billing data for each section based on its usage. 6 Basic Capability to accommodate additions of new disks. Non-functional Requirements (description provided only when relevant requirements given) Performance Basic Resource (capacity) management shall not have an effect on the performance of storage devices. 5.9.5.4. Fault control Fault control provides functions to monitor and display the status of storage devices, and to issue messages when failure occurs. Functional Requirements 1 Basic Provision of a function to provide automatic notification of the occurrence of monitored events. 2 Basic Provision of a filtering function, which enables automatic classification of the monitored events. 178 3 Additional Capability to remotely operate the storage devices in the event of a storage failure (centralized control of powering On/Off and restart). 4 Basic Capability to gather information such as the operation/console log, event log, and configuration. 5 Basic Capability to forcefully shutdown connection port links in SAN switches from a remote location. This functionality is required, for example, to perform stepwise disconnection prior to starting maintenance operations. Non-functional Requirements (description provided only when relevant requirements given) Extendability Basic Compatibility with various types of databases and OSs. Availability Basic Provision of multiple notification methods (e.g. alarm light, mail, etc.). These monitoring methods must operate concurrently to guarantee secure notification to the management server. 5.9.5.5. Backup management Backup management provides controlling methods against data destruction that may be caused by disasters or storage failures (including human errors). Functional Requirements 1 Basic Provision of functions that enable performance of backup operations without the use of the LAN or servers (*). 2 Basic Provision of functions to support remote backup and disaster recovery operations among the hubs. (*) LAN-free backup: a method to backup data by way of SAN, and not by way of LAN. Server-less backup: a backup method that does not use the LAN, and does not put load on the server. Non-functional Requirements (description provided only when relevant requirements given) Security Basic Authority to make a reference to the backup media must be strictly limited only to the authorized operators. 5.9.5.6. Others Functional Requirements 1 Basic Capability to record an operations log performed to the storage, and the information must be browsable. 5.9.6. Functional and Non-Functional Requirements for service desk 5.9.6.1. Service desk management Service desk management provides functions that enable it to work as the one-stop center for accepting and managing trouble notifications and various usage inquiries regarding the information system. Functional Requirements 1 Basic Capability to manage inquiries that arrive via mails and through the GUI. 179 2 Basic Capability to automatically notify the operator in charge of inquiries, and to register them for storage in database. 3 Basic Capability to attach a file, as auxiliary information, to trouble tickets, problem sheets, and modification management forms. 4 Basic Capability to browse and search past inquiries through the use of a GUI. 5 Basic Provision of an escalation function. 6 Basic Capability to automatically register failure information that was detected by other management functions through a well coordinated linkage between them. 7 Basic Capability to integrate all information system related application contacts to the service desk. Non-functional Requirements (description provided only when relevant requirements given) Extendability Additional Provision of an interface that enables coordinated operation with server monitoring and network monitoring functions. Availability Basic No software restriction shall be placed on the maximum number of inquiries (extendability must be management-related incorporated). 5.9.6.2. Others Functional Requirements 1 Basic Capability to record an operations log performed to the service desk, and the information must be browsable. 180 5.9.7. Functional and Non-Functional Requirements for Security 5.9.7.1. Virus protection function Virus protection provides function to detect malicious or infected programs to protect servers and terminals (PCs) from becoming infected with those harmful agents. Functional Requirements 1 Basic Provision of anti-virus/vaccine software that is compatible with the proposed OS. 2 Basic Capability of automatic shutdown of PCs following the completion of a virus scan (if the user plans to shutdown the PC after the virus-scan), or automatic re-execution of the virus scan at the subsequent restart of the PC. 3 Basic Capability of automatically updating the virus definition pattern file, which involves scheduled access to the server of the pattern file provider through the Internet. 4 Additional Capability to execute an update of the virus definition pattern file without the need to restart the system. 5 Basic Capability to detect infected/malicious programs in real time, and to isolate the malicious program or cleanse viruses. 6 Basic Provision of functions that enable centralized management of pattern files in a server, and to distribute them to terminals. Non-functional Requirements (description provided only when relevant requirements given) Availability Additional Abnormality in vaccine software must not cause the stoppage of servers and terminals (PC). Availability Basic Stoppage of the distribution server that distributes virus definition patterns and other information shall not bring the detection function to a stop. Availability Basic Latest pattern files for virus-checking shall be distributed. Security Basic Provision of protective measures against inadvertent distribution of spurious virus definition pattern files. Security Basic Inability of the end users to stop the running vaccine software, or uninstall it. Performance Additional Virus scan and pattern file distribution shall not cause excessive delay in other normal operation programs. Extendability Basic Provision of scalability to cope with the increased variety of objects to be distributed (i.e. pattern files and other related files). - The content of this section corresponds to the following items in the Standards for Information Security Measures for the Central Government Computer Systems: 2.1.1.4, 2.1.2 - The content of this section corresponds to the following segments in the physical configuration model: S0, S1 181 5.9.7.2. Internet Content Filtering Function The Internet contents filtering function provides methods to block access to harmful information on the Web (Internet) Functional Requirements 1 Basic Introduction of a function to block access from the targeted internal network to a set of specified Internet URLs. 2 Basic Capability to automatically update the banned URL database by means of accessing database provider’s servers, such as PICS, via the Internet. 3 Basic Capability to specify the interval to check if there are any updates in the banned URL database. 4 Basic Capability to allow access authority to URLs only to the specified users. 5 Basic Capability to monitor accesses to the banned URLs. 6 Basic Provision of enough banned URL data within and outside of the country. 7 Basic Capability to classify the banned and allowed URLs into detailed categories. 8 Basic Capability to apply a particular filtering policy on a unit-by-unit, or user-by-user basis. 9 Basic Capability of centralized user management in coordination with the directory service. 10 Basic Capability to synchronize multiple servers, even in a load-balancing environment consisting of a number of servers, by setting and applying a single rule. 11 Basic Provision of flexible rule settings, including such rules as “Browsing allowed & transmission prohibited” and “Filtering after checking its contents.” 12 Basic Capability of category-by-category and user-by-user graphic display access situation. 13 Basic Capability to extract required information (e.g. user name, group name, blocking situation, etc) from the access log. 14 Basic Capability to apply filtering functions to the cache of a search engine and translation functions provided by a translation site. Block log and POST log must be browsable from the management screen or by using report software. 15 Additional Provision of a virus detection capability by analyzing Web contents. 16 Additional Provision of an ICAP client function, or its equivalent within the chassis. Non-functional Requirements (description provided only when relevant requirements given) Availability Basic Abnormality in contents filtering functions shall not cause the stoppage of servers and terminals (PC). Availability Basic Stoppage of the distribution server that distributes pattern files for contents filtering shall not bring the detection function to a stop. Availability Basic Failures in content filtering functions shall not place any obstacles in the flawless continuation of network communication, and this must not require user intervention (setting modifications, etc). Security Basic Provision of a method to check the source of pattern file distribution (e.g. server certificate), enabling confirmation of the legitimacy of the pattern file. 182 Security Performance Extendability Basic Inability of the end users to stop the running contents filter, or uninstall it. Basic Running of the contents filter and distribution of pattern files shall not cause excessive delay in other normal system operations. Basic Provision of scalability to cope with the increased number of terminals to be checked by the contents filter. Related technologies Contents PICS (Platform for Internet Content Selection) control Technical specifications for implementing selective reception of Web contents standard in accordance with the levels defines by the user. This standard was established by W3C. (Standard) http://www.w3.org/PICS/ - The content of this section corresponds to the following items in the Standards for Information Security Measures for the Central Government Computer Systems: 2.1.1.2, 2.1.1.4, 2.2.3.2 - The content of this section corresponds to the following segments in the physical configuration model: S1 5.9.7.3. Anti-Spam Mail Function Anti-spam mail function provides methods to block spam mails (i.e. the mails that are sent unilaterally irrespective of the receiver’s will). Functional Requirements 1 Additional Provision of a personal firewall function that blocks transmission of spam mails from the client PCs. 2 Basic Provision of appropriate measures to protect the mail addresses that are laid on public view (e.g. on Web site). Protective measures are required – for example, the use of separate server – because the open addresses are more vulnerable to external menaces in terms of information security than those used by office members. 3 Basic Capability to monitor spam mail reception. 4 Basic Capability to block spam mails based on the source IP addresses. 5 Basic Capability to block spam mails from known senders. 6 Basic Capability to use a white list for message forwarding without blocking. 7 Basic Capability to block spam mails that contain URLs of fraudulent/malicious Web sites. 8 Basic Capability to block spam mails using a spam fingerprinting technique, or using other rule sets capable of maintaining higher level of security. 9 Basic Provision of handling a setting capability against mail judged as spam – isolation, distribution with a tag, destruction, etc. 10 Basic Capability to statistically check the status of spam mail traffic. 11 Additional Provision of a spam mail suppression measure either as an appliance or as software. 12 Additional Provision of a domain control measure on the delivery side - OP25B, DKIM, SPF etc. - to block spam mail transmission to the Internet. 183 Non-functional Requirements (description provided only when relevant requirements given) Availability Additional Abnormality in anti-spam functions shall not cause the stoppage of servers or terminals (PC). Availability Basic Stoppage of the distribution server that delivers anti-spam mail measures (e.g. pattern file) shall not cause a halt in anti-spam mail functions. Availability Basic Provision of measures to avoid adverse effects on normal operations (mail traffic, etc.) even in the case of functional failures and stoppage of the anti-spam mail server. Security Basic Provision of protective measures against inadvertent distribution of spurious anti-spam pattern files. Security Basic Inability of the end users to stop the running anti-spam functions, or uninstall them. Performance Basic Checking of spam mails and distribution of pattern files shall not cause excessive delay in other normal operation programs. Extendability Basic Provision of scalability to cope with the increased variety of objects to be distributed (anti-spam mail pattern files, etc.). Performance Additional Enough capacity to handle reception processing of a large number of spam-mails. - The content of this section corresponds to the following items in the Standards for Information Security Measures for the Central Government Computer Systems: 2.2.3.1 - The content of this section corresponds to the following segments in the physical configuration model: S0, S1, S2, S3, and S5. 5.9.7.4 Firewall Function The firewall provides methods to secure the safety of a particular network by controlling communication between the network and other external networks. Functional Requirements 1 Basic Installation of devices with firewall capabilities in the connection points linking the Internet, internal network, and the utilized system, which allow only particular types of communication traffic. 2 Basic Provision of a packet filtering function, which makes a go/no-go decision of traffic based on IP address and port number. 3 Basic Compatibility with both IPv4 and IPv6 protocols. 4 Basic Capability given to the administrator to configure audit information – including the address information whose communication traffic was blocked by the firewall. The configuration and verification procedure of the audit information must allow a remote access. 5 Basic Provision of a state-full inspection function, which makes a go/no-go decision on packet traffic based on the state of the communication flow. 6 Basic Provision of the TCP’s network address port translation (NAPT) function. 7 Basic Provision of a network address translation (NAT) function. 8 Basic Provision of a passing control function using a timer targeted at a combination of IP address and port number (this function also enables the system to monitor UDP communication). 184 Non-functional Requirements (description provided only when relevant requirements given) Availability Basic Provision of a multi-device redundant configuration that enables continued operation even in a case of failure and stoppage of one firewall function. Performance Basic Capability to continue normal processing even when the system receives a large number of packets. Security Basic Provision of a function to deny the access of suspicious packets in coordination with IDS. - The content of this section corresponds to the following items in the Standards for Information Security Measures for the Central Government Computer Systems: 2.1.1.2, 2.1.1.4, 2.1.1.3, 2.2.4.1 - The content of this section corresponds to the following segments in the physical configuration model: S1 5.9.7.5. Intrusion Detection/ Protection Function Intrusion detection provides functions to monitor communication traffic on the network, and to detect symptoms of fraudulent access. Functional Requirements 1 Basic Provision of the capability to analyze the packets that pass through the network using network type IDS (Instruction Detection System), which enables detection of attacks non-blockable by the firewall. 2 Basic Compatibility with both IPv4 and IPv6 protocols. 3 Basic Capability of automatically updating the pattern file, which involves scheduled access to the server of the pattern file provider through the Internet. 4 Basic Provision of an anti-intrusion processing function: this function, at the detection of an intrusion event, blocks the fraudulent access to the targeted segment/host in coordination with the device/software involved (such as a firewall), and outputs the related log as well as issuing an alarm to the monitoring equipment. 5 Basic Provision of an anti-intrusion mechanism that blocks the intrusion of fraudulent packets using a firewall and IPS functions working in coordination with IDS. 6 Basic Provision of an anti-intrusion mechanism against signature-type and anomaly-type intrusions, which involves distribution of highly reliable pattern files on an as-needed basis. 7 Additional Provision of a function to block attacks to applications (SQL injection, cross-site scripting, etc.). Non-functional Requirements (description provided only when relevant requirements given) Availability Basic Implementation of pass-through (by-pass) circuits to avoid breaks in the network even in the case of equipment failure (this requirement applies to in-line installation). Availability Basic Buildup of log shall not result in functional stoppage. Security Basic Capability of the network type IDS to operate in stealth-mode. - The content of this section corresponds to the following items in the Standards for Information 185 Security Measures for the Central Government Computer Systems: 1.5.1.1, 2.1.1.4, 2.2.4.2 - The content of this section corresponds to the following segments in the physical configuration model: S1 5.9.7.6. Network Connection Monitoring Function A network connection monitoring function provides methods to defend a particular network against a menacing terminal (PC) by controlling the connection between them. Functional Requirements 1 Basic Provision of a quarantine function to protect the network: the function performs a security inspection before a terminal (or other device) is connected to the network, and in case of failure it tries, in cooperation with other network devices, to isolate the failed terminal from the network. 2 Basic Introduction of a mechanism to detect the connection of an unauthorized terminal or other device to the network, in which case the terminal (or other device) is indicated in the specified area on the monitor screen, or a message is displayed. 3 Basic Provision of a function to isolate a terminal that failed security inspection from the network (quarantine), and only permits the use of the server exclusively utilized for security update purposes. 4 Basic Capability to implement a quarantine network by utilizing software (or other techniques) to test security compatibility of terminals. 5 Basic Provision of functions to avoid unauthorized connection of terminals (authentication function by means of IP/MAC address, or that in compliance with IEEE802.1x, etc.). 6 Basic Capability to issue warnings to the administrator regarding the following events/situations: application situation of security patches on the OS, settings of OS firewall, settings of screen saver and log-in password, introduction status of anti-virus software, pattern update status of anti-virus software, real-time scan settings of anti-virus software, checking status of arbitrarily introduced software, and occurrence and isolation status of the terminal that failed quarantine inspection. Basic Provision of a function to analyze and summarize information regarding the 7 number of connected terminals and the security status for each of them during a designated period, and output a report in text format. Non-functional Requirements (description provided only when relevant requirements given) Availability Basic Provision of redundancy in network connection monitoring functions, which guarantees continued operation even when the network devices (e.g. server) with network monitoring capability fail. Availability Basic Capability to isolate/stop the network connection monitoring function with ease if any trouble occurs in it. That is, such a situation shall not take place in which no PC – with connection authority given by the network connection monitoring function – is connected to the network. Extendability Basic Capability to connect more than one terminal. Related technologies 186 Institute of Electrical and Electronic Engineers 802 シリーズ A standard that stipulates the user authentication method at access points: defined by IEEE (Institute of Electrical and Electronics Engineers) LAN standardization committee (802 committee). (Specifications) http://www.ieee802.org/1/pages/802.1x.html - The content of this section corresponds to the following items in the Standards for Information IEEE802.1x Authentication Security Measures for the Central Government Computer Systems: 2.1.1.2, 2.1.1.4, 2.1.2.3, 2.2.4.1 - The content of this section corresponds to the following segments in the physical configuration model: S0, S1, and S6 5.9.7.7. Anti-Virus Gateway The anti-virus gateway provides network protection functions against viruses, worms, and spyware that can intrude by way of e-mail (SMTP, POP3, IMAP), file transfer (FTP), and Web (HTTP) traffic, and also provides file scanning functions on attached files, whereby the execution of these functions should not compromise overall performance of the network. Functional Requirements 1 Basic Capability to automatically update virus protection by downloading the latest pattern files. 2 Basic Provision of a function to update the anti-virus pattern file immediately after the release of a new version, either by the provider’s initiative (“push” update) or administrator’s initiative (“pull” update). 3 Additional Capability to connect to the virus checking port using a bridge: the port (except for the administration port) does not require IP address assignment. Non-functional Requirements (description provided only when relevant requirements given) Availability Basic Distribution of the new pattern file against the new breed of viruses within 24 hours after its detection. - The content of this section corresponds to the following items in the Standards for Information Security Measures for the Central Government Computer Systems: 2.1.2.2, 2.4.3 - The content of this section corresponds to the following segments in the physical configuration model: S1, S2 5.9.7.8. VPN Encryption Function VPN (IPSecVPN, SSL-VPN, etc.) provides functions to encrypt communication traffic. Functional Requirements 1 Basic The code language used must comply with those stated in the “Code Usage Policy for Procurement on Information System for Cabinet Office and Ministries” (Board of Managers, Liaison Conference for the Ministries and Agencies Concerning Administration Information System (Inter-ministerial Meeting of Government Information Systems Division-Directors), Feb. 28, 2003) 2 Basic Capability to use multiple encryption keys, which should be used selectively for every group and for every person/party located on the other side of information link. 187 3 Basic Capability to perform encrypted encoding/decoding operations. communication without the need of Non-functional Requirements (description provided only when relevant requirements given) Performance Basic Execution of the above described procedures shall not cause significant delays in normal business operations. Related technologies Encryption AES(Advanced Encryption Standard) Standard The U.S. Government’s next generation standard for encryption methods, adopted by the National Information System for Science and Technology (NIST). The new standard was established in March 2001 (FIPS PUB197) to replace DES (established in 1977) due to the concerns about insufficient security. (FIPS PUB197) http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf Encryption 3DES(Triple - Data Encryption Standard) Standard An encryption method developed by IBM. A higher level of security has been achieved by the triple application of DES (a secret key cryptosystem developed by IBM). Electronic X.509 Certificate. Certificate A standard for open key certificate established by ITU-T (one of X500 directory series included in ISO/IEC international standards). The latest version published in 1997 (X.509v3) added an extension area in the certificate for arbitrary functional enhancement. X.509v3 was revised in 2000 to bring higher clarity to the quick method of expired information notification to the user and attribute certificate definitions. - The content of this section corresponds to the following items in the Standards for Information Security Measures for the Central Government Computer Systems: 2.1.1.6,2.2.4.1,2.2.4.2,2.2.4.3 - The content of this section corresponds to the following segments in the physical configuration model: S0 5.9.7.9. HTTPS Encryption Function The HTTPS encryption function represents the mechanism to combine TLS encryption protocol to enhance security of HTTP communication. Functional Requirements 1 Basic HTTP encryption is applied in the HTTP servers made public on the Internet where the need to prevent tampering and tapping of user-server communication is considered important. In such environment, the HTTP server is required to rigorously restrict the range of the users authorized to access browsing the site, and for uploading data through HTTP traffic. 2 Basic The code language used must comply with those stated in the “Code Usage Policy for Procurement on Information System for Cabinet Office and Ministries” (Board of Managers, Liaison Conference for the Ministries and Agencies Concerning Administration Information System (Inter-ministerial Meeting of Government Information Systems Division-Directors), Feb. 28, 2003) 188 3 Basic Capability for use with several different Web browsers. 4 Basic Capability to apply the SSL server and client authentication technique when data of special importance is processed (e.g. uploading). 5 Basic Authentication history and HTTP communication log after authentication shall be recorded and stored for a specified period. 6 Basic As an alternative to the management method of the communication log stated in the previous item, the trail management function may be used. Non-functional Requirements (description provided only when relevant requirements given) Performance Basic Execution of above described procedures shall not cause significant delays in normal business operations. Performance Basic In case an attempt is due to incorporate TSL in an HTTP server that suffers heavily concentrated access, an introduction of a dedicated TSL server shall be considered. Availability Basic In case a dedicated TLS server is already in place, stoppage of the server (due to failure, hazard, etc.) shall not affect operations of HTTP servers. Related technologies Security TLS (Transport Layer Security) Protocol A protocol that provides encryption functions for communication requiring security. It is implemented as a wrapper for TCP communication, thus it is independent of the upper level protocols. (TSL1.1/RFC4346)http://tools.ietf.org/html/rfc4346 - The content of this section corresponds to the following items in the Standards for Information Security Measures for the Central Government Computer Systems: 1.3.1.1,1.3.1.2,1.3.1.3,2.1.1.4 - The content of this section corresponds to the following segments in the physical configuration model: S0, S1 5.9.7.10. File Encryption Function This function provides methods to encrypt files. Functional Requirements 1 Basic Encryption functions shall be applied to terminals both within and outside the ministries. 2 Basic Capability to encrypt a variety of document files including those created by word processing and spreadsheet software. 3 Basic The code language used must comply with those stated in the “Code Usage Policy for Procurement on Information System for Cabinet Office and Ministries” (Board of Managers, Liaison Conference for the Ministries and Agencies Concerning Administration Information System (Inter-ministerial Meeting of Government Information Systems Division-Directors), Feb. 28, 2003) 4 Basic Capability to encrypt shared information on the server on a department/project basis, and to block access from third parties by imposing access controls. 5 Basic Provision of simple operations for encrypting and decoding. 6 Basic Capability of automatic encryption of hard disk contents. 189 7 Basic 8 Basic 9 Basic 10 Basic Provision of simple and easy file encryption methods in preparation for storage in external media. Provision of a function to block taking information out of the ministries without encryption – for example, by disconnecting external media (USB memory, MO, FD, external HDD, etc.) out of the terminals installed within the ministry. Capability of automatic data encryption to be performed when the data is transferred for storage to the external devices (e.g. USB memory, MO, FD, external HDD, etc.) connected to the terminals installed in the ministry. Capability to decode encrypted files that were transferred from the devices within the ministry to those in places out of the ministry without relying on a specially-installed encryption software installed on the latter (password entry for authentication may be a required step). Non-functional Requirements (description provided only when relevant requirements given) Performance Basic Execution of the above described procedures shall not cause significant delays in normal business operations. Backup Basic Provision of a fail-safe mechanism that enables decoding of an encrypted file even if the terminal in which the encryption were performed fails – for example, through the use of a backed-up decoding key. - The content of this section corresponds to the following items in the Standards for Information Security Measures for the Central Government Computer Systems: 2.1.1.6,2.2.4.1,2.2.4.2,2.2.4.3 - The content of this section corresponds to the following segments in the physical configuration model: S0, S3, and S6 5.9.7.11. Trail Management Function Trail management provides log management functions for controlling system/network users (and programs). These include functions for login/logout management. Functional Requirements 1 Basic Provision of functions to gather and store log information regarding the operations performed in client PCs and servers - mail delivery, Web access, file operation, printing, etc. 2 Basic Capability to define the target information assets prior to the start of log gathering. 3 Basic Capability to gather such trail information as the name of accessed information assets, user name that accessed it, types of manipulation performed on it, and date and time of the access event. 4 Basic Capability to automatically output the log for centralized management. 5 Basic Provision of a function to perform statistical analysis of the gathered trail information, and to output the results (e.g. in graphic format). 6 Basic Provision of functions to perform log information gathering, long-term storage of it, and backing it up, as well as the ability to browse it on an as-needed basis. 7 Basic Provision of a function to output the results of log gathering and summarized information either in CSV or PDF format. 8 Basic Provision of a function to output the compiled summary of log information in graphical format. 190 Non-functional Requirements (description provided only when relevant requirements given) Security Basic Provision of a function to protect the gathered log information against any attempt of tampering. Security Basic Provision of appropriate measures – access control, encryption, anti-tampering and tampering detection etc. - to protect trail logs against fraudulent use by third parties. Extendability Basic Capability to handle OS logs (normal/error log of the system and applications) in the same fashion as above. Performance Basic Execution of log gathering operations shall not cause significant delays in log output functions. Backup Basic Provisions of appropriate measures (e.g. making a backup) to protect the trail log against file corruption and deletion. - The content of this section corresponds to the following items in the Standards for Information Security Measures for the Central Government Computer Systems: 1.3.1.1, 1.3.1.2, 1.3.1.3, 2.1.1.4 - The content of this section corresponds to the following segments in the physical configuration model: S0, S1, and S2 5.9.8. Functional/Non-Functional Requirements for Job Management Job management provides functions to maintain scheduled execution of business operations, which include defining the procedural flow of routine tasks and triggering jobs on/at a given day/time or at a specified event. Functional Requirements 1 Basic Capability to define a system operation calendar. 2 Basic Capability to schedule the series of programmed job execution in accordance with the system operation calendar, and to execute them automatically. 3 Basic Capability of centralized management of job operation controls. 4 Basic Capability to record the situation under which the jobs are performed and record the execution history as log information. 5 Basic Capability to monitor job execution status. 6 Additional Capability to start job execution triggered by such events as a timer, file reception, and file modification. 7 Basic Capability to manage a day by [48]-hour system. 8 Additional Capability of blanket definition/modification of a large number of jobs. Non-functional Requirements (description provided only when relevant requirements given) Security Additional Capability to restrict the range of available functions (definition, execution, reference, etc.) depending on the authority given to a user. Backup Basic Capability to backup the calendar definitions and job definitions. 191 5.9.9. Compatibility with virtualization Functional Requirements (compatibility with virtual environment) 1 Basic Capability to deploy an equivalent set of software to achieve the same level of performance in a virtual environment as in the physical server environment. The virtual environment consists of such elements as a virtual guest server, virtual storage, and a virtual network realized through the use of virtualization mechanisms. 192 5.10. EIP 5.10.1. Definition EIP represents the “Enterprise Information Portal” that provides functions conducive to perform effective IT-system based business operations, including the function to control information and applications centrally for delivery to Web browsers running on the terminals. It delivers an assortment of views on a screen linked to contents and applications appropriately assigned to the user depending on his/her role in the portal site. EIP Functions & Services Function & Service Definition Portal Site function Functions to create an integrated view as a Web page (portal site) comprising of multiple applications – business applications, groupware applications, information contents (documents, images, animations, etc.) – capable of transmitting/receiving information to/from other Web browsers. Personalize function A function to identify each portal site user and his/her role, and create a combination of contents and applications most suited to him/her, enabling delivery of it in a unified screen or view. Application integration A mechanism to achieve on-portal site integration of the job-related function roles of a portal site user and applications, thus enabling close linkage among them. The target applications include such business packages as groupware, business intelligence (BI), customer relationship management (CRM), and enterprise resource planning (ERP), as well as XML Web service applications. Management An EIP related management function. It includes user management, contents management, auditing, other various management functions and backup. 5.10.2. Portal Site Function Functional Requirements 1 Basic Capability to perform user authentication/authorization on a portal site basis, and the capability to perform these tasks in coordination with other directory services external to the server. 2 Basic Customization: allowance to freely change the combination of information contents and applications incorporated in the portal site, and to rearrange the screen layout. 3 Basic Search: a function to search, by entering a keyword to a search field on the portal site screen or a search application, the objective through the information contents and application data accumulated on the portal site, and report the search result information on the site’s screen. 4 Basic The portal site shall have a capability to respond to accesses from the Web browser installed on such devices as PC, PDA, and mobile phones. 193 Non-functional Requirements (description provided only when relevant requirements given) Availability Basic Provision of system configuration that has multiplexed portal sites over a plural of server hardware systems, which ensures uninterrupted system operation even in the case of failure in one server utilizing other servers. Load Basic Provision of system configuration with its portal site servers balancing multiplexed over a set of plural server hardware systems, which enables to balance the load of access request to the site. Performance Basic Provision of enough performance capacity that enables to process the amount of user access requests arriving at the portal site simultaneously. Related technologies Directory service protocol LDAP (Lightweight Directory Access Protocol) 5.10.3. Personalize function Functional Requirements 1 Basic Customize function: customizing capability to combine the required contents information and applications, and to define/edit the screen layout depending on the user’s role in business operation. 2 Basic Personalize function: capability to change the set of information (selection of views and applications) in accordance with the attribute information of the logged on user. 5.10.4. Application integration function Functional Requirements 1 Basic Portlet collaboration: capability to link/integrate portlets – those within the user’s server, as well as remote portlets that are openly released as Web services – to facilitate operating applications and contents placed on other servers. 2 Basic External connection: capability to link business systems, business applications, and databases that are connected to the network and operating within and outside of the common infrastructure. 3 Basic Web service collaboration: capability to perform linkage/integration operations on the screen of the portal site in coordination with the applications provided as a Web service. 194 4 5 Basic Provision of functions to integrate the following types of groupware applications on the portal site screen. 1) Scheduling function 2) Meeting room, bulletin board 3) Electric mail 4) Workflow of routine tasks (attendance management, expense calculations, etc.) 5) Database searching 6) Document management Additional Application collaboration: provision of a function to perform integration/linkage operations on the screen of the portal site in coordination with application package products (business intelligence (BI), customer relationship management (CRM), and enterprise resource planning (ERP)). Related technologies Web service related protocols SOAP WSDL 5.10.5. Management Functional Requirements 1 Basic User management: capability to manage (register/edit/delete) the user ID and personal information of the users that have access authority to the portal site. 2 Basic Audit: capability to browse the access history (log) to the contents and applications within the portal site. The access history shall include such information as: date and time, information to identify the computer accessed, and the access result (success/failure). 3 Additional Single sign-on: Provision of a function to authenticate and authorize the user automatically, to access desired contents/applications with a single action (i.e. entry of user ID and password) done by the user when he/she tries to login to the portal site. This involves contents and application management in association with the user ID and password for user authentication and authorization. Non-Functional Requirements (description provided only when relevant requirements given) Backup Additional Provision of a system configuration that enables backing up the information contents and management data contained in the portal site. 195 5.11. Open Web Server 5.11.1. Definition The Open Web Server distributes information content through the Internet, and its primary use is as a tool to disclose information to the general public as well as to enterprises. Because it operates 24 hours a day and 7 days a week embracing a variety of access from unspecified clients, it is under constant threat from all sorts of possible malicious attacks (data tampering, denial of service, information tapping, unauthorized promotion/denial of access authority, etc.). Therefore, measures must be adopted to protect assets from those attacks, and to prevent security events/accidents from occurring. These measures are implemented in a high-security segment with firewall isolation, or DMZ (DeMilitarized Zone), which lies in between the external network (the Internet) and internal network. In light of possible IPv4 address depletion problem, previous considerations must be due for proper coexistence and parallel usage of IPv4 and IPv6. This involves careful implementation of operation/management/monitoring/maintenance methods, at the design stage as well as in the purchase of equipment, and security measures for running various devices used on open Web server devices. General user (citizens, enterprises) Internet Communication within the Cabinet Office and Ministries Mobile access server Mail server External Proxy server Open DNS server External f irewall DMZ Load balancer (load balancing equipment) Open Web server Internal f irewall DMZ Intranet Internal Proxy server Internal DNS server Figure 5.11-1 CMS equipment Open Web Server Configuration 196 Functions and services provided by the Open Web Server Function & Service Definition WWW service Refers to the contents distribution services utilizing HTTP protocol - documents, images, and other data - conducive to information disclosure to the general public and enterprises. FTP service Refers to the services utilizing FTP protocol that enables file transfer (upload and download) between the terminals located outside the ministries and the open Web server. The services shall be mainly used for distributing/uploading large size files, or frequently updated files. Content management The Content Management System (CMS) provides services system (CMS) such as production and management of Web-based digital content – released/distributed from the WWW services running and performs on the open Web server – distribution/review/maintenance services for the open Web server. CMS shall include functions that assume due considerations for compatibility with the internal control and accessibility. -Assumed users/usagesServer manager Server management/ audit -Assumed users/usagesInternet connection users Web site browsing File upload/download -Assumed users/usagesSite (information distribution) manager Allocation and authority settings of information distribution Operation management tool/ audit tool GUI/CUI Web browser FTP client Load balancer (load balancing equipment) WAF(Web Application Firewall) FTP service WWW service Access log Operating system Open Web server Figure 5.11-2 Schematic Overview of Open Web Server 197 5.11.2. WWW Service Functional requirements 1 Basic This function returns contents stored in the Web server responding to requests from users (e.g. Web browser clients). It shall include such additional capabilities as: running server-side script language (SSI, etc.) embedded in the content to convert and send data (HTML, etc.), and running external programs on the server that dynamically format and send data (HTML, XML, images, etc.). 2 Basic User authentication/authorization: provision of a function to identify the user, when an access is made to an open site, and gives authentication accordingly – i.e. allows access to, and usage of the site only for those who already have been authorized, and denies access to others. It also shall be able to set the access range and operation limit for each user within the open Web site, and to grant authorization accordingly. Additionally, the authentication/authorization procedures shall be capable of performing in coordination with external directory services. 3 Basic WAF (Web application firewall): Provision of the capability to detect improper data indicative of malicious attacks (such as SQL injection and cross-site scripting) and block these accesses, which requires rigorous inspection of transmitted/received information to/from the applications and Web pages on the open Web site. 4 Additional Server certificate and path encryption: Provision of a function to install a server certificate (server’s open key and server information), and to encrypt transfer data using SSL protocol. The encryption method shall have encryption strength compatible with those code languages listed in the e-Government recommendations. 5 Basic File format management for delivery: Capability to define a set of file formats for use in file delivery from a Web site, and inhibit those that are not included in that set from being used in file transfer. 6 Basic Allocation of delivery file: Capability given to the Web administrator to allocate contents and set access authority for delivering information through the intra-net and open Web site, and execute quick check/test on the latest update information of the contents. 7 Basic Access log record: Capability to record an access log for the accumulation of access history files (who, when, what, and the last access to the information, etc.). The log information shall be recorded in a way that allows selection/specification of type and order of information to meet the requirements of HTTP communication, and should be capable of outputting in either W3C extended log file format or NCSA common log file format. 8 Additional Audit: Capability to compile an auditing report from the stored stock of access logs in different perspectives (for each audit event, for different time windows, for each user,…). 198 9 10 11 Additional Efficiency measurement: Provision of the capability to measure the work load on a WWW site (number of concurrent connections, average request frequency, etc.), processing efficiency (HTTP process throughput, response time, etc.), and resource usage status (CPU utilization ratio, etc.). Basic Session management: Provision of a function to issue a session ID needed for the Web application to perform safe session management, and to maintain the session information. Basic Management interface: Provision of GUI (Graphical User Interface) or CUI (Character-based User Interface) tools to help perform various management operations (add/edit/delete a user account, setting of site authority, setting of file types for delivery, auditing, performance monitoring, etc.) from the management terminal installed in the internal network. Provision of a set of API‘s (Application Program Interface), used to invoke management tasks for programs, is also required. 199 Non-functional Requirements (description provided only when relevant requirements are given) Performance Basic Provision of sufficient processing capacity - in terms of the number of concurrent connections, SPECweb value, etc. - to meet the client’s (mainly Web browser) requirements. Availability Basic Provision of a system configuration (clustering, etc.) that enables continued processing of subsequent request even after a failure in server hardware or middleware. Upgradability of Basic Capability to secure sufficient processing capacity – through processing increasing/decreasing server resources, and additional installation performance or removal of servers – to meet the changing load requirements (number of concurrent connections, increasing/decreasing number of accesses) without needing to stop services. Upgradability of Basic Provision of a system configuration that enables the addition of SSL performance performance enhancement mechanisms for SSL protocol (for higher encryption and decoding performance, e.g. SSL accelerator). Regular delivery of Basic Delivery of vulnerability and security patch information to the security patch server administrator regularly (for example, once a month). This information to service shall be included in the information delivery target middleware and software provided by the information security service vendor, and OS may require affiliation to some kind of information delivery service. Application of Basic Capability to perform the following procedures: application, test security patch to and verification, and situation-dependent cancelling (deletion) of middleware and security patches to the operating system and middleware OS distributed by Web page. Service delivery Basic Capability of service delivery on a “24 hours a day / 7 days a time zone week” basis. Backup, Basic Capability to backup data on the open Web site (distributed restoration contents and server configuration information) without needing to stop Web site operations, and to restore the site quickly using the backup data. Remote Basic Provision of a system configuration that enables the performing of management management tasks targeted at an open Web site from the administrator terminal implemented in the internal network. Load balancing Basic Provision of a load balancing function (a device) implemented on the front side of the open Web server, and the capability to realize a load-balanceable configuration using it. 200 Related technology Web server's client-to-client (Web browser)communication protocol Web page description language Technology to run external program on the server Server-side script language Unit for Web processing efficiency measurement Authentication scheme Directory service protocol Path encryption protocol Standard for sending/receiving various types of files as e-mail, or using HTML protocol Log file format Monitoring, Control Mechanism/Protocol HTTP (Hyper Text Transfer Protocol) HTML (Hyper Text Markup Language) This markup language has been standardized as HTML 4.01specifications (W3C recommendation, 24 Dec.1999). CSS (Cascading Style Sheets) This style sheet has been standardized as CSS2.1 specifications (W3C recommendation, 9 Sep. 2009). CGI (Common Gateway Interface) CGI has been standardized as RFC3875. Java Servlet ASP.NET (Active Server Pages for .NET) SSI (Server Side Include) PHP (Hypertext Preprocessor) JSP (Java Server Pages) SPECweb Basic Authorization Digest Authorization LDAP (Lightweight Directory Access Protocol) SSL(Secure Socket Layer) MIME(Multipurpose Internet Mail Extension) W3C extended log file format NCSA common log file format SNMP (Simple Network Management Protocol) WBEM (Web-Based Enterprise Management) 201 5.11.3. FTP Service Functional requirements 1 Basic Capability to provide server-side file transmission/reception services for file transfer practice between the client PC and the open Web server. 2 Basic User authentication/authorization: Provision of a mechanism to identify the user, and authorize/deny the user the ability to perform specified operations and access to the targeted files and folders based on the authority given to him/her. These authentication/authorization procedures shall be capable of performing in liaison with the OS’s access control functions and external directory services. 3 Basic Transmission/reception data encryption: The encryption method shall have the encryption strength compatible with those methods listed in the e-Government recommendations. 4 Basic User separation: Capability to separate the area (folder) for uploading/downloading on an user-by-user basis, and isolate it from those used by other users. Capability to create a user folder in accordance with the structure specified, and to define the folder capacity and maximum file size allowed for transfer on a user-by-user basis. 5 Basic Access log record: Capability to record and accumulate operation history as a series of log files (who, when, what, and the types of operation). The log information shall be recorded in the way that allows for the selection/specification of the type and order of information to meet the requirements of FTP communication, and should be capable of outputting in either W3C extended log file format or NCSA common log file format. 6 Basic Audit: Capability to compile an report serviceable for auditing from the stored stock of usage status logs in different perspectives (for each audit event, for different time windows, for each access user,…). 7 Basic Client access: Capability to access an FTP site from a client PC utilizing a Web browser or CUI (Character-based User Interface). 8 Additional Efficiency measurement: Provision of a capability to measure processing requests (number of concurrent connections, etc.), processing efficiency (transfer rate, etc.), and resource usage status (CPU utilization ratio, waiting status of I/O queue, etc.). 9 Basic Management interface: Provision of methods to perform various management operations - add/edit/delete a user account, setting of site authority, setting of file types for delivery, auditing, performance monitoring, etc. - from the management terminal located on the internal network. If the management method involves the use of a GUI (Graphical User Interface) or CUI (Character-based User Interface), a set of APIs ((Application Program Interface) shall be provided for the programs to access management tasks. 202 Non-functional Requirements (description provided only when relevant requirements are given) Performance Basic Provision of sufficient performance capacity to the process uploading/downloading load of files (number of concurrent connections, data transfer capability, etc.). Data storage Basic Provision of sufficient disk area capacity for the secure capacity storage of uploaded/downloaded files. Availability Basic Provision of a system configuration that allows for continuous normal processing of subsequent requests by surviving servers even after a failure in a single server hardware, OS, and middleware. Expansibility of Basic Capability to expand free space for storage of disk area uploaded/downloaded files within a given period of time (this may be required when capacity shortage is imminent). Upgradability of Basic Capability to secure sufficient processing capacity – through processing increasing/decreasing server resources, and additional performance installation or removal of servers – to meet the changing load requirements (number of concurrent connections, increasing/decreasing number of data transfer requests) without needing to stop services. Regular delivery Basic Delivery of vulnerability and security patch information to the of security patch server administrator regularly (for example, once a month). information to This service shall be included in the information delivery target middleware and software provided by the information security service vendor, OS and may require affiliation to some kind of information delivery service. Application of Basic Capability to perform the following procedures: application, security patch to test and verification, and situation-dependent cancelling middleware and (deletion) of security patches to the operating system and FTP OS service middleware. Service delivery Basic Capability of delivery on a “24 hours a day / 7 days a week” time zone basis. Backup, Basic Capability to backup data on the file storage area of an FTP restoration site without needing to stop services, and to restore the site quickly using backup data. Remote Basic Provision of a system configuration that enables the management performing of management tasks targeted at an open FTP site from the administrator terminal implemented in the internal network. Load balancing Additional Provision of a system configuration that enables balancing of file transfer load among the servers: i.e. capability to construct an FTP site by combining multiple servers and allocating a larger load to the server with the minimum track record in terms of the volume of data communication. 203 Related technology File transfer protocol Directory service protocol Data encryption protocol in file transfer Log file format Monitoring, control mechanism/protocol FTP (File Transfer Protocol) LDAP (Lightweight Directory Access Protocol) FTPS (File Transfer Protocol over SSL/TLS) SFTP (Secure File Transfer Protocol) W3C extended log file format NCSA common log file format SNMP (Simple Network Management Protocol) WBEM (Web-Based Enterprise Management) 204 5.11.4. Content Management System (CMS) Functional requirements 1 Additional Capability to utilize/include content from existing Web sites in an content production effort. 2 Additional Capability to search and list various contents (text, images, etc.) for browsing/referencing to facilitate content production. 3 Additional Capability to easily produce and control contents, that have standardized and unified page design for controlled accessibility throughout the site, by utilizing templates (such as Web page prototypes). 4 Basic Capability to update contents by editing HTML files. 5 Additional Capability to handle various data formats (PDF, Flash, text, Microsoft Office documents, etc.) for content files. 6 Additional Provision of an authority management function (including authentication and authorization) to assign to specified users or to user groups, the authority to operate on contents. The authentication and authorization functions shall operate in conjunction with other directory services. 7 Basic Capability to register pre-release content files on the Web page, enabling the ability to preview the expected image after release. 8 Additional Provision of a function to automatically carry forward the approval and release process for new content, or a workflow that promotes this process. 9 Additional Provision of a function to automatically release a new content on the open Web server on the scheduled day (the content and release schedule must be defined in advance). 10 Additional Capability to perform such operations as: reference to revision history of content, review older images of content, and rewind the display back to one of the older versions. 11 Additional Capability to browse past actions done by the persons in charge of production/maintenance/presentation of content (who, when, and which operation). 12 Additional Capability to deliver update information for a Web page using one of the update information distribution technologies (RSS feed, ATOM feed, etc.). Non-functional Requirements (description provided only when relevant requirements are given) Availability Additional Capability to continue content delivery using WWW services even in the event of CMS stoppage. Backup, Additional Capability to save backup copies of Web contents even while restoration they are under production or in the process of being delivered. A function shall be provided to rewind the Web content to an older state by restoring from the backup. Related technology Web accessibility criteria Directory service protocol JIS X 8341-3 W3C WCAG (Web Content Accessibility Guidelines) 1.0/2.0 LDAP (Lightweight Directory Access Protocol) 205 5.12. Groupware, File Server, and Mail Server 5.12.1. Definition of groupware, file server, and mail Server The groupware, file server, and mail server are accepted as productivity enhancing mechanisms for organizations as they realize sharing and exchange information among the information system users. These mechanisms provide such facilities as electronic mail, electronic bulletin board, electronic conference room, scheduling, conference room booking, and file sharing. The objective of these facilities is to achieve smoother communication among the users, and thus support information sharing for well-informed policy planning. Figure 5.12-1 Functions and services provided by groupware, file server, and mail server The groupware, file server, and mail server typically provide the following six functions/services. 1) Groupware 2) Electronic mail 3) File sharing 4) Instant messaging 5) Full-text search 6) Web conference 206 Functions and services provided by groupware, file server, and mail server Function & Service Definition Groupware Groupware provides facilities for information sharing among users, and thus contributes to achieving smoother communication. The users can exchange their opinions and information using the electronic bulletin board and electronic conference. Such functions as user schedule management, facility management (e.g. conference room), and To-Do list contribute to enhance routine task efficiency for the users. The groupware also provides functions for managing attribute information (e.g. user ID assigned to each user, and the group he/she belongs), allowing it to be used as an employee directory. Electronic mail Electronic mail provides the users with the means to send/receive an e-mail within the ministry or with external organizations. Standardized protocol for sending and receiving mails is employed, and communication requests from the terminals shall be compatible with SMTP (for transmission) and POP, IMAP (for reception). In light of the need to exchange highly confidential e-mails, this function shall be compatible with encryption and electronic signature. To avoid virus infection via e-mail communication, it shall perform anti-virus functions by checking attached files. Note that the e-mail communication may be provided as a function of groupware. File sharing Refers to the practice of shared use of storage resources among the terminals, making cross-user information sharing easier and quicker. This mechanism includes the shared use of storage areas under the control of file server, enabling file sharing according to the user’s affiliation and authority. Rigorous access control shall be implemented in the file sharing mechanism, and access history shall be recorded in the audit log. Instant messaging Refers to the provision of a real-time message exchange function, whereby the usage status of the users is checked in advance. This function shall not only be able to identify if the user is on-line or off-line, it provides further on-line status information (i.e. enabled/disabled to respond, at/away-from-desk, at conference, etc.), enabling to select the contact method most suited to the situation (telephone/e-mail, instant messaging). Full-text search Refers to the functions to search for a given string among the document database provided by groupware and the stock of document files stored on the file server. The user shall be able to use combined criteria – single of multiple keyword, and logical conditions connecting them (AND, OR, etc.) – and only 207 Web conference the allowed range of the search results shall be presented to the user depending on his authority level. Refers to the functions that allow a plurality of users on the network to have a conference, sharing a common screen and using voice/video communication. It also provides functions to share office documents, and shared use of a virtual whiteboard to which the conference participants are able to write sentences and figures. A Web interface is also provided for booking and managing a Web conference. 208 5.12.2. Functional/Non-Functional Requirements and Standard Technology of Groupware Functional requirements 1 Basic Capability of the user to register/modify/delete the documents posted to electronic bulletin board. 2 Basic Capability to add a link to the posed document (link to a file, table, image, document, etc.). 3 Basic Capability to classify the posted documents based on the information displayed on the document list screen – for each author, for each category, etc. Capability to perform search among the posted documents based on “keywords or other information.” 4 Basic Capability given to the system administrator to define the users with authority to access the bulletin board, and restrict the range of their usage authority. 5 Basic Capability given to the system administrator to delete a document from electronic bulletin board if the document is considered inadequate for public view. 6 Basic Provision of functions to support electronic conferences, where multiple users can post/exchange their opinions on a specific theme. 7 Basic Provision of functions to create multiple electronic conference rooms for each discussion theme, and users’ opinion (posting) shall be recorded as electronic data. 8 Additional Capability to display the series of postings on a specific theme in a hierarchical structure for easy viewing as a single thread. 9 Basic Capability of schedule management on a user-by-user basis. Capability to define and manage the range of users whose schedules will be put on view for others. 10 Basic Capability to browse schedules of multiple of users that belong to the same organization/group, and to search their vacant times. 11 Basic Capability to register repetitive schedules (weekly, monthly, …), with an authority to accept/reject the request for schedule registration. 12 Additional Capability to identify an overlapped portion of a schedule (if any) by means of a symbol or marking. 13 Basic Capability given to the user to refer to the booking status of facilities (e.g. conference room). 14 Basic Capability given to the administrator to manage registration/update/deletion of facilities. The administrator shall be able to assign access authority on facility-by-facility basis. 15 Basic When a user tries to reserve a conference room, he/she shall be able to search for a vacant time zone for the room. The user shall also be able to search for an available room at a specified time window. 16 Basic In synchronization with the booking of a conference room, a notification message shall be sent to those involved by e-mail or other means. 17 Basic Capability to manage To-Do lists created by users. 18 Basic Capability to manage the progress status of tasks (work) registered in the To-Do list, which necessitates the capability to assign the start date, terminal date, and priority information for each task. 209 19 Basic 20 Basic 21 Basic Provision of an electronic telephone directory function as well as the directory for the centralized management of the users. Search capability based on such information as the name, affiliation, telephone number, mail address, etc. - shall be provided as well. Authentication of a user, when he/she tries to use groupware, shall be performed using the user ID and password assigned to each user. Provision of a graphical user interface (GUI) for easy access for users. Non-functional Requirements (description provided only when relevant requirements are given) Availability Additional Adoption of a system configuration that provides enhanced availability, by employing such technologies as redundant servers, clustered software, and replication. Security Basic Capability to exercise rigorous control on each of the functions provided by groupware - e.g. electronic bulletin board, electronic conference room, schedule, facility booking, To-Do list, and electronic telephone directory. Additional Capability to encrypt communication to ensure security. Performance Basic The system design shall assume {approximately 50 thousand} users, and the system configuration shall provide sufficient processing capacity to meet the stated performance requirements. Extendability Additional In view of a possible increase in the number of users, the system configuration shall assume enough flexibility to allow future performance upgrades. Backup Basic Capability to save backup copies of contents created by the user (posting, schedule, booking, tasks, etc.) along with the configuration information. Related technology Directory LDAP (Lightweight Directory Access Protocol) is a standard protocol used for service connection with the directory service. LDAP V3 has been established. protocol Directory LDIF (LDAP Data Interchange Format) defines the file formats used to exchange exchange LDAP account information. format Supplementary note: Groupware, in the broad sense of the term, may include such functions as electronic mail, instant messaging, and Web conferencing. An appropriate specification description shall be adopted in view of the purchase range. 210 5.12.3. Functional/Non-Functional Requirements and Standard Technology of Electronic Mail Functional requirements 1 Basic Provision of a web mailing function, and the capability to create, transmit, and receive mails from electronic mail clients. Requests from electronic mail clients shall conform with SMTP (transmission) and POP, IMAP (reception). Web mail shall conform with HTTP/HTTPS. 2 Basic Mail format shall support an HTML format as well as a simple text format. 3 Basic Functions to sort the mails – based on such criteria as destination and content - shall be provided. The folders used to sort the mail shall be allowed to have a hierarchical structure, enabling easy search by specifying conditions. 4 Basic Provision of an automatic sorting function to given folders based on such information as the sender and the keyword included in the subject. The user shall be able to assign multiple addresses and keywords for sorting mail. 5 Basic The address book shall provide functions compatible with Japanese names and Japanese organization names. 6 Basic Capability to encrypt the body text of a mail and attached files for exchange of e-mails with a high level of confidentiality. Provision of functions for sender authentication, and to give/check an electronic signature. The encryption method and electronic signature shall be compatible with S/MIME. 7 Additional Capability to send a notice of absence to the sender if the receiver is absent. 8 Basic 9 Additional 10 11 Basic Basic 12 13 Additional Additional 14 Additional 15 Additional Electronic mail clients shall have the capability to read and create a mail even when the network is offline. Provision of the mechanism given to the electronic mail clients to avoid erroneous transfer and diverted use of the mail (through copy & paste and printing). Capability to restrict the size of mail boxes provided to the users. Provision of functions to link with groupware’s schedule management and facility booking functions (e.g. automatic mail transmission to members when a schedule is registered). Provision of an option to confirm if the mail has been read. Capability to perform a virus check of the files attached to a mail on the mail server using anti-virus software. For encrypted mails – as it is difficult to for check viruses on the mail server – methods shall be provided to run virus checking on other locations (e.g. terminal). Capability to save archived mails for auditing: this is a measure to avoid unauthorized use of mails and information leaks. Provision of settings that prevent external leakage of ministerial physical information to the outside world (e.g. the IP address of ministry mail server may be leaked by being attached to a mail header). 211 16 Additional The request to send from electronic mail clients shall be authenticated and compatible with SMTP over SSL/TLS, and the request to receive shall be compatible with POP over SSL/TLS, or IMAP over SSL/TLS. Non-functional Requirements (description provided only when relevant requirements are given) Availability Additional Adoption of a system configuration that provides enhanced availability by employing such technologies as redundant servers, clustered software, and replication. Security Additional Capability to verify electronic mails using sender domain authentication to detect malicious mails (avoidance of tampering and spoofing of electronic mails). Additional Provision of mechanisms to prevent erroneous mail transmission: for example, placement of a wait before mail delivery and cancels sending if an error in the destination description is found. Additional Provision of a mechanism to send only the mails authorized by the approver: this applies when handling highly confidential mails. Performance Basic The system design shall assume {approximately 50 thousand} users. Performance specifications shall be made clear in advance, for creation of the system with sufficient processing capacity. Additional The size of the mail box per user shall be at least {100MB}. Extendability Additional In view of a possible increase in the number of users, the system configuration shall assume enough flexibility to allow future performance upgrades. Backup Basic Capability to store backups of mails transmitted and received by the user, as well as the setting information. Related technology Mail SMTP (Simple Mail Transfer Protocol) is a standard protocol used to send an transmission electronic mail. It is used when a user sends an electronic mail to the mail protocol server, and the electronic mail is transferred between mail servers. Mail POP3 (Post Office Protocol) is a protocol used to receive a mail from the server reception where electronic mails are stored. It is used when a user tries to receive an protocol electronic mail from the mail server. The mails are stored and managed on a terminal. IMAP4 (Internet Message Access Protocol) is a protocol used to receive a mail from the server where electronic mails are stored. It is used when a user tries to receive an electronic mail from the mail server. The mails are stored and managed on the mail server. Mail S/MIME (Secure/Multipurpose Internet Mail Extensions) is a standard method encryption used to encrypt an electronic mail, and to create an electronic signature. It is method utilized by the user to encrypt an electronic mail and create an electronic signature. Supplementary note: In terms of the effective use of electronic mails, the configuration of the mechanism to be procured may differ from case to case: for example, intra-ministerial mail exchange and external communication – with external organizations, and mail exchange via the Internet – may 212 require different configurations (e.g. implementation of a mail gateway). Therefore, the procurement planning requires clear specifications regarding the range of the mail exchange (within the ministry, with external organizations, or via the Internet). (Example) [In this procurement, the scope of mail exchange is intended only for intra-ministerial communications.] [In this procurement, the scope of mail exchange includes, not only within the ministry, but also extra-ministerial mail traffic with other ministries and local governments via the Kasumigaseki WAN and the LGWAN.] [In this procurement, the scope of mail exchange includes traffic with private sectors via the Internet, as well as within the ministry and with other ministries.] 213 5.12.4. Functional/Non-Functional Requirements and Standard Technology of File Sharing Functional requirements 1 Basic Provision of file sharing functions among the users. 2 Basic OS standard file management software and Web browser shall be given an access capability to shared resources. 3 Basic Capability to control access by setting graded access privileges to the users depending on the user’s authority. The access control shall have the authority to manage creation, reference, modification, and deletion of files and folders. 4 Basic Capability to record an access log to the shared resources, and output information for the analysis of unauthorized accesses. 5 Basic Capability to encrypt data to be stored on the file server. 6 Basic Capability to create a backup on a regular basis: required for easy restoration in case of data loss by user’s inadvertent operation. 7 Basic Capability to limit available disk capacity for each user, and for each shared drive (management of the used space of disks). 8 Additional Capability to perform a full-text search on all the files stored in the file server. Non-functional Requirements (description provided only when relevant requirements are given) Availability Additional Adoption of system configuration that provides enhanced availability by employing such technologies as redundant servers, clustered software, and replication. Additional Adoption of RAID technology in storage devices as an insurance policy against disk failures. Security Basic Provision of a mechanism to protect the data stored on file servers against information leak and tampering caused by unauthorized accesses. Additional Capability to encrypt communication to ensure security. Performance Extendability Backup Basic System design shall assume that it provides services to {approximately 50 thousand} users. The performance requirements shall be defined clearly in advance to achieve a configuration with sufficient capacity. Additional Capability to process accesses from {300 terminals} simultaneously. Additional The file server shall have an effective capacity equal to, or larger than {100 TB}. Additional In view of a possible increase in the number of users, the system configuration shall assume enough flexibility to allow future performance upgrades and disk capacity expansion. Basic Capability to save backup copies of data on the shared disks, along with the configuration information. 214 Related technology File sharing CIFS (Common Internet File System) is a standard protocol used to share files protocol on a TCP/IP network. 215 5.12.5. Functional/Non-Functional Requirements and Standard Technology of Instant Messaging Functional requirements 1 Basic Provision of a real-time message exchange mechanism, whereby the usage status of the users on the terminal are checked in advance. 2 Basic Capability to manage users by grouping: a contact list (persons on the end of line) specific to each user shall be compiled for message exchange. 3 Basic Capability to display if the persons on the contact list are present or absent by online/offline identification. 4 Basic The status indicators used to show that the person is on-line shall be user-selectable: “ready to respond,” “unable to respond,” “absent from the desk,” and “at conference,” etc. 5 Basic Capability to display user’s attribute information (telephone number, mail address, etc) as well as his presence/absence status. 6 Basic Capability to save the message exchange history (sorted on person-by-person basis on the other end of the line). 7 Basic Capability to exchange messages among three or more users, as well as conduct one-to-one communication. 8 Basic Capability to automatically change, even while in the “on-line” state, the status indicator to “absent from desk” if the user does not operate the terminal longer than a given period of time. 9 Basic This function shall be able to exchange files using the same mechanism as the message exchange, without the need to attach the file to a mail. 10 Basic Authentication of a user, when trying to use instant messaging, shall be performed using the user ID and password assigned to each user. 11 Basic Provision of a graphical user interface (GUI) for easy access for the users. Non-functional Requirements (description provided only when relevant requirements are given) Availability Additional Adoption of system configuration that provides enhanced availability by employing such technologies as redundant servers, clustered software, and replication. Security Additional Capability to encrypt communication to ensure security. Performance Basic System design shall assume that it provides services to {approximately 50 thousand} users. The performance requirements shall be defined clearly in advance to achieve a configuration with sufficient capacity. Extendability Additional In view of a possible increase in the number of users, the system configuration shall assume enough flexibility to allow future performance upgrades and disk capacity expansion. Backup Basic Capability to save backup copies of data (contact lists, etc.) along with the configuration information. 216 5.12.6. Functional/Non-Functional Requirements and Standard Technology of Full-Text Search Functional requirements 1 Basic Capability to search for contents within the Cabinet Office and Ministries that contain the keyword entered by the user. The user shall be able to specify a combined search criteria – single or multiple keywords, and logical conditions connecting them (AND, OR, etc.). 2 Basic Capability to restrict the scope of a user’s search: a user shall be allowed to search only the contents within the Cabinet Office and Ministries on which he/she has the access authority. 3 Basic The targets of search shall include: documents created by office applications installed on the server (word processors, spread sheets, presentation tools, and others), document database for groupware (postings on electronic bulletin board, etc.), and XML/HTL files on Web sites. 4 Basic Capability to limit or select the scope of target information – e.g. only the data stored on the file server. 5 Basic Capability to perform synonym search (search using a word similar to the keyword given). Data shall be provided for synonym search, and the dictionary shall be maintained by the administrator. 6 Basic Capability to display the search result information as a list, and the user can select an information item from the list for display and then save the relevant information. 7 Additional Capability to collect data that may be used as target information for searching, by accessing the file servers, groupware, and Web site within the Cabinet Office and Ministries on a regular basis. 8 Additional Capability to extract texts for analysis from the collected resources such as text/HTML/XML files and documents created by office applications. 9 Additional Capability to compile a search information index based on the results of analysis, which can accelerate searching. Non-functional Requirements (description provided only when relevant requirements are given) Availability Additional Adoption of a system configuration that provides enhanced availability by employing such technologies as redundant servers, clustered software, and replication. Security Basic Capability to restrict the scope of a user’s search: a user shall be allowed to search only the contents on which he/she has access authority. Additional Capability to encrypt communication to ensure security. Performance Additional Provision of a tolerance against the attacks from the users that threaten security (e.g. SQL injection). Basic System design shall assume that it provides services to {approximately 50 thousand} users. The performance requirements shall be defined clearly in advance to achieve a configuration with sufficient capacity. 217 Extendability Backup Additional In view of possible the increase in the number of users, the system configuration shall assume enough flexibility to allow future performance upgrades and disk capacity expansion. Basic Capability to save backup copies of data (index, etc.) along with the configuration information. 218 5.12.7. Functional/Non-Functional Requirements and Standard Technology for Web conference Functional requirements 1 Basic Capability given to multiple of participants on the network to have a Web conference sharing a common screen on the browser. 2 Additional Capability to have voice conversations and video conferences through the use of microphones, speakers, and Web cameras available on the terminal. 3 Basic Capability to confirm, on the screen, the list of the users participating in the Web conference. 4 Basic Capability given to all participants to share the terminal screen designated by the presenter. 5 Basic The mode of screen sharing shall allow selections depending on the presenter’s convenience – full-screen sharing and partial screen sharing (i.e. only the screen of a specific application is shared). 6 Basic Provision of a virtual whiteboard to which any of the participants can freely write characters and figures: it is shared by the participants to help develop a discussion. 7 Basic Provision of a mechanism to book Web conferences from the browser, and send an electronic notification mail to the user who will chair the conference. 8 Basic Provision of a function to define a password required to log on to the conference. The user shall be able to define it when booking the Web conference, as well as the conference name, date and time, and the number of participants. 9 Basic Capability to book a series of repetitive Web conferences at one time, on an “every day,” “every week,” “every month,” and “every year” basis. 10 Basic Provision of a function to display the lists of Web conferences for easy reference: on-going Web conferences, those that have already closed, and those reserved. 11 Basic Capability, given to the user who will chair a conference, to see the list of his Web conferences and detailed information thereof. Non-functional Requirements (description provided only when relevant requirements are given) Availability Additional Adoption of a system configuration that provides enhanced availability by employing such technologies as redundant servers, clustered software, and replication. Security Basic Capability to define different password for each Web conference, enabling only the users who received the password notification in advance to participate in the conference. Additional Capability to encrypt communication to ensure security. Performance Basic System design shall assume that it provides services to {approximately 50 thousand} users. The performance requirements shall be defined clearly in advance to achieve a configuration with 219 sufficient capacity. Additional The system shall assume that {approximately 500 users} will participate in a Web conference simultaneously. Extendability Additional In view of the possible increase in the number of users, the system configuration shall assume enough flexibility to allow future performance upgrades and disk capacity expansion. Backup Basic Capability to save backup copies of information related to the Web conference (configuration information and others). Related technology Distributed WebDAV (Web-based Distributed Authoring and Versioning) – a file file system management protocol (an extended version of HTTP) for use in a Web-based protocol distributed file system. IETF RFC 2518. 220 5.13. Integrated Account Management, Authentication, Authorization (Access Control) 5.13.1. Definition of Integrated Account Management, Authentication, Authorization (Access Control) Integrated Account Management, Authentication, and Authorization (Access Control) provides a mechanism to manage information system users in an integrated and uniform fashion. It confirms the identity of a user (to authenticate him with his ID), and controls his/her access to resources according to the level of authority given to him/her. Figure 5.13-1 Functions and services provided by Integrated Account Management, Authentication, Authorization (Access Control) Integrated Account Management, Authentication, and Authorization (Access Control) typically provides the following five functions/services. 1) Integrated account management 221 2) Directory linkage 3) Web single sign-on 4) Desktop single sign-on 5) OS access control These functions and services constitute a mechanism to manage account information in an integrated fashion, and realize a single sign-on environment that contributes to the enhanced convenience for users. The integrated directory information may further find its applications in the electronic telephone directory within the organization, a shared address book for the mail system, and a destination address search for instant messaging. Functions and services provided by Integrated Account Management, Authentication, Authorization (Access Control) Function & Service Definition Integrated account Refers to the provision of functions to manage user authentication management information (user ID, password) and attribute information (group, affiliation) in an integrated fashion. The account information, under integrated control, is provided – automatically or manually - to the related systems and directories based on the pre-defined policies (provisioning function). It also provides a workflow function that supports various management tasks (i.e. tasks related to account management). Directory linkage In an environment where account information is stored in multiple of directories in different formats (RDB, LDAP, CSV file), a Directory Linkage realizes coordination among these directories by providing connector functions (used for connection with various directories and databases) and through attribute conversion (data conversion/mapping). Web single sign-on Refers to the provision of methods to manage the authentication process of multiple Web applications and access control in an integrated fashion, thus realizes single sign-on. The user has to only log in to the Web once with a single sign-on: this enables the user to utilize all the accessible Web applications without the need to log in to each, one by one. It also provides functions such as: access history log to Web applications, generation of re-authentication request when a time-out occurs. Desktop single sign-on Refers to the functions that enable the user to log in to various applications – the OS running on the terminal, groupware, Web applications, and C/S type applications – by performing a single log in procedure (i.e. single sign-on). The user only has to log in to the desktop once through a single sign-on: this enables the user to utilize all the accessible applications that run on the terminal without the need to log in to each, one by one. 222 OS access control Refer to the functions to execute access control procedures over the OS resources (files, network, user, etc.) in accordance with the pre-defined access control policies. The access control policies are managed in an integrated fashion, and are applied collectively to each of the systems to be managed. It also collects and stores access history information - when, who, to what resource, and success/failure – as an audit log. The access control policies may be applied, as well as to the ordinary users, to those with privileges (so called administrator users) in accordance with this type of work. 223 5.13.2. Functional/Non-Functional Requirements and Standard Technology of Integrated Account Management Functional requirements 1 Basic Provision of a function to register/modify/delete account information in an integrated fashion. 2 Basic Capability to automate the life cycle management of account information by utilizing pre-defined policies to register/modify/delete account information. 3 Basic Provision of a mechanism to automatically provide the changes in one system (user registration, attribute etc.) to the systems in destination address (provisioning function), whereby the changes are provided based on the defined policies. 4 Basic Capability to restrict the scope of available user IDs based on given restrictions (e.g. naming rules, period of validity, etc.). In terms of passwords, this function shall also place restrictions on the length of the string, types of characters, and period of validity. 5 Basic Provision of a mechanism to apply proposed changes in account information (registration, modification, deletion, etc.) to various OSs and directories after obtaining approvals through the workflow. 6 Basic Capability to place usage control on a user’s ID: suspension (deactivation) and resumption (activation). 7 Basic The user shall be authorized to change or reset his own password (self-care). 8 Basic Essential operations – addition, modification, deletion in account information and policy – shall be recorded in the audit log. 9 Additional Capability to display the content of audit logs in an easy-to-read report format. Non-functional Requirements (description provided only when relevant requirements are given) Availability Additional Adoption of a system configuration that provides enhanced availability by employing such technologies as redundant servers, clustered software, and replication. Security Basic Provision of a mechanism to allow access to account information only to authorized administrators. Basic Capability to protect account information by setting appropriate levels of access authority according to the roles of the administrator and his/her scope of management objectives. Basic Capability to identify a user ID that has been out of use for a long time, and invalidate/delete it. Additional Capability to encrypt communications. Performance Basic The system will manage [approximately 50 thousand] accounts, and in the period of personnel revisions, will have to process a large number of user attribute modifications in a short period of time. The system configuration shall have sufficient processing capacity in view of the stated performance requirements. 224 Extendability Backup Additional As the targeted system expands and the user population grows, the number of accounts is also expected to increase. The system configuration shall assume enough flexibility to allow future performance upgrades. Basic Capability to save backup copies of account information and policies. Related technology Directory LDAP (Lightweight Directory Access Protocol) – a standard protocol used to service access connect to directory services. LDAP V3 has been established. protocol Directory LDIF (LDAP Data Interchange Format) – a file format used to exchange service LDAP’s account information. interchange format Provisioning SPML (Service Provisioning Markup Language) – a standard protocol used information for ID provisioning. SPML V2 has been established. exchange language - The content of this section corresponds to the following items in the Standards for Information Security Measures for the Central Government Computer Systems: 2.1.1.1 - 2.1.1.4 - The content of this section corresponds to the following segments in the physical configuration model: S1 - S6 225 5.13.3. Functional/Non-Functional Requirements and Standard Technology of Directory Linkage Functional requirements 1 Basic Provision of a function to coordinate multiple directories for synchronizing the account information in these directories. 2 Basic Provision of a connector (data communication) function. This function shall enable the delivering of account information to dissimilar distributed directories (RDB, LDAP, CSV file, etc.). 3 Basic Provision of a matching engine function (data conversion/matching). This function shall be able to perform data type conversion/matching at the time of account information delivery, so that the account information becomes compatible with the destination directory environment. 4 Basic Provision of tools (GUI, SDK, etc.) used to configure data conversion/mapping operations. 5 Basic Capability to incorporate logical operations freely while data is being processed – for example, combining and processing data obtained from different directories. 6 Basic Provision of a mechanism to synchronize the passwords stored in an integrated directory. 7 Basic Provision of a mechanism to check the validity of account information stored in a directory (discrepancies, addition of unauthorized account, etc.). Non-functional Requirements (description provided only when relevant requirements are given) Availability Additional Adoption of a system configuration that provides enhanced availability by employing such technologies as redundant servers, clustered software, and replication. Security Additional Capability to encrypt communications. Performance Basic The system will manage [approximately 50 thousand] accounts, and in the period of personnel revisions, will have to process a large number of user attribute modifications in a short period of time. The system configuration shall have sufficient processing capacity in view of the stated performance requirements. Extendability Additional As the targeted system expands and the user population grows, the number of accounts is also expected to increase. The system configuration shall assume enough flexibility to allow future performance upgrades. Backup Basic Capability to save backup copies of management data (matching rules, etc.). Related technology Directory LDAP (Lightweight Directory Access Protocol) – a standard protocol used to service access connect to directory services. LDAP V3 has been established. protocol Database JDBC (Java Database Connectivity) – a set of APIs used by Java programs connection API to access RDB. Use of these APIs is assumed in case the directory is RDB. 226 - The content of this section corresponds to the following items in the Standards for Information Security Measures for the Central Government Computer Systems: 2.1.1.1 - 2.1.1.4 - The content of this section corresponds to the following segments in the physical configuration model: S1 - S6 227 5.13.4. Functional/Non-Functional Requirements and Standard Technology of Web Single Sign-on Functional requirements 1 Basic Provision of two control functions targeted at Web applications: authentication using the specified authentication schemes (user ID, password, etc.), and a URL-based access control function. 2 Basic Capability given to the user that, once the user logs in to the system, he/she can utilize all the accessible Web applications without the need to log in to each, one by one (single sign-on). 3 Basic Centralized management of access control policies, enabling application to multiple authentication proxies and agents simultaneously. 4 Basic Provision of a mechanism to transfer the account information of the logged-in users (user ID, affiliation, etc.) to Web applications. 5 Basic Capability to lock (disable) an account automatically if it failed log-in procedures repeatedly more than the specified number of times. 6 Basic Capability to create and accumulate audit logs from account authentication history. 7 Additional Capability to combine the authentication mechanism with other powerful methods such as token authentication (one-time password), IC card authentication, and biometric authentication. Non-functional Requirements (description provided only when relevant requirements are given) Availability Additional Adoption of a system configuration that provides enhanced availability by employing such technologies as redundant servers, clustered software, and replication. Security Basic Intensive application of access control on the audit log records to prevent information from tampering. Additional Capability to encrypt communications. Performance Extendability Backup Basic The system assumes {approximately 50 thousand} accounts. The performance requirements shall be defined clearly in advance to achieve a configuration with sufficient capacity. Additional In view of a possible increase in the number of Web applications and users, the system configuration shall assume enough flexibility to allow future performance upgrades. Basic Capability to save backup copies of settings information (of access control policies, etc.) and audit logs. Related technology Directory LDAP (Lightweight Directory Access Protocol) – a standard protocol used to service access connect to directory services. protocol - The content of this section corresponds to the following items in the Standards for Information Security Measures for the Central Government Computer Systems: 2.1.1.1 - 2.1.1.4 228 - The content of this section corresponds to the following segments in the physical configuration model: S1 - S6 229 5.13.5. Functional/Non-Functional Requirements and Standard Technology of Desktop Single Sign-on Functional requirements 1 Basic Provision of an agent running on the terminal whose function is to perform, by executing user authentication steps in place of the user, to automatically log in to various applications – Web applications, groupware, C/S type applications – thus, realizing a single sign-on. 2 Basic The user shall be able to utilize all available applications on the terminal by only performing a log on to the desktop one time, saving the time and effort of logging in to each application. A single sign-on shall be realized through the adoption of applications that run in conjunction with the log-on authentication on desktop OS, or through the action of an agent that automatically enters authentication information, which matches the information (user ID, password) pre-registered to the relevant application. 3 Basic The system administrator shall be able to manage all the single sign-on applications in an integrated fashion, along with the automatically entered user IDs and passwords. Terminal settings shall also be managed in an integrated fashion. 4 Additional In view of the possibility that the user has lost the log in password for the desktop agent for single sign-on, the system shall provide a function to cope with this situation (e.g. password reminder function). 5 Additional Capability to combine the authentication mechanism with other powerful methods such as token authentication (one-time password), IC card authentication, and biometric authentication. Non-functional Requirements (description provided only when relevant requirements are given) Availability Additional Adoption of a system configuration that provides enhanced availability by employing such technologies as redundant servers, clustered software, and replication. Security Basic The user ID and password (both are automatically entered) shall be maintained after encryption. Performance Basic The system assumes {approximately 50 thousand} accounts. The performance requirements shall be defined clearly in advance to achieve a configuration with sufficient capacity. Extendability Additional In view of a possible increase in the number of applications and users, the system configuration shall assume enough flexibility to allow future performance upgrades. Backup Basic Setting information of the agent shall be backed up. - The content of this section corresponds to the following items in the Standards for Information Security Measures for the Central Government Computer Systems: 2.1.1.1 - 2.1.1.4 - The content of this section corresponds to the following segments in the physical configuration model: S1 - S6 230 5.13.6. Functional/Non-Functional Requirements and Standard Technology of OS Access Control This section describes only the aspects of access control - functional and non-functional requirements - directly linked to the OS. With the advancement of Internet technologies in recent years, several mechanisms for access control and authority management, that are not limited in their scope to one OS, have been standardized (e.g. RBAC, XACML) as a part of identity management. These OS-independent schemes distribute information regarding access control to resources in accordance with the pre-defined access control policies. The access control policies are managed in an integrated fashion, and provide functions for auditing (creation/modification/deletion) and life cycle management. Access control allows both role-based and rule-based definitions, and enables incorporation of independent logic. Functional requirements 1 Basic Capability to monitor accesses to OS resources (files, network, users, etc.), and allow only those accesses permitted by the pre-defined access control policy. 2 Basic Capability to apply access control – access to system operations, files, and programs - even to those account with OS administrator authority. 3 Basic Capability to manage the access control policies in an integrated fashion, and apply them to multiple targeted servers. 4 Basic Capability to detect and block tampering attempts to critical data and programs. 5 Basic Capability to give notice to the monitoring console at the time when a policy violation is detected (e.g. unauthorized access). 6 Additional Audit log that records accesses to OS resources (files, network, users, etc.) shall include such information as: date and time, user name, resource name, details of access and results. 7 Additional Capability to analyze a policy violation event, such as an unauthorized access, if such an instance is detected. The analysis shall be based on the information recorded in the audit log (date and time of unauthorized access, user name, resource name, details of access and its results, etc.). 8 Basic Provision of a mechanism to collect audit logs gathered by the managed servers, and manage and store them in an integrated fashion. Non-functional Requirements (description provided only when relevant requirements are given) Availability Additional Adoption of a system configuration that provides enhanced availability by employing such technologies as redundant servers, clustered software, and replication. Security Basic Intensive application of access control on the audit log records to prevent information tampering. Additional Capability to encrypt communications. 231 Performance Extendability Backup Basic The system assumes {approximately 50 thousand} accounts. The performance requirements shall be defined clearly in advance to achieve a configuration with sufficient capacity. Additional In view of a possible increase in the number of systems and users, the system configuration shall assume enough flexibility to allow future upgrades of process performance. Basic Setting information (e.g. access control policy) and audit log shall be backed up. Related technology Access RBAC (Role Based Access Control) – a role-based approach to implement control access control. The administrator achieves proper authority allocation by managing the role assignment of users or groups (UA: User Role Assignment) and permission assignment to the roles (PA: Permission Role Assignment). Access XACML (eXtensible Access Control Markup Language) – a set of specifications control to define a XML-based access control description language. It enables complex description conditional settings to the resources. language International standard: ITU-T Recommendation X.1142 - The content of this section corresponds to the following items in the Standards for Information Security Measures for the Central Government Computer Systems: 2.1.1.1 - 2.1.1.4 - The content of this section corresponds to the following segments in the physical configuration model: S1 - S6 232 5.14. Integrated Directory 5.14.1. Definition of Integrated Directory The integrated directory provides master database functions that cover the collected account information separately maintained in each ministry. It maintains the master account information data in coordination with the data stored in the human resource/payroll account information system and GIMA (Government Identity Management for Authentication) - an inter-ministerial common system. The account information stored in the integrated directory is distributed to each relevant directory within the Cabinet Office and Ministries via the integrated account management functions and directory linkage functions. Figure 14-1 Relation between the Integrated Directory and GIMA (Government Identity Management for Authentication) 233 Functions and Services Provided by Integrated Directory Functions and Definition Services Integrated directory The integrated directory provides master database functions that control the collection of account information constructed by the Cabinet Office and Ministries. It provides a common platform to unify the management of account information used for running Web applications and groupware, as well as to enable the staff member search of the staff member directory. As it stores the master data for account information to be saved in a variety of directories, it needs to be updated for the latest organization/personnel information, in close coordination with the human resource/payroll account system and GIMA (Government Identity Management for Authentication, when personnel shuffling is implemented. [Reference] Human resources/payroll account systems have two variants: those constructed by the initiative of the Cabinet Office or each Ministry, and those constructed through common agreement among these organizations based on the Business System Optimization Plan. Currently, the former individual systems are in the process of shifting into the latter common system. Therefore, depending on the transition status in each ministry, the system to be linked with the integrated directory should be selected accordingly. The Government Identity Management for Authentication (GIMA) manages account information required to utilize the business applications used within the Cabinet Office and in common with Ministries, as well as those used in each ministry independently, and also provides functions for authentication, authorization, and acquisition of audit logs. ■Functions provided by Government Identity Management for Authentication (GIMA) 1) Management and provision of account information 2) Principal authentication and authorization function 3) Recording and provision of access trail information (log information of 1) and 2) above) 234 The Government Identity Management for Authentication (GIMA) performs an on-line acquisition of personnel information from the human resources/payroll account system to streamline account information related to administrative tasks in business applications. In the Cabinet Office and Ministries where they already have the mechanism for the unified management of account information within the organization, they shall utilize the established mechanisms as a user authentication platform within the cabinet office and ministries that delivers the equivalent functionality of GIMA. Linkage specifications documents for effective data linkage with GIMA are provided: they should be consulted as the need arises. 235 5.14.2. Functional /Non-Functional Requirements of Integrated Directory Functional requirements (use of a password is assumed as authentication information) 1 Basic Realization of a mechanism to manage account information in an integrated fashion in close linkage with the integrated account management function and directory linkage function. 2 Basic Provision of a repository (data storage) function used to store and manage account information in an integrated fashion. The repository shall have the capacity to store the following information items for the user. - Identifier : ID (user ID, etc.) for user identification - Credential : Data used for authentication (password, etc.) - Common Profile : Data about the user (affiliation, government post, etc.) 3 Additional The repository shall have the capacity to store the following information items for the user. - Application Profile : Data used by applications 4 Additional Capability to take data linkage with the human resources/payroll management systems in each ministry independently. 5 Basic Provision of a function to import/export account information. 6 Basic Provision of an interface for data linkage with external systems. 7 Basic Capability to record operations performed on account information in an audit log. 8 Additional Capability to display the content of an audit log in an easy-to-read report format. Non-functional Requirements (description provided only when relevant requirements are given) Availability Additional Adoption of a system configuration that provides enhanced availability by employing such technologies as redundant servers, clustered software, and replication. Security Basic Provision of a mechanism to allow access to account information only to authorized administrators. Basic Capability to protect account information by setting appropriate levels of access authority according to the roles of the administrator and his/her scope of management objectives. Basic Intensive application of access control on the acquired audit log records to prevent information from tampering. Additional Capability to encrypt communications. Performance Basic The system will manage “approximately 50 thousand” accounts, and in a period of personnel changes, is required to update a large number of user attribute modifications in a short period of time. The performance requirements shall be 236 Extendability Backup defined clearly in advance to achieve a configuration with sufficient processing capacity. Additional As the targeted system expands and the user population grows, the number of user IDs is also expected to increase. The system configuration shall assume enough flexibility to allow future performance upgrades. Basic Data of account information stored in the repository shall be backed up. Related technologies Directory LDAP: LDAP (Lightweight Directory Access Protocol) is a standard service protocol used for connection with the directory service. LDAP V3 has access been established. protocol Directory LDIF: LDIF (LDAP Data Interchange Format) defines the file formats service data used to exchange LDAP account information. exchange format Database JDBC: JDBC (Java Database Connectivity) represents a set of APIs access used by Java programs to access RDB. Use of these APIs is assumed technology in the case where the directory is RDB. - The content of this section corresponds to the following items in the Standards for Information Security Measures for the Central Government Computer Systems: 2.1.1.1 - 2.1.1.4 - The content of this section corresponds to the following segments in the physical configuration model: S1 - S6 237 5.15. WAN, Ministerial LAN, DNS/DHCP/Proxy, Remote Access The IPv4 global address, required for connections to the Internet, has now almost depleted its inventory available for new assignments (IPv6 will be used for newly assigned global addresses). Therefore, new installation of servers with IPv4 global address, and construction of a new DMZ will be ruled out in advance under normal conditions. In addition, as IPv6 does not hold compatibility with IPv4, the networks and servers using IPv6 defy simple connection with those using IPv4. To cope with the problem of new address assignment and connection, some measures will be needed to achieve coexistence and combined use of both the IPv6 environment and the existing IPv4 environment. To accomplish flawless coexistence and combined use of IPv4 and IPv6, careful considerations should be exercised in advance on the equipment (server, PC, etc.) at the design and procurement stages, as well as on the operational practices such as the content of operation/management/monitoring/maintenance and security measures. This section mainly provides description from the viewpoint of IPv4 requirements. When planning to introduce IPv6, due considerations should be exercised at both the design and implementation stages. 5.15.1. LAN LAN is an infrastructure network through which a variety of services are provided within Cabinet Office and Ministries as shown in the figure below. XX Ministry XX Ministry LAN LAN Remote access Switch Switch Figure 5.15-1 Router, etc. Switch Router, etc. Switch WAN Positioning of LAN in the network 238 Definitions of the functions and services provided by LAN are as follows. Functions and Services Layer-3 switch Layer-2 switch Secure wireless LAN Definition Layer-3 switches shall be deployed in the locations where multiple of networks (segments) are linked together. This switch assumes the role of the core switch (center switch) of the LAN within the Cabinet Office and Ministries. Layer-2 switches shall be deployed in the locations where network devices within the same network (a segment) are linked together. This switch assumes the role of the floor switch (edge switch, access switch) of the LAN within the Cabinet Office and Ministries. Wireless LAN refers to the LAN system that transmits/receives data through wireless communication. The secure wireless LAN is a variant of this characterized by an enhanced level of security. 5.15.1.1. Layer-3 Switch Functional requirements 1 Basic Capability to communicate using DIX Ethernet Ver.2 frame. Or, if the system uses IEEE802.3 frame, capability to communicate using IEEE802.3 frame. 2 Basic Provision of a routing function (Static, RIPv1/v2, OSPFv2/v3, etc.) 3 Basic Provision of multicast routing functions (PIM-SM/DM, IGMP, etc.) are required if services are to be provided utilizing multicast within the Cabinet Office and Ministries. 4 Basic 5 Basic 6 7 Basic Basic 8 Basic Provision of functions to enable access control for packets that are relayed within the same network (segment) or between dissimilar networks (segments) – e.g. access control list function, filtering function, etc. Provision of a priority control function (QoS, etc.) that enables identification of packets – those transmitted/received by a specific system provided within the Cabinet Office and Ministries - and to prioritize them for relaying. Provision of VLAN functions compatible with IEEE802.1Q. Provision of link aggregation functions compatible with IEEE802.3ad. Provision of spanning tree protocol functions compatible with IEEE802.1D, IEEE802.1w, or IEEE802.1s. 239 9 Basic Provision of network authentication functions (IEEE802.1X authentication, Web authentication, MAC address authentication, etc.) to prevent unauthorized connections to the LAN within the Cabinet Office and Ministries. 10 11 Basic Provision of correct cables (category 5, etc.) that fit the ports. Additional Provision of a IEEE802.3af compatible power receiving capability (POE) is required if the layer-3 switch is to be connected, or planned to be connected, for a power supply from a secure wireless LAN using the IEEE802.3af scheme. Non-functional requirements Performance Basic Provision of the required number of the correct types of ports for connections with the servers and network devices within the Cabinet Office and Ministries (e.g. 10/100BASE-TX, 10/100/1000BASE-T, 1000BASE-SX, 1000BASE-LX, 10GBASE-SR, 10GBASE-LR, etc.) Basic Provision of a sufficient performance capacity (backplane performance, switching performance, etc.) to meet the required service throughput provided for the Cabinet Office and Ministries. Reliability Basic Provision of functions (e.g. VRRP and others) required to enable, in case of trouble, redundant operation of the network, utilizing a hot standby system. This scheme includes sharing the same default gateway address by two or more layer-3 switches Basic Provision of backup ports in preparation for physical port failures – the number of them should not be so large that they adversely affect normal system operation. Basic Provision of a dual power supply, and measures to enhance the reliability of power supply (such as the use of UPS) Security Basic Provision of an identity authentication function that enables selective endowment of administrative authority Basic Provision of functions required to enable the administrator to define settings (e.g. ACL), and to monitor (audit) the system through the review of modification records Operational Basic Provision of a console port that can be used to track maintenance modifications of setting information and check operational status. Basic Provision of functions (TELNET, SSH, Web setting, etc.) that enable remote maintenance from the operation management terminal. Basic Provision of functions (FTP, TFIP, etc.) that enable saving of a backup copy of configuration definition information. 240 Basic Basic Basic Basic Basic Provision of functions (SNMP, RMON, etc.) required for the operation management server to operate/monitor the network configuration within the Cabinet Office and Ministries. Provision of a function (NTP or SNTP) that enables the system to maintain the time settings of the layer-3 switch in a normal state at all times. Provision of a function (port mirroring, etc.) that enables traffic analysis over the layer-3 switch. Provision of a function to transfer logs (Syslog and others) to the server. Mountability in a 19-inch rack. Related technologies Routing protocol RIP (Routing Information Protocol) is a routing protocol used to perform path exchanges dynamically with layer-3 switches or routers. RIPv1:RFC1058, RIPv2:RFC2453 OSPF (Open Shortest Path First) is a routing protocol used to perform path exchanges dynamically with layer-3 switches or routers. With improvements in some of the problems inherent in RIP, routing protocol has become applicable to large scale networks. OSPFv2/v3: RFC2328/RFC2740 File transfer FTP (File Transfer Protocol) is a protocol to transfer files. protocol RFC959 TFTP (Trivial File Transfer Protocol) is a protocol to transfer files. RFC1350 Multicast PIM-SM (Protocol Independent Multicast- Sparse Mode) is a protocol routing protocol to create the path information required to relay multicasting packets. RFC2362 PIM- DM (Protocol Independent Multicast- Dense Mode) is a routing protocol to create the path information required to relay multicasting packets. IGMP (Internet Group Management Protocol) is a protocol to control the multicast group configured to receive multicasting packets. IGMPv1: RFC1112, IGMPv2: RFC2236, IGMPv3:RFC3376 Network time NTP (Network Time Protocol) is a protocol used to secure the protocol internal clock of the network devices, making sure clocks operate in a normal state at all times through time synchronization with external servers. NTPv3:RFC1305 SNTP (Simple Network Time Protocol) is a protocol used to secure the internal clock of the network devices, making sure clocks operate in a normal state at all times through its capability to synchronize with external servers. RFC1361 Network SNMP (Simple Network Management Protocol) is a protocol 241 management protocol Communication protocol Encrypted communication protocol router redundancy protocol Log message transfer protocol Link aggregation protocol Virtual network Loop-free protocol Ethernet communication standard used to monitor/control network devices through networks based on a MIB (Management Information Base). The devices generally support one or more of the following three versions: SNMPv1, SNMPv2c, SNMPv3. RMON (Remote network Monitoring) is an MIB (Management Information Base) used to monitor the communication status – traffic situation, errors, etc.- of the network devices installed in remote locations. RFC1757. Generally, four groups of MIB (Ethernet Statistic, Ethernet History, Alarm, Event) are implemented in the devices. MIB (Management Information Base) is management information, standardized in terms of its structure and identification method, for use in network management protocols. RFC1213. Both standard definitions and vendor definitions exist. TELNET is a protocol that provides general purpose bidirectional communication and virtual terminals. RFC854 SSH (Secure Shell) is a protocol that provides encrypted communication and virtual terminals. This is the program used, for example, to log in to other computers via the network, to execute commands on remote machines, and to transfer files to other machines. RFC4250-4256, 4716, 4819 SFTP (SSH File Transfer Protocol) is a file transfer protocol that utilizes SSH. VRRP (Virtual Router Redundancy Protocol) is a protocol that enables redundant configurations in the system consisting of layer-3 switches and routers. RFC2338 Syslog is a protocol for transferring log messages of the network devices to external servers via the IP network. Link Aggregation is a protocol that enables enhancement for path redundancy and secures wide bandwidth through logical aggregation of a plurality of physical ports into one. IEEE802.3ad VLAN (Virtual LAN) is a function that enables division of one switch into a plurality of networks. VLAN includes such schemes as Port LAN, Tag VLAN, and Protocol VLAN. IEEE802.1Q STP (Spanning Tree Protocol) is a protocol that enables construction of redundant configurations in layer-2. STP includes such variants as RSTP and MSTP. IEEE802.1D, IEEE802.1w, IEEE802.1s Standard specifications for Ethernet ports implemented in network devices. 10BASE-T: IEEE802.3, 100BASE-TX: IEEE802.3u, 1000BASE-T: IEEE802.3ab, 1000BASE-SX, 1000BASE-LX: IEEE802.3z, 10GBASE-SR, 10GBASE-LR: IEEE802.3ae 242 Electricity Supply Standard Authentication standard POE (Power Over Ethernet) is a method to supply power to network devices - wireless LAN access points, IP telephones, etc. – utilizing LAN cables. IEEE802.3af IEEE802.1X 5.15.1.2. Layer-2 switch Functional requirements 1 Basic Capability to communicate using IEEE802.3 frame and DIX Ethernet Ver2 frame. 2 Additional Provision of functions to enable access control for packets that are relayed within the same network (segment) or between dissimilar networks (segments) – e.g. access control list function, filtering function, etc. 3 Basic Provision of a priority control function (QoS, etc.) that enables identification of packets – those transmitted/received by a specific system within the Cabinet Office and Ministries - and to prioritize them for relaying. 4 Basic Provision of VLAN function compatible with IEEE802.1Q. 5 Basic Provision of a link aggregation function compatible with IEEE802.3ad. 6 Basic Provision of spanning tree protocol functions compatible with IEEE802.1D, IEEE802.1w, or IEEE802.1s. 7 Basic Provision of a network authentication function (IEEE802.1X authentication, Web authentication, MAC address authentication, etc.) to prevent unauthorized connections to the LAN within the Cabinet Office and Ministries. 8 Additional Provision of a IEEE802.3af compatible power receiving capability (POE) is required if the switch is to be connected, or planned to be connected, to a secure wireless LAN (this requirement shall apply when power is received from a switch using the IEEE802.3af scheme). 9 Basic Provision of correct cables (category 5, etc.) that fit with the ports. 243 Non-functional requirements Performance Basic Provision of the required number of correct types of ports for connections with the servers and network devices within the Cabinet Office and Ministries (e.g. 10/100BASE-TX, 10/100/1000BASE-T, 1000BASE-SX, 1000BASE-LX, 10GBASE-SR, 10GBASE-LR, etc.) Basic Provision of a sufficient performance capacity (backplane performance, switching performance, etc.) to meet the required service throughput provided for the Cabinet Office and Ministries. Reliability Basic Provision of backup ports in preparation for physical port failures – the number of them should not be so large so that they adversely affect normal system operation. Security Basic Provision of an identity authentication function that enables selective endowment of administrative authority. Basic Provision of functions required to enable the administrator to define settings (e.g. ACL), and to monitor (audit) the system through the review of modification records. Operational Basic Provision of a console port that can be used to track maintenance modifications of setting information and check operational status. Basic Provision of functions (TELNET, SSH, Web setting, etc.) that enable remotely controlled maintenance from the operation management terminal. Basic Provision of functions (FTP, TFIP, etc.) that enable saving of a backup copy of configuration definition information. Basic Provision of functions (SNMP, RMON, etc.) required for the operation management server to operate/monitor the network configuration within the Cabinet Office and Ministries. Basic Provision of a function (NTP, SNTP, etc.) that enables the system to maintain the time settings of the layer-2 switch in a normal state at all times. Basic Provision of a function (port mirroring, etc.) that enables traffic analysis over the layer-2 switch. Basic Provision of a function to transfer logs (Syslog and others) to the server. Basic Mountability in a 19-inch rack. 244 Related technologies File transfer FTP (File Transfer Protocol) is a protocol to transfer files. RFC959 protocol TFTP (Trivial File Transfer Protocol) is a protocol to transfer files. RFC1350 Network time NTP (Network Time Protocol) is a protocol used to secure the protocol internal clock of the network devices, making sure clocks operate in in a normal state through time synchronization with external servers. NTPv3:RFC1305 SNTP (Simple Network Time Protocol) is a protocol used to secure the internal clock of the network devices, making sure clocks operate in a normal state at all times through its capability to synchronize with external servers. RFC1361 Network SNMP (Simple Network Management Protocol) is a protocol used to management monitor/control network devices through networks based on MIB protocol (Management Information Base). The devices generally support one or more of the following three versions: SNMPv1, SNMPv2c, SNMPv3. RMON (Remote network Monitoring) is a MIB (Management Information Base) used to monitor the communication status – traffic situation, errors, etc.- of the network devices installed in remote locations. RFC1757. Generally, four groups of MIB (Ethernet Statistic, Ethernet History, Alarm, Event) are implemented in the devices. MIB (Management Information Base) is management information, standardized in terms of its structure and identification method, for use in network management protocols. RFC1213. Both standard definitions and vendor definitions exist. Communication TELNET is a protocol that provides general purpose bidirectional protocol communication and virtual terminals. RFC854 Encrypted SSH (Secure Shell) is a protocol that provides encrypted communication communication and virtual terminals. This is the program used, for protocol example, to log in to other computers via the network, to execute commands on remote machines, and to transfer files to other machines. RFC4250-4256, 4716, 4819 SFTP (SSH File Transfer Protocol) is a file transfer protocol that utilizes SSH. Log message Syslog is a protocol for transferring log messages of the network transfer devices to external servers via the IP network. protocol Link Link Aggregation is a protocol that enables enhancement of path aggregation redundancy and the securing of wide bandwidth through logical protocol aggregation of a plurality of physical ports into one. IEEE802.3ad Virtual network VLAN (Virtual LAN) is a function that enables division of one switch into a plurality of networks. VLAN includes such schemes as Port LAN, Tag VLAN, and Protocol VLAN. IEEE802.1Q 245 Loop free protocol Electricity Supply Standard Authentication standard STP (Spanning Tree Protocol) is a protocol that enables construction of redundant configurations in layer-2 routers. STP includes such variants as RSTP and MSTP. IEEE802.1D, IEEE802.1w, IEEE802.1s POE (Power Over Ethernet) is a method to supply power to network devices - wireless LAN access points, IP telephones, etc. – utilizing LAN cables. IEEE802.3af IEEE802.1X 246 5.15.1.3. Secure Wireless LAN If the system plans to introduce a secure wireless LAN, due deliberation should be exercised on its security strength. Functional requirements 1 Basic Communication capability using TCP/IP, UDP/IP shall be provided. 2 Basic Both the access point (AP) and client shall support IEEE802.11g, IEEE802.11a (W52,W53,W56) as the transmission scheme. 3 Additional Both the AP and the client shall support IEEE802.11n as the transmission scheme. 4 Basic Both the AP and client shall support IEEE802.11n as the transmission scheme. Note, however, that the clients are allowed to use a supplicant. The encryption method shall have encryption strength compatible with those method listed in the e-Government recommendations. 5 Basic Both the AP and client shall support WPA2, IEEE802.1x (EAP-FAST/TLS/TTLS/PEAP, etc.) as the authentication scheme. Note, however, the clients are allowed to use a supplicant. They shall support, when in a connected state, authentication using the MAC address of the terminal. 6 Basic The AP shall support ESS-ID stealth function. 7 Basic In the system where VoWLAN is implemented, the capability to limit the number of terminals connected to an AP is required. 8 Basic The system shall support both AC source and IEEE802.3af scheme to receive electric power or a power injector with the matching capacity may be used instead (in which case, matching shall be made with the switch’s power supplying capacity). 9 Additional Provision of a DHCP function, or DHCP relay function. Non-functional requirements Reliability Basic Capability to do maintenance of the AP settings from remote terminals via the network. Security Basic Capability to perform wireless access point setting and identity authentication for audit record administrator. Basic Capability to acquire security-related audit logs – start/end of access point usage, access logs, and others. Operational Basic Capability to manage the AP using SNMP. maintenance Basic Link capability with the Syslog server. 247 Related technologies Wireless LAN IEEE802.11a (W52,W53,W56), IEEE802.11b/g,n standard Wireless LAN WPA (Wi-Fi Protected Access) is a standard used for wireless authentication LAN authentication. IEEE802.11i method WPA2 (Wi-Fi Protected Access 2) is a standard used for wireless LAN authentication. This is a new version of the WPA standard, published in 2002, compatible with the upgraded AES encryption. IEEE802.11i Encryption AES (Advanced Encryption Standard) is a symmetric-key standard cryptography scheme standardized as the new U.S. encryption method. FIPS PUB 197 PEAP (Protected Extensible Authentication Protocol) is one of extended variants of PPP (Point to Point Protocol) with an added feature for authentication functions, which is characterized by two-way authentication between the server and clients. IEEE802.1x Security TLS (Transport Layer Security) is characterized by combined protocol security technologies – public- and private-key cryptography, digital certificates, hush functions, etc. - and is capable of preventing tapping and tampering of data and spoofing. IEEE802.1x TTLS (Tunneled Transport Layer Security) is a variant of TLS (Transport Layer Security, a EPA authentication protocol utilized in PPP authentication schemes), and performs authentication using the user name/password protected by a key encryption method. IEEE802.1x. EAP-FAST is a generally available EAP (Extensible Authentication Protocol) pursuant to IEEE 802.1x, and implements tunneling through authentication process using a symmetrical key algorithm. It is compatible both with IEEE 802.1x and EEE 802.11i. Avoidance of ESS-ID stealth is a function to conceal a part of the “beacon wireless LAN signal” train (i.e. transmission of ESS-ID, network identification, at detection a regular interval to external world). IEEE 802.11 Electricity POE (Power Over Ethernet) is a method to supply power to Supply network devices - wireless LAN access points, IP telephones, etc. Standard – utilizing LAN cables. IEEE802.3af DHCP DHCP (Dynamic Host Configuration Protocol) is a protocol used to automatically assign a computer with the information, such as an IP address, required to establish temporary connection to the Internet. RFC2131, RFC2132 Network SNMP (Simple Network Management Protocol) is a protocol used management to monitor/control network devices through networks based on protocol MIB (Management Information Base). The devices generally 248 Log message transfer protocol support one or more of the following three versions: SNMPv1, SNMPv2c, SNMPv3. Syslog is a protocol for transferring log messages of the network devices to external servers via the IP network. 249 5.15.2. WAN It represents a communication scheme in which a set of computers installed in remote locations – home ministry and its regional offices, and other ministries – exchange data through telephone lines and other dedicated lines. XX Ministry XX Ministry LAN LAN Remote access Switch Switch Figure 5.15-2 Router, etc. Switch Router, etc. Switch WAN Positioning of WAN in the network Definitions of the functions and services provided by a WAN are as follows. Functions and Services Router Line service (Inter-hub network) Line service (Internet connection) Definition A router is a piece of equipment that relays the data flowing within a network to other networks. Line service (inter-hub service) represents a “Wide Area Network.” It represents a communication scheme in which a set of computers installed in remote locations – home ministry and its regional offices, and other ministries – exchange data through telephone lines and other dedicated lines. Representative examples of WAN include IP-VPN – a carrier network that is shared among user enterprises, and a virtual LAN is constructed on it - and wide-area Ethernet. Line service (Internet connection) represents a set of computer networks mutually interconnected using the Internet Protocol technology. It realizes data communication with the computers on the Internet via telephone lines, dedicated lines, and Internet service providers (ISP). 250 5.15.2.1. Router and other devices Functional requirements 1 Basic Capability to communicate using DIX Ethernet Ver.2 frame, or if the system uses the IEEE802.3 frame, the capability to communicate using IEEE802.3 frame. 2 Basic Provision of a routing function (Static, RIPv1/v2, etc.). 3 4 5 6 7 8 9 Additional Provision of a routing function (OSPFv2/v3, BGP, etc.). Basic In cases where the system has network connections in locations exterior to the Cabinet Office and Ministries, or it uses internet VPN connections: Router: The router shall support IPsec (main mode/aggressive mode). Additional In other cases than above: The device shall support IPsec (main mode/aggressive mode). Basic The routers In the system that have network connections and internet VPN connections in locations exterior to the Cabinet Office and Ministries: If the list of encryption methods included in the e-Government recommendations have been released, a router with encryption strength matching with those listed shall be applied to the IPsec encryption algorithm for mutual connection among the hubs. Additional In other cases than above: If the list of encryption methods included in the e-Government recommendations have been released, a router with encryption strength matching with those listed shall be able to apply. Basic Router: The router shall have a shaping function. Additional SW: The SW shall have a shaping function. Basic Provision of a priority control function (QoS, etc.) that enables identification of the packets – those transmitted/received by a specific system provided within the Cabinet Office and Ministries and to prioritize them for relaying. Additional In cases where the router is connected to a network with overlapping network addresses, provision of an NAT, NAPT function is required. Basic Provision of functions to enable access control of packets that are relayed within the same network (segment) or between dissimilar networks (segments) – e.g. access control list functions, filtering functions, etc. Basic Provision of correct cables (category 5, etc.) that fit with the ports. 251 Non-functional requirements Performance Basic Provision of the required number of correct types of ports for connection with the servers and network devices within the Cabinet Office and Ministries. Basic Provision of sufficient performance capacity to meet the required service throughput provided for the Cabinet Office and Ministries. Reliability Basic Capability to configure redundancy on the CPU block or redundant network configuration shall be achieved through the use of OSPF/VRRP and other methods, and by installing two or more routers. Additional Provision of a dual power supply, and measures to enhance the reliability of power supply (such as the use of UPS). Additional Provision of backup ports in preparation for physical port failures – the number of them should not be so large that they adversely affect normal system operation. Operational Basic Provision of a console port that can be used to track maintenance modifications of setting information and check operational status. Basic Provision of functions (TELNET, SSH, Web setting, etc.) that enable remotely controlled maintenance from the operation management terminal. Basic Provision of functions (FTP, TFIP, etc.) that enable saving a backup copy of configuration definition information. Basic Provision of functions (SNMP, etc.) required for the operation management server to operate/monitor the network configuration within the Cabinet Office and Ministries. Basic Provision of a functions (NTP or SNTP) that enables the system to maintain the time settings of the router in a normal state at all times. Basic Provision of a function to transfer logs (Syslog and others) to the server. Basic Mountability in a 19-inch rack. This requirement may be dropped if the router/device is so small that rack mounting is not necessary. Related technologies Routing protocol RIP (Routing Information Protocol) is a routing protocol used to perform path exchanges dynamically with the layer-3 switches or routers. RIPv1: RFC1058, RIPv2: RFC2453 252 File transfer protocol Time synchronization protocol Network management protocol Communication protocol Encrypted communication protocol Log message transfer protocol Ethernet communication standard OSPF (Open Shortest Path First) is a routing protocol used to perform path exchanges dynamically with the layer-3 switches or routers. With improvements in some of the problems inherent in RIP, routing protocol has become applicable to large scale networks. OSPFv2/v3: RFC2328/RFC2740 FTP (File Transfer Protocol) is a protocol to transfer files. RFC959 TFTP (Trivial File Transfer Protocol) is a protocol to transfer files. FC1350 NTP (Network Time Protocol) is a protocol used to secure the internal clock of the network devices, making sure clocks operate in a normal state through time synchronization with external servers. NTPv3:RFC1305 NTP (Simple Network Time Protocol) is a protocol used to secure the internal clock of the network devices, making sure clocks operate in a normal state through its capability to synchronize with external servers. RFC1361 SNMP (Simple Network Management Protocol) is a protocol used to monitor/control network devices through networks based on MIB (Management Information Base). Devices generally support one or more of the following three versions: SNMPv1, SNMPv2c, SNMPv3. MIB (Management Information Base) is management information, standardized in terms of its structure and identification method, for use in network management protocols. RFC1213. Both standard definitions and vendor definitions exist. TELNET is a protocol that provides general purpose bidirectional communication and virtual terminals. RFC854 SSH (Secure Shell) is a protocol that provides encrypted communication and virtual terminals. This is the program used, for example, to log in to other computers via the network, to execute commands on remote machines, and to transfer files to other machines. RFC4250-4256, 4716, 4819 SFTP (SSH File Transfer Protocol) is a file transfer protocol that utilizes SSH. Syslog is a protocol for transferring log messages of the network devices on the IP network to external servers. Standard specifications for Ethernet ports of network devices.. 10BASE-T: IEEE802.3, 100BASE-TX: IEEE802.3u, 1000BASE-T: IEEE802.3ab, 1000BASE-SX, 1000BASE-LX: IEEE802.3z, 10GBASE-SR, 10GBASE-LR: EEE802.3ae 253 Encrypted communication standard Key exchange standard Network address conversion standard IPsec is the standard for the use of encrypted communication. RFC2401(Security Architecture for the Internet Protocol), RFC2406(IP Encapsulating Security Payload [ESP]) IKE is the standard used for key exchange. RFC2407 (The Internet IP Security Domain of Interpretation for ISAKMP), RFC2408 (Internet Security Association and Key Management Protocol (ISAKMP)), RFC2409 (The Internet Key Exchange (IKE)) NAT and NAPT are the standards for address conversion. FC1631 (The IP Network Address Translator (NAT)) 5.15.2.2. Line Service (inter-hub network) Functional requirements 1 Basic Capability to communicate using IEEE802.3 frame and DIX Ethernet Ver2 frame. 2 Basic Support of the following schemes as the access method (access line) to the backbone: exclusive line, ATM, Ethernet, xDLS, and FTTH. 3 Basic Provision of [QoS (priority control) or other functions] to reduce the effect caused by inter-system traffic to a minimum. 4 Basic Secured isolation of the line services from the external world, ensuring a complete shut out of access from external networks. 5 Basic Capability to provide router monitoring as a part of the services. 6 Basic Capability to provide a remote access function as a part of the services. 254 Non-functional requirements Performance Basic Capability to allocate sufficient throughput (bandwidth) needed to render services delivered within the Cabinet Office and Ministries. Reliability Basic Provision of a network capable of constructing optimum (such as redundant) configuration to cope with unexpected system stops (circuit failure, router failure, etc.) Basic The main line and backup line shall use different regional lines – each of which provided by different telecommunication carriers – to upgrade fault tolerance. The backbone shall also be a multi-carrier-capable (i.e. capability to construct a multi-carrier redundant configuration). Switching between the main line and backup line shall be performed automatically. Operational Basic Provision of a contact for inquiries in case of troubles that maintenance may occur in the backbone line, regional lines (access lines), and terminal devices. Basic Capability to monitor, do maintenance, and respond to troubles on the line (notification of trouble occurrence, tracking down and separation of the cause of the failure, failure reporting, etc.) Basic Capability of on-site troubleshooting, in terms of device repair and replacement. Basic On-request provision of traffic data for each line after the introduction of the system. 255 5.15.2.3. Line Service (Internet connection) Functional requirements 1 Basic Capability to communicate using IEEE802.3 frame and DIX Ethernet Ver2 frame. 2 Basic The provider’s backbone switch shall have the capability of IPv6 connection. 3 Basic The access line to the Internet (the communication line from the Internet connection point to the ISP) shall support an exclusive line, ATM, Ethernet, and FTTH. 4 Basic The ISP backbone shall have the capability to connect directly, or by way of a transit carrier, to a domestic/overseas major IX and overseas major ISP. Sufficient bandwidth – wider than that given to the access line - shall be secured to the ISP backbone. 5 Basic Provision capability of the required number of global IP addresses. 6 Basic Provision capability of a DNS server as a part of the internet connection services. Non-functional requirements Performance Basic Capability to allocate sufficient throughput (bandwidth) needed to render services delivered within the Cabinet Office and Ministries. Reliability Basic Provision of a network capable of constructing optimum (such as redundant) configuration to cope with unexpected system stops (circuit failure, router failure, etc.). Basic The main line and backup line shall use different regional lines – each of which provided by different telecommunication carriers – to upgrade fault tolerance. Switching between the main line and backup line shall be performed automatically. Basic Capability to, when needs arise, to achieve a redundant configuration using path exchange protocol (dynamic routing protocol: BGP). Operational Basic Provision of a contact for inquiries in case of troubles that maintenance may occur in the ISP access line and terminal devices. Basic Capability to monitor, do maintenance, and respond to troubles on the line (notification of trouble occurrence, tracking down and separation of the cause of the failure, failure reporting, etc.) Basic Capability of on-site troubleshooting, in terms of device repair and replacement. Related technologies Path exchange BGP (Boarder Gateway Protocol) is a routing protocol used to 256 protocol perform path exchanges dynamically with the layer-3 switches or routers. RFC4271 257 5.15.3. Remote Access Remote access represents a mode of connection from the external networks to the internal network (or computers) via telephone line, dedicated line, or the Internet. XX Ministry Remote access device Switch Router/FW Switch Figure 5.15-3 Internet Remote access device configuration in a network Functions, services, and definitions of remote access are as follows. Functions and Definition Services Remote access Refers to the devices that terminate accesses from the external device networks to the internal network (or computers) via telephone line, dedicated line, or the Internet. 5.15.3.1. Remote access device Functional requirements 1 Basic Capability to communicate using the IEEE802.3 frame and DIX Ethernet Ver2 frame. 2 Basic Provision of an authentication function to prevent connection from an unauthorized terminal. 3 Basic Linkage capability with the authentication server. 4 Basic Provision of an encrypted communication function using SSL or IPsec to secure a sufficient level of security. If the list of encryption methods included in the e-Government recommendations has been released, a device with the encryption strength matching with those listed shall be applied. 5 Basic Definition capability of the maximum number of simultaneously accessible users. 258 6 Basic 7 Basic Web applications shall be operational while the remote access devices are being connected using SSL and other schemes. Capability to configure settings for each user/group, and the provision of easy procedures for security policy settings and maintenance. Non-functional requirements Performance Basic Provision of a response capability to the requests from clients located within the range of service delivery (reconnection of disconnected communication, etc.). Reliability Basic Capability to achieve a redundant configuration of devices. Operational Basic Capability of being operated by way of Web-browser and maintenance CLI. Basic Provision of maintenance functions from remote locations using [TELNET, FTP, SSH, etc.] Basic Provision of functions [SNMP, etc.] required for the operation management server to operate/monitor the network configuration within the Cabinet Office and Ministries. Basic Mountability in a 19-inch rack. Related technologies Encrypted IPsec is the standard for the use of encrypted communication. communication RFC2401 (Security Architecture for the Internet Protocol), standard RFC2406(IP Encapsulating Security Payload [ESP]) Communication protocol File transfer protocol Encrypted communication protocol Network management protocol TELNET is a protocol that provides general purpose bidirectional communication and virtual terminals. RFC854 FTP (File Transfer Protocol) is a protocol to transfer files. RFC959 SSH (Secure Shell) is a protocol that provides encrypted communication and virtual terminals. This is the program used, for example, to log in to other computers via the network, to execute commands on remote machines, and to transfer files to other machines. RFC4250-4256, 4716, 4819 SNMP (Simple Network Management Protocol) is a protocol used to monitor/control network devices through networks based on MIB (Management Information Base). Devices generally support one or more of the three versions: SNMPv1, SNMPv2c, SNMPv3. 259 5.15.4. DNS/DHCP/Proxy DNS is a function to manage relations between IP addresses and domain names, or host names. DHCP is a function to distribute the IP addresses and subnet masks to be used to the clients, and notify the IP addresses of the servers (gateway server, DNS server, etc.) to be used to the clients. Proxy is a function to communicate with the external networks, in place of the computers located in the internal network and are incapable to perform direct communication with the external networks. XX Ministry XX Ministry DNS/DHCP/Proxy server DNS/DHCP/Proxy server Switch Switch Router, etc. Switch Router, etc. Switch Figure 5.15-4 DNS/DHCP/Proxy server configuration in a network The definitions of DNS/DHCP/Proxy are as follows. Functions and Services DNS server DHCP server Proxy server Definition A DNS server manages relations between IP addresses and domain names, or host names. A DHCP server distributes the IP addresses and subnet masks to be used by the clients, and notifies the IP addresses of the servers (gateway server, DNS server, etc.) to be used to the clients. A Proxy server communicates with the external networks, in place of the computers located on the internal network and are incapable of performing direct communication with external networks. 260 5.15.4.1. DNS Server Functional requirements 1 Basic Capability of TCP/IP communication. 2 Basic Provision of a name (address) resolution function for IP addresses, domain names, and host names associated with the use of DNS protocol. 3 Basic The name resolution function shall be compatible both with forward and reverse lookup. 4 Basic Provision of linking capability with the upper, or lower DNS server. Non-functional requirements Performance Basic Provision of a response capability to the requests from clients located within the range of service delivery. Reliability Basic The server shall have a dual configuration (main and sub), or the hardware shall be capable of a redundant configuration. Operational Basic Capability to clear the cache. maintenance Basic Capability of being maintained from remote devices. Basic Mountability in a 19-inch rack, or compatibility with floor mounting. Related technologies Domain name DNS (Domain Name System) manages correspondence between system the IP address and other items such as a host name on the Internet and a domain name used in e-mail. RFC1034, RFC1035 5.15.4.2. DHCP Server Functional requirements 1 Basic Capability of TCP/IP communication. 2 Basic Capability to provide the IP addresses required for the use of DHCP protocol. or Capability to provide IP addresses through the use of DHCP protocol. 3 Basic Capability to specify the range of IP addresses to be allocated. Non-functional requirements Performance Basic Provision of a response capability to the requests from clients located within the range of service delivery. Reliability Basic Capability to achieve a redundant configuration of devices. Operational Basic Capability of being maintained from remote devices. maintenance Basic Mountability in a 19-inch rack, or compatibility with floor 261 mounting. Related technologies DHCP DHCP (Dynamic Host Configuration Protocol) is the protocol used to assign a computer with the information, such as an IP address, required to establish a temporary connection to the Internet..RFC2131, RFC2132 262 5.15.4.3. Proxy Server Functional requirements 1 Basic Capability of TCP/IP communication. 2 Basic The Proxy server shall be able to relay access to the Internet and Web within the ministry. 3 Basic Provision of an HTTP request relaying function compatible with HTTP1.1. 4 Basic Provision of a caching function of HTML contents. Non-functional requirements Performance Basic Provision of a response capability to the requests from clients located within the range of service delivery. Basic Capability to change the cache size allocation, or provision of sufficient amount of cache area for business operations. Reliability Basic Capability to achieve a redundant configuration of devices. Operational Basic Capability of being maintained from remote devices. maintenance Basic Mountability in a 19-inch rack, or compatibility with floor mounting. Related technologies Proxy server A Proxy server is situated in an interface between the Internet and the internal network of an enterprise or other entities, and provides an internet connection as a “proxy” for the computers within the internal computers that are not capable of direct connection. Hypertext HTTP (Hyper Text Transfer Protocol) 1.1. RFC2068 transfer protocol Web page HTML (HyperText Markup Language) is a markup language used description to describe a Web page. language 263 5.15.5. VoIP VoIP is a platform on which various telephone services within the Cabinet Office and Ministries are provided utilizing the IP network as shown in the diagram below. IDC XX Ministry LAN LAN Operational VoIP server, VoIP gateway IP telephone Switch Switch Switch Router, etc. Router, etc. Switch WAN Standby VoIP server, VoIP gateway Figure 5.15-5 VoIP server/gateway configuration in a network Functions, services, and definitions of VoIP are as follows. Functions and Services VoIP server, VoIP gateway Definition A combination of VoIP servers and/or VoIP gateways are arranged to work with a layer-3 switch bundling a plurality of networks (segments) within the Cabinet Office and Ministries. VoIP server and/or VoIP gateway assumes a role to provide various types of telephone services within the Cabinet Office and Ministries. 5.15.5.1.VoIP Server, VoIP Gateway Functional requirements 1 Basic Provision of an extension interconnection function within the Cabinet Office and Ministries, and an external connection function with the general public networks and IP public networks. 2 Basic Provision of call hold, call redirection, and call pickup functions. 3 Basic Provision of a function to define the call notification number (transmitted when an external call is made) for each extension number. 4 Basic Provision of a function to connect with mobile terminals (wireless LAN telephone terminal, PHS, etc.). 5 Basic Provision of optimum path selection (ARS, etc.) to reduce the cost of external calls. 264 6 Basic 7 Basic 8 Basic Provision of a function to gather external calling charge (deemed charge) information for each extension number and department within the Cabinet Office and Ministries, and output reports thereof. Provision of network authentication functions for IP telephone transceivers (IEEE802.1x authentication, MAC address authentication, etc.) to prevent unauthorized connections to the LAN within the Cabinet Office and Ministries. The control protocol used in the IP telephone transceivers shall conform to SIP (IETF RFC3261). Non-functional requirements Performance Basic Provision of enough capacity to connect the required number of IP telephone transceivers used within the Cabinet Office and Ministries. The maximum expandable capacity shall be taken into consideration in view of the future proliferation of IP telephone transceivers. Basic Provision of enough processing capacity (HCS, BHCA, etc.) for handling telephone services rendered within the Cabinet Office and Ministries. Reliability Basic The VoIP server shall have an allowance for a redundant configuration. Basic Capability to switch, at the time of VoIP server failure, to the backup VoIP server within the given period of time, so as to avoid affecting business operations. Basic Switching to the backup VoIP server, triggered by VoIP server failure, shall not interrupt currently running calls. Operational Basic Provision of a log that can be used to track modifications of maintenance setting information and check operational status. Basic Provision of functions (TELNET, SSH, Web setting, etc.) that enable remotely controlled maintenance from the operation management terminal. Basic Provision of functions (FTP, TFIP, etc.) that enable saving a backup copy of configuration definition information. Basic The VoIP server shall have the capability to monitor, in coordination with the operation management server, the processes running on the VoIP server. Basic Provision of a function to transfer logs (Syslog and others) to the server. Basic Mountability in a 19-inch rack, or compatibility with floor mounting. Related technologies Protocols for IP SIP (Session Initiation Protocol) is a control protocol for IP telephone and telephone and others. IETF RFC3261 others Authentication IEEE802.1X 265 standard File transfer protocol Log message transfer protocol FTP (File Transfer Protocol) is a protocol to transfer files. RFC959 TFTP (Trivial File Transfer Protocol) is a protocol to transfer files. RFC1350 Syslog is a protocol for transferring log messages of the network devices to external servers via the IP network. 266 5.16. Workflow, BAM 5.16.1. Definition of workflow and BAM Workflow describes a series of work patterns - each of which have high chances of repetition found in a part or the whole of a business process, which enables a smooth handover of business activities (document, information, tasks, etc.) from one person in charge to the next, following the established steps of business practices. A workflow is often represented as a business flow chart or other presentation tools, after careful examination of each work’s content and sequence. The software specifically designed to define, create, and operate the workflow on an IT system is called a workflow management system. The system enables such practices as execution controls (automatic allocation and ordering of work for each person in charge), management and transfer of information/data associated with the workflow, and monitoring of situation progress. The use of a workflow management system enables efficient processing and is expected to speed up business operations. This is achieved through the creation of electronic data from a variety of work papers (application form, request for approval, payment bill for transportation, request for vacation, notification of residence removal, etc.) that have traditionally required moving through a series of approval steps by the persons in charge, dispersed throughout the sections within the ministry. This processing is done by implementing such practices as parallel circulation of documents and requests for final decision making from a business trip destination utilizing a hand-held PC. BAM (Business Activity Monitoring) represents a suite of technologies and processes that monitors the implementation status and past record of business processes in real time, and issues an alert when an irregular value or some other sign of degradation is detected. The administrator and persons in charge can utilize this information, as a trigger for the call to next action, leading to decisions being made and swift handling of the problem. BAM also monitors the selected business processes directly related to the organization’s KPI (Key Performance Indicators), and display a visualized summary of execution state and KPI on the dashboard screen. The alert information reported from monitoring enables quicker response to the chances of problems taking place in business processes, leading to upgraded efficiency. This is the objective of BAM. Monitoring data thus measured and accumulated will also provide useful information for the review and redesign of business processes. 267 5.17. Common Elements in Domains 5.17.1. Definition The common elements in domains represent an assembly of requirements common to a plurality of technical domains such as communication protocol, data formats, and character codes. This section defines only the related technologies, and does not provide functional, and non-functional requirements. Functional and non-functional requirements are designated in the sections that describe the related technologies. Related technologies Communication protocol Universal Multiple-octet Coded Character Set Graphic format IP: IETF RFC 791 TCP: IETF RFC 793 UDP: IETF RFC 968 HTTP 1.1: IETF RFC 2616 HTTP over TLS: IETF RFC 2818 TLS: IETF RFC 4243 FTP: IETF RFC 959 FTPS: IETF RFC 2229 SSH: IETF RFC 4250, 4251, 4252, 4253, 4254, 4255, 4256 Unicode: ISO/IEC 10646 JPEG: ISO/IEC 15444-1, -2, -3 PNG: ISO/IEC 15948 268 6. Procurement of services This Chapter organizes “services” to be procured in information system procurement in accordance with procurement specifications issued by ministries and explains the method of creating specifications. Please refer to Chapter 5 for procurement of “goods” which is not covered by this Chapter. This Chapter classifies services related to information systems by information system phase. Planning phase Requirements definition 要件定義 phase Operation/maintenance 運用・保守フェーズ phase Development phase 開発フェーズ 6.2 6.2.3 Support for ( 等) procurement (Project management, etc.) 6.3 6.4 運用 6.4 Operation 6.5 Helpdesk 6.1 Support 6.1全体計画 for master 策定支援 plan formulation 6.2.2 Support for procurement 6.2 1 調達支援 (requirements ( 等) definition, etc.) 6.3 System integration (design/development) 6.3 ハードウェア更改 6.3 機能追加 6.6 Maintenance 6.7 Tasks incidental to procurement of devices Hardware maintenance Software maintenance Application maintenance System infrastructure maintenance 6.8 Tasks incidental to procurement of iDC equipment ・ 設備) 6.9 Network procurement 6.12 Security Figure 6-1 Classification of procurement of services 269 Table 6-1 Explanation of services Service 6.1 Support for master plan formulation 6.2 Support for procurement 6.3 System integration (design/development) 6.4 Operation 6.5 Helpdesk 6.6 Maintenance 6.7 Tasks incidental to procurement of devices 6.8 Tasks incidental to procurement of iDC equipment 6.9 Network procurement 6.10 Cloud service 6.11 Cloud construction 6.12 Security 6.13 Other (to be created) Service operation Planning the systematization initiative and creating a systematization plan Supporting service for ministerial procurements: e.g. implementation of requirements definition, deciding on procurement policies/procedures, creation of procurement specifications, request for comments, evaluation of contractors, and project management. Service operations concerning information system integration: e.g. design, development, migration, operation, operation/maintenance, design of information systems. Service operations concerning information systems (“6.5 Helpdesk” may be considered as part of the operations of 6.4; however, it is separately described in this Chapter) Service operations concerning helpdesk to respond to inquiries from users on system operation Service operations of information system maintenance: e.g. correction of information system faults, modification of system/software products after delivery and adaptation to changed environments Service operations generated incidental to procurement of devices(*excluding maintenance): e.g. installation, configuration of devices necessary for information systems (including ready-made software, such as OS which is inseparable from hardware) Service operations such as installation and configuration of various equipment in facilities (data center) prepared by the procurers, and operation monitoring of relevant systems (and incidental operations) Services related to construction of local networks, such as LAN and WAN (Wide Area Network), and service operations incidental to service procurement, such as WAN service and internet service. Service operations using cloud system services Service operations to construct cloud systems This section describes security cautions in procurement of services and security approaches during construction of information systems Service operations not included in 6.1 – 6.12, such as procurement of business package software. 270 6.1.Support for master plan formulation 6.1.1. Definition of procurement area “Support for master plan formulation” refers to support provided by contractors to procurers in formulating master plans concerning system integration/operations. If reforms are being considered in the business process/system/organization for the formulation of master plans, such considerations shall be conducted during this process. Planning phase Requirements definition 要件定義 phase Operation/maintenance 運用・保守フェーズ phase Development phase 開発フェーズ 6.2 6.2.3 Support for ( 等) procurement (Project management, etc.) 6.3 6.4 運用 6.4 Operation 6.5 Helpdesk 6.1 Support for master plan formulation 6.2.2 Support for procurement 6.2 1 調達支援 (requirements ( 等) definition, etc.) 6.3 System integration (design/development) 6.3 ハードウェア更改 6.3 機能追加 6.6 Maintenance 6.7 Tasks incidental to procurement of devices Hardware maintenance Software maintenance Application maintenance System infrastructure maintenance 6.8 Tasks incidental to procurement of iDC equipment ・ 設備) 6.9 Network procurement 6.12 Security Figure 6.1-1 Items corresponding to the areas of procurement of services 271 6.1.2 Services to be listed in specifications 6.1.2.1. Typical service operations The following table shows services to be included in specifications. The corresponding SLCP-2007 1 activities are also given. For actual procurement, correspondence to SLCP activities should be examined so as not to omit necessary information. To write specifications, a draft of procurement specifications should be prepared by selecting appropriate items while coordinating with the corresponding Program Management Office (PMO). Service operations 1. Systematization initiative 2. Systematization plan SLCP-2007 activity Outline of service operations Extracting issues on existing systems(* for existing systems) Study on demand for systematization Study on technological trends Formulating systematization initiative, etc. Considering system outline Formulation of schedule of design/development/migration/ operation Implementation of rough estimates Formulating systematization plan , etc. 1 1.4.2 Systematization initiative 1.4.3 Systemization plan Chapter/section corresponding to Basic Guidelines for 2 Procurement (and its title) - - Software Life Cycle Processes-Japan Common Frame 2007 (SLCP-JCF 2007), Information-technology Promotion Agency, Japan (in Japanese) 2 The “Basic Guidelines for Government Procurement Related to Information Systems”, March 2007, Ministry of Internal Affairs and Communications (in Japanese) http://www.soumu.go.jp/main_content/000070266.pdf 272 6.1.2.2. Explanations and examples of descriptions in specifications concerning services 1. Systematization initiative Item Outline of services Description Prior to system integration, systemization initiative shall be formulated by conducting studies on demand for systematization and studies on technological trends, etc. If there is an existing system, issues in the system shall be identified. Suggested input Requirements definition document and design document for (Prepared by the existing systems (*for existing system) procurer) Demands from procurers for systematization Set of relevant materials in cases where there are materials concerning the previous optimization plan Product Systematization initiative document (Prepared by the contractor) Matters to be described in specifications Requirements for systematization initiative shall be described [1. Basic requirements to be listed] ・ Study of demand for systematization ・ Study of technological trends ・ Formulation of systematization initiative, etc. [2. Requirements to be added depending on type/characteristics of project] ●For existing systems ・ Identify issues on existing systems Example/explanation of [1. Basic requirements to be listed] a description in (1)Studies on demand for systematization specifications A study of demand for systematization shall be conducted by interviewing persons concerned. (2) Study of technological trends Applicability shall be examined and issues involved in application shall be organized through the study of trends of the most advanced technologies both in Japan and overseas. (3)Formulation a systematization initiative A systematization initiative document shall be formulated to clarify the entire structure of new system, system integration policies, estimated costs, outline of suggested effects, etc. [2. Requirements to be added depending on type/characteristics of project] 273 ●For existing systems (1) Identifying issues on existing systems Problems in existing system shall be identified through interviews with users and organizing issues to be resolved. Notes on characteristics of projects/information - systems Notes on security In the case of information systems that deal with critical information, security policies systematization initiative 274 shall be included in the 2. Systematization plan Item Description Outline of service Upon giving shape to the future image of the system and making operations rough estimates, design/development/operation schedule shall be formulated based on the systematization initiative document and estimates. These descriptions shall be compiled into a systematization plan. Suggested input Requirements definition document and design document of existing (Prepared by the systems (*for existing systems) procurer) Demand from procurer for systematization Product Systematization plan (Prepared by the Optimization plan (*for systems subject to optimization) contractor) Matters to be Enter requirements for systematization plans described in [1. Basic requirements to be listed] specifications ・ System outline shall be examined. ・ Design/development/operation schedule shall be formulated. ・ Rough estimates shall be made. ・ Systemization plans shall be prepared. [2. Requirements to be added depending on type/characteristics of project] ●For systems subject to optimization ・Optimization plan shall be prepared. Example/explanation [1. Basic requirements to be listed] of a description in (1) Consideration of system overview specifications System function diagram shall be created upon defining and organizing basic requirements for functions to be mounted on the system. Hardware diagram, software diagram, network diagram shall be created upon considering rough system configuration. (2)Formulation of design/development/operation schedule Overall schedule for system development/operation shall be formulated upon considering the period required for system integration. (3) Implementation of rough estimates Rough estimates of costs required for system integration shall be made. (4) Formulation of systematization plan 275 The following documents shall be created: a systematization plan that includes a future image of the system, design/development/operation schedule, and the result of rough estimates. A systematization plan shall define the framework and roles of procurers and contractors, constraints and prerequisites and standard management guidelines to be observed. [2. Requirements to be added depending on type/characteristics of project] ●For systems subject to optimization (1) Formulation of optimization plans An “optimization plan Shall be created, which defines overview of target business/system, details of implementation of optimization, optimization process table, existing and future systems, and list of index of optimization effect/service index, based on the Guidelines for Business/System Optimization Plan. Notes on Optimization plans for systems subject to business/system characteristics of optimization shall be created, as defined in the Guidelines for projects/information Business/System Optimization Plan. systems Notes on security In cases of information systems that deal with critical information, systemization plans shall include considerations for security. 276 6.1.3. Deliverable product and timing of delivery The table below lists typical deliverable products and timing of delivery. The official name of each product and its delivery deadline needs to be entered in accordance with the actual situation. Service Deliverable product Delivery deadline 1.Systematization initiative Systematization initiative At the completion of the project 2. Systematization plan Systematization plan At the completion of the project Optimization plan 6.1.4. Suggested input The following table shows input and timing to be presented to a procurer (proposer) in advance. The official name of each product and its delivery deadline need to be entered in accordance with the actual situation. Service Input Timing for presenting input 1. Systematization Requirements definition At the time of tender publishing initiative document and design document of existing system, etc. Demand from the procurer for At the time of tender publishing systematization 2. Systematization plan Concept of systematization At the time of tender publishing Requirements definition At the time of tender publishing document and design document of existing system, etc. Demand from procurer for At the time of tender publishing systematization 6.1.5. Division of roles In separated/breakout procurement, the division of roles among procured services, related procurement and the relevant procurement should be clarified in accordance with the scope of separated orders and the ministerial policies and presented at the time of tender publishing. When considering procurement, services to be realized in the entire procurement should be identified. A clear division of roles and services should be specified and a table of the division of roles should be compiled so that the concerned parties can agree that there are no omissions/errors in services/roles in the breakout procurement. 277 6.2. Support for procurement 6.2.1. Definition of procurement area Support for procurement refers to support for operations of procurers at the time of design/development. This document covers two services: namely, “6.2.2 Support for procurement in requirements definition phase” and “6.2.3 Support for procurement in design/development phase, such as project management.” Basic design Requirements definition Detailed design Development /test /migration Operation /maintenance Support for Major services Support for project management requirements (formulation of project plan, progress management, issue management, change definition management, quality management, risk management, etc.) Support for procurement following basic Support for procurement (creation of specifications, creation of assessment criteria, etc.) design (creation of specifications, creation of Support for other operations assessment criteria, (product management, operation of conferences, etc.) etc.) 6.2.2 Support for By TRM classification procurement in the 6.2.3 Support of procurement following design/development, such as project management requirements definition phase Figure 6.2-1 Classification of services in support for procurement Service classification 6.2.2 Support for procurement in requirements definition phase Applicable service operations The contractor shall provide support for operations, such as implementation of requirements and procurement of goods and services (support for determining procurement policies/procurement method, support for creation of procurement specifications, and support for request for comments and evaluation of contractors). 6.2.3 Support for procurement following The contractor shall provide support for service operations, such design/development, such as project as project management concerning system development and management procurement of goods and services (support for determining procurement policies/procurement method, support for creation of procurement specifications, and support for request for comments and evaluation of contractors). 278 6.2.2. Support for procurement in the requirements definition phase 6.2.2.1. Definition of procurement area “Support for procurement in requirements definition phase” refers to support operations in requirements definition phase, such as support for requirements definition and support for creation of procurement specifications for system design/development based on the definition (See Figure 6.2-1 and Figure 6.2-2). Please refer to 6.2.3 for procurement support operations concerning projects following the design/development operations (system integration operations), since it is not included in this section. Planning phase Requirements definition 要件定義 phase Operation/maintenance 運用・保守フェーズ phase Development phase 開発フェーズ 6.2 6.2.3 Support for ( 等) procurement (Project management, etc.) 6.3 6.4 運用 6.4 Operation 6.5 Helpdesk 6.1 Support 6.1全体計画 for master 策定支援 plan formulation 6.2.2 Support for procurement (requirements definition, etc.) 6.3 System integration (design/development) 6.3 ハードウェア更改 6.3 機能追加 6.6 Maintenance 6.7 Tasks incidental to procurement of devices Hardware maintenance Software maintenance Application maintenance System infrastructure maintenance 6.8 Tasks incidental to procurement of iDC equipment ・ 設備) 6.9 Network procurement 6.12 Security Figure 6.2-2 Scope of the applicable services in the process of information system 279 6.2.2.2. Services to be included in specifications 6.2.2.2.1. Typical services The following table shows services to be included in the specifications. Corresponding SLCP-2007 3 activities are also given. For actual procurement, the correspondence to SLCP activities should be checked so as not to omit necessary information.. Items corresponding to the Basic Guidelines on Procurement (BGP) 4 are also listed. To write specifications, a draft of procurement specifications should be prepared by selecting appropriate items while coordinating with the corresponding Program Management Office (PMO). Service operations 1. Confirmation/evaluation/ improvement/estimation of effects of the optimization plan 2. Support for requirements definition 3.Estimation of system cost 4.Support for procurement operations Outline of service operations Support for confirmation/ evaluation/improvement/ estimation of effects of the optimization plan Support for the following requirements definition ・ Definition of schedule ・ Requirements definition for business/functions ・ Requirements definition for system architecture ・ Requirements definition for information/data ・ Requirements definition for user interfaces ・ Requirements definition for external interfaces ・ Requirements definition for networks ・ Requirements definition for software ・ Requirements definition for hardware ・ Requirements definition for information security ・ Requirements definition for design/development ・ Requirements definition for tests ・ Requirements definition for migration ・ Requirements definition for operation/maintenance Construction of system/estimation of operation cost based on requirements definition implemented in Section 2. Support for procurement-related operations, such as the creation of a procurement plan, creation of procurement specifications, response to request for comments and evaluations from contractors, etc. 3 Activities of SLCP-2007 Chapter and section of specifications corresponding to BGP (and its title) 1.4.3 Systematization plan 1.5.2.4 Definition of function requirements 1.5.2.5 Definition of non-function requirements 1.6.2 Definition of system requirements 1.5.2.6 Requirements definition concerning schedule 1.5.2.5 Definition of non-function requirements 1.1.2 Preparation of presentation request 1.1.3 Preparation and renewal of contract 3.Infromation system requirements 4.Requirements for scale/performance 5. Requirements for reliability, etc. 6.Requreiments for information security 7.Information operation environment 8. Requirements definition for tests 9. Requirements definition for migration 10. Requirements definition for operation 11. Requirements definition for maintenance Software Life Cycle Processes-Japan Common Frame-2007 (SLCP-JCF 2007), Information-technology Promotion Agency, Japan (in Japanese) 4 The “Basic Guidelines for Government Procurement Related to Information Systems”, March 2007, Ministry of Internal Affairs and Communications (in Japanese) http://www.soumu.go.jp/menu_news/s-news/2007/pdf/070301_5_bs2.pdf 280 6.2.2.2.2. Explanation on services and examples of descriptions in specifications 1. Confirmation/evaluation/improvement/estimation of effects of optimization plans Item Description Outline of Service To confirm and evaluate the optimization plan, and make operations improvements as necessary. To provide support for estimation of optimization effects. Suggested input ・ Optimization plan (Prepared by the procurer) Product (Prepared by the ・ Report on the optimation plan in terms of the confirmation/evaluation/improvement/estimation of effects contractor) Matters to be [1. Basic requirements to be listed] described in ・ Confirmation/evaluation/improvement proposals for optimization specifications plans ・ Estimation of the effects at the time of implementing the plan Example/explanation ○The contractor shall make proposals for of a description in confirmation/evaluation/improvement proposals of an optimization specifications plan. The contractor shall make confirmation/evaluation and improvement proposals to check if an optimization plan presented by the Ministry is in conformity with “the Basic Guidelines for Government Procurement Related to Information Systems,” “Business/System Optimization Guidelines” and the “Information Network (Common System) Optimization Plan of the Ministry of ___.” ○The contractor shall make estimation of effects at the time of implementing the plan, shall confirm details estimated in the optimization plan with respect to the effects of the realization of the plan, such as a reduction of costs and/or a reduction of operation processing time, and shall make revisions when necessary. Notes on characteristics of a This operation becomes necessary only when an optimization plan is project/information created in “6.1 Support for formulating master plan” system Notes on security - 281 2. Support for requirements definition Item Description Outline of Service Support for requirements definition concerning system and business operations procurement. Suggested input ・ Systemization plan (Prepared by the ・ Optimization plan (* when there is an optimization plan) procurer) ・ Requirements definition document/design document of existing system, etc. (* when there is an optimization plan) ・ Other information to be provided as needed by contractor Product ・ Requirements definition document (Prepared by the contractor) Matters to be [1. Basic requirements to be listed] described in Support for requirements definition with respect to the following specifications items: ・ Definition of schedule ・ Requirements definition for business/functions ・ Requirements definition for system architecture ・ Requirements definition for information/data ・ Requirements definition for user interfaces ・ Requirements definition for external interfaces ・ Requirements definition for networks ・ Requirements definition for software ・ Requirements definition for hardware ・ Requirements definition for information security ・ Requirements definition for design/development ・ Requirements definition for tests ・ Requirements definition for migration ・ Requirements definition for operation/maintenance Example/explanation ○Implementation of requirements definition of a description in The following requirements shall be defined and requirements specifications definition documents shall be compiled, based on the “Draft Optimization Plan” prepared by the Ministry, guidelines separately presented by the Ministry and consultation with the Ministry. A) Definition of schedule B) Requirements definition for business/functions C) Requirements definition for system architecture D) Requirements definition for information/data E) Requirements definition for user interfaces 282 Item Description F) Requirements definition for external interfaces G) Requirements definition for networks H) Requirements definition for software I) Requirements definition for hardware J) Requirements definition for information security K) Requirements definition for design/development L) Requirements definition for tests M) Requirements definition for migration N) Requirements definition for operation/maintenance Notes on characteristics of If organizational change happens, its effects shall be discussed in the projects/information requirements definition. systems Notes on security Procurers and creators of specifications shall define information security requirements in conformity with the “Standards for Information Security Measures for the Central Government Computer Systems” and the information security policies of ministries. The definition of the following requirements shall be specifically clarified since they are required to be stated in specifications by the “Basic Guidelines for Government Procurement Related to Information Systems”: (1) Definition of authority, and (2) Definition of security measures 283 3. Estimation of system cost Item Description Outline of Service To estimate the cost for system integration/operation from the results operations of requirements definition Suggested input ・ Requirements definition document (Prepared by the (for product stated in Section 2) procurer) Product ・ Estimated cost of system integration (draft) (Prepared by the ・ Estimated cost of operations (draft) contractor) Matters to be [1. Basic requirements to be listed] described in ・ Cost estimation and creation of cost estimation document specifications Example/explanation ○Cost estimation and creation of estimated cost document of a description in ・ The contractor shall estimate the cost of defined functions and specifications services, system integration and operation expenditure based on the requirement definition document, and shall compile an estimated cost document. ・ Approval of a relevant officer shall be obtained with respect to calculation items, calculation method and calculation type. Notes on characteristics of - projects/information systems Notes on security - 284 4. Support for procurement operations Item Outline of Service operations Suggested input (Prepared by the procurer) Product (Prepared by the contractor) Matters to be described in specifications Example/explanation of a description in specifications Description Support for operations related to the procurement of design/development, such creation of a procurement plan, creation of procurement specifications, request for comments, and evaluations of contractors, etc. ・ Optimization plan (* if there is an optimization plan) ・ Requirements definition document (for product listed in Section 2) ・ Procurement plan document (draft) ・ Procurement specifications (draft) ・ Outline for creating bid materials (draft) ・ Evaluation procedures (draft) ・ List of evaluation items (draft) ・ Evaluation criteria document (draft) ・ Table of scores (draft) ・ Table of responses to request for comments ・ Explanations on bid announcement (draft) ・ Budget justification materials needed after bid announcement (draft) [1. Basic requirements to be listed] ・ Support for formulating procurement method/procedures ・ Support for creating materials related to procurement procedures, such as procurement specifications (draft), outline for creating bid materials (draft), evaluation procedures, list of evaluation items, etc. ・ Support for request for comments ・ Support for evaluation of bidders [2. Requirements to be added depending on type/characteristics of project] (Project falling under the category of a specific information system) (project with an estimated price of design/development exceeding ¥0.5 billion) ・ Support for creating a procurement plan document (draft) ・ Support for responding to remarks from a government-level Project Management Office and ministerial-level Project Management Offices. [1. Basic requirements to be listed] ○Support for creating procurement method/procedures ・ The contractor shall examine and propose the best procurement method in accordance with the scale and characteristics of the project. ○Support for creating materials concerning procurement procedures, such as procurement specifications (draft), outline for creating bid materials (draft), evaluation procedures, list of evaluation items, etc. ・ The contractor shall support the creation of procurement specifications (draft) and outlines for creating bid materials (draft), shall support the procurement of design/development contractors, based on the requirements definition document. Procurement specifications (draft) shall be created from a fair and 285 Item Description neutral perspective, without making assumptions on specific technology or devices/tools. ・ The contractor shall support the creation of materials (evaluation procedures/list of evaluation items/certificate of confirmation, etc.) necessary for selection of contractors in accordance with the procurement method. ○Support for response to request for comments ・ The contractor shall provide support for creating responses to the opinions and inquiries received, when comments are requested, ・ The contractor shall present the revision and finalization of procurement specifications (draft) when necessary, based on the results of request for comments. ○Support for evaluation on bidders ・ The contractor shall provide support for technical review and present evaluation reports for the Ministry. The contractor shall examine whether every item of proposals and certificates of confirmation presented by bidders are meeting requirements, and compile items with unclear descriptions or not meeting requirements into a list and present the list to the Ministry. [2. Requirements to be added depending on type/characteristics of project] ●Projects under the category of specific information systems ○The contractor shall provide support for creating a procurement plan (draft). The contractor shall create a procurement plan document (draft) based on the “Basic Guidelines for Government Procurement Related to Information Systems.” ○The contractor shall provide support for responding to remarks made by a government-level Project Management Office and ministerial-level Project Management Offices. The contractor shall provide support for creating materials and shall give explanations on created products when remarks or inquiries are made by a government-level Project Management Office and ministerial-level Project Management Offices. Notes on characteristics of projects/information systems The “Basic Guidelines for Government Procurement Related to Information Systems” requires creation of a procurement plan in the cases of specific information systems (projects with estimated price of design/development exceeding ¥0.5 billion). Notes on security - 286 6.2.2.3. Deliverable product and timing of delivery The following table shows the deliverable product and delivery timing. The official names and delivery timing of each product should be listed in accordance with the actual situation. Service operations Deliverable product Delivery timing 1. Report on confirmation After conclusion of contract Confirmation/evaluation/ evaluation/improvement proposals for (example of a 6-month project: improvement proposal optimization plans and estimation of effects around 1.5 months after the for optimization plan conclusion of contract) and estimation of effects 2.Support for Requirements definition document requirements definition After conclusion of contract (example of a 6-month project: around 2.5 months after the conclusion of contract) 3.Estimation of system Estimation of cost of system integration After implementation of cost Estimation of operation cost requirements definition 4.Support for Procurement plan document (draft) Date designated by procurement Procurement specifications (draft) ministries/agencies operations Outline for creating bid materials (draft) Evaluation procedures (draft) List of evaluation items (draft) Evaluation criteria document (draft) Table of scores (draft) Table of responses to request for comments Explanations on bid announcement (draft) Budget justification materials needed after bid announcement (draft) 287 6.2.2.4. Suggested input The following table shows the input and timing to be presented to procurers (or proposers) in advance. The official names and delivery timing of each input should be listed in accordance with the actual situation. Service operations Input 1. Confirmation/evaluation/ Timing to present input Optimization plan At the time of formulation for the improvement proposal for optimization plan optimization plan and estimation of effects 2.Support for requirements Systematization plan At the time of release of definition Optimization plan specifications (reflecting Section 1) Date designated by ministries/agencies 3.Estimation of system cost 4.Support for procurement operations Requirements definition document After implementation of (product in Section 2) requirements definition Optimization plan After operations of requirements Requirements definition document definition (product stated in Section 2) (*A set of support operations, such as requirements specifications for next-term infrastructure information system of the Ministry of ___, 2010) Confirmation/evaluation/improvement proposal for optimization plan and estimation of effects Creation of next-term system procurement plan Specifications for request for comment, etc. Estimation of system cost based on the draft of specifications for request for comment (requirements definition) (Creation of rough draft) (Creation of final draft (Creation of draft) (Creation of estimation) Creation of draft of WBS items related to support for technical review, etc. (Reference) Revision of optimization plan Next-term system requirements specifications (Draft creation) (Intra-ministerial coordination/approval procedure) (Creation of specification) (Intra-ministerial coordination/coordination with MIC) Figure 6.2-3 Example of table of overall schedule 288 March February January December November October September August July Fiscal Year 2010 6.2.3. Support for procurement following design/development, such as project management. 6.2.3.1. Definition of procurement area “Support for procurement following design/development, such as project management” in this section refers to procurement support operations, etc., such as project management after the design/development phase. (See Figure 6.2-1 and Figure 6.2-4). Planning phase Requirements definition 要件定義 phase Operation/maintenance 運用・保守フェーズ phase Development phase 開発フェーズ 6.4 運用 6.4 Operation 6.2.3 Support for procurement (Project management, etc.) 6.5 Helpdesk 6.1 Support 6.1全体計画 for master 策定支援 plan formulation 6.2.2 Support for procurement 6.2 1 調達支援 (requirements ( 等) definition, etc.) 6.3 System integration (design/development) 6.3 ハードウェア更改 6.3 6.6 Maintenance 6.7 Tasks incidental to procurement of devices Hardware maintenance Software maintenance Application maintenance System infrastructure maintenance 6.8 Tasks incidental to procurement of iDC equipment ・ 設備) 6.9 Network procurement 6.12 Security Figure 6.2-4 Scope of applicable services in the process of information system 289 6.2.3.2. Services to be stated in specifications 6.2.3.2.1. Typical services The following table shows services to be included in specifications. The corresponding SLCP-2007 53 activities are also given. For actual procurement, correspondence to SLCP activities shall be examined so as not to omit necessary information. Items corresponding to the Basic Guidelines on Procurement (BGP) 64 are also listed. To write specifications, a draft of procurement specifications shall be prepared by selecting appropriate items while coordinating with the corresponding Program Management Office (PMO). Outline of service operations 1.Project management 2.Support for procurement 3.Support for other operations Activities of SLCP-2007 Outline of service operations Activities of SLCP-2007 Creation of a project plan, progress management, issue management, change management, quality management, risk management Support for procurement related operations, such as creation of a procurement plan document, creation of procurement specifications, response to request for comments, evaluation of contractors, etc. Product management, Operation of conferences 1.2.4 Planning 1.2.5 Implementation and management 5 Chapter and section of specifications corresponding to BGP (and its title) ― Software Life Cycle Processes-Japan Common Fram-2007 (SLCP-JCF 2007), Information-technology Promotion Agency, Japan (in Japanese) 6 The “Basic Guidelines for Government Procurement Related to Information Systems”, March 2007, Ministry of Internal Affairs and Communications (in Japanese) http://www.soumu.go.jp/menu_news/s-news/2007/pdf/070301_5_bs2.pdf 290 6.2.3.2.2. Explanation on services and examples of descriptions in specifications 1. Project management Item Description Outline of service Formulate project plans and define the method of project operations management, etc. Implement various types of management, such as progress management, issue management, change management, quality management, and risk management Suggested input ・ Systematization initiative (Prepared by the ・ Systematization plan procurer) ・ Optimization plan ・ Requirements definition document Product ・ Project management plan (Prepared by the ・ Report on project management contractor) Matters to be [1. Basic requirements to be listed] described in ・ Formulation of project plan specifications ・ Progress management ・ Issue management ・ Change management ・ Quality management ・ Risk management [2. Requirements to be added depending on type/characteristics of project] ・ Progress management by EVM Example/explanation [1. Basic requirements to be listed] of description of ○Formulation of project plan specifications A project plan shall be formulated, which prescribes the promotional method of project management operations and index for management, etc. When doing so, roles of project participants, contact list of concerned parties, and conferences, etc. shall be clarified in the project plan. ○Progress management Instructions shall be given to system developers to present WBS and other necessary materials that are needed for progress management. Requirements for the relevant documents shall be presented to contractors. The progress of work of the development contractor shall be periodically checked, and if there is a delay in schedule, support for 291 measures for recovery from the delay shall be provided upon identifying the causes and impacts, etc. ○Issue management Issues that may influence the progress of the project shall be appropriately managed, and the division of roles shall be considered to resolve the issues and support shall be given for managing resolution deadlines and for consideration of solutions. ○Change management Importance/target/implementation period of various specifications shall be examined and managed at the time of change in system specifications. ○Quality management Details of product and materials presented by the development contractor shall be confirmed and inquiries shall be made to indicate defects, etc., for the purpose of improving the quality of product, etc. ○Risk management Possible risks shall be identified, which may influence the progress of a project and measures for risk reduction/aversion or resolution shall be presented. [2. Requirements to be added depending on type/characteristics of project] ●For systems subject to optimization ○Progress management by EVM Quantitative progress management by EVM (Earned Value Management) shall be performed and reported, based on the WBS consulted and agreed between the procurer and the operation contractor for system development. Notes on characteristics of - projects/information systems Notes on security - 292 2. Support for procurement Item Outline of service operations Suggested input (Prepared by the procurer) Product (Prepared by the contractor) Matters to be described in specifications Example/explanation of a description in specifications Description Support for operations related to the procurement of design/development, such as creation of a procurement plan, creation of procurement specifications, response to request for comments, and evaluation of contractors, etc. ・ Optimization plan (* only when there is one) ・ Requirements definition document ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ Procurement plan document (draft) Procurement specifications (draft) Outline for creating bid materials (draft) Evaluation procedures (draft) List of evaluation items (draft) Evaluation criteria document (draft) Table of scores (draft) Table of responses to request for comments Explanations on bid announcement( draft) Budget justification materials needed after bid announcement (draft) [1. Basic requirements to be listed] ・ Support for procurement methods/procedures ・ Creation of materials concerning procurement procedures, such as procurement specifications (draft), outline for creating bid materials (draft), evaluation procedures, list of evaluation items, etc. ・ Support for response to request for comments ・ Support for evaluation of bidders [2. Requirements to be added depending on type/characteristics of project] (Projects falling under the category of specific information system) ・ Creation of procurement plan (draft) ・ Support for responding to remarks made by a government-level Project Management Office and ministerial-level Project Management Offices. [1. Basic requirements to be listed] ○Support for procurement methods/procedures ・ The contractor shall examine and propose the best procurement procedures based on the size and characteristics of the project ○The contractor shall create materials related to procurement procedures, such as procurement specifications (draft), outline for creating bid materials (draft), evaluation procedures and list of evaluation items, etc. ・ The contractor shall create procurement specifications (draft) and outline for creating bid materials (draft), based on the requirements definition, for the procurement of design/development contractor. Procurement specifications (draft) shall be created from a fair and neutral perspective, without making assumptions on specific technology or devices/tools. 293 Item Description ・ The contractor shall create materials (evaluation procedures/list of evaluation items/certificate of confirmation, etc.) necessary for the selection of contractors in accordance with the method of procurement. ○Support for response to request for comments ・ The contractor shall support responses to opinions and inquiries received, when comments are requested, ・ The contractor shall provide support for the revision and finalization of procurement specifications (draft) when necessary, based on the results of request for comments. ○Support for evaluation of bidders ・ The contractor shall provide support for technical review and report evaluation results to the Ministry. The contractor shall also examine whether every item of proposals and certificates of confirmation presented by bidders is meeting requirements, and shall compile items with unclear descriptions or not meeting requirements into a list and present the list to the Ministry. Notes on characteristics of projects/information systems [2. Requirements to be added depending on type/characteristics of project] ●Projects falling under the category of specific information systems ○The contractor shall create a procurement plan document (draft) based on guidelines and the “Basic Guidelines for Government Procurement Related to Information Systems.” ○The contractor shall provide support for responding to remarks made by a government-level Project Management Office and ministerial-level Project Management Offices. ・The contractor shall provide support for the creation of materials and shall give explanations on the created products when remarks or inquiries are made by a government-level Project Management Office and ministerial-level Project Management Offices. The “Basic Guidelines for Government Procurement Related to Information Systems” requires the creation of a procurement plan document in cases of a specific information system (project with estimated price of design/development exceeding ¥0.5 billion). Notes on security - 294 3. Support for other operations Item Description Outline of service Support for operations of the procurer, such as product management operations and conference operations, etc. Suggested input - (Prepared by the procurer) Product ・ Product management plan (draft) (*) (Prepared by the ・ Communication management plan (draft) (*) contractor) ・ Conference minutes (draft) (*) Not necessary if it is defined in the project management plan Matters to be [1. Basic requirements to be listed] described in ・ Product management specifications ・ Operation of conferences Example/explanation [1. Basic requirements to be listed] of a description in ○Product management specifications ・ The contractor shall support acceptance by the procurers by confirming that the deliverable products of the development contractor is complete and its quality is satisfactory. ・ The contractor shall support version management of delivered products. ○ Operation of conferences ・ The contractor shall support in project defining conferences and shall clarify participants and operating body, etc. ・ With respect to conferences operated by contractors of the business in question, the contractor shall create and present the minutes (draft) within __ business days after the relevant conference. ・ With respect to conferences hosted by procurers, the contractor shall provide support for creation of conference materials when necessary. Notes on characteristics of - projects/information systems Notes on security - 295 6.2.3.3. Deliverable product and timing of delivery The table below lists typical deliverable products and timing of delivery. The official name of each product and its delivery deadline should be entered in accordance with the actual situation. Service 1.Project management Deliverable product Delivery deadline Project plan Project plan: within one month Report on project management after conclusion of a contract Report on project management: monthly 2.Support for Procurement plan (draft) Date designated by procurement Procurement specifications (draft) ministries/agencies Outline for creating bid materials (draft) Evaluation procedures (draft) List of evaluation items (draft) Evaluation criteria document (draft) Table of scores (draft) Table of responses to request for comments Explanations on bid announcement (draft) Budget justification materials needed after bid announcement (draft) 3.Support for other Minutes Within __ business days after operations conference 6.2.3.4. Suggested input The following table shows input and timing to be presented to procurers (proposers) in advance. The official name of each product and its delivery deadline need to be entered in accordance with the actual situation. Service operations Input Timing to present input 1.Project management - - 2.Support for procurement Optimization plan After implementation of Requirements definition document requirements definition - - 3.Support for other operations 6.2.3.5. Division of roles In separated/breakout procurement, the division of roles among procured services, related procurement and the relevant procurement should be clarified in accordance with the scope of separated orders and the ministerial policies and presented at the time of tender publishing. When considering procurement, services to be realized in the entire procurement should be identified. A clear division of roles and services should be specified and a table of the division of roles should be compiled so that the concerned parties can agree that there are no omissions/ errors in services/roles in the breakout procurement. 296 6.3. System Integration (Design/Development) This Chapter covers services related to construction of information systems, including design, development, migration and operational design. Planning phase Requirements definition 要件定義 phase Operation/maintenance 運用・保守フェーズ phase Development phase 開発フェーズ 6.2 6.2.3 Support for ( 等) procurement (Project management, etc.) 6.3 6.4 運用 6.4 Operation 6.5 Helpdesk 6.1 Support 6.1全体計画 for master 策定支援 plan formulation 6.2.2 Support for procurement 6.2 1 調達支援 (requirements ( 等) definition, etc.) 6.3 System integration (design/development) 6.3 ハードウェア更改 6.3 機能追加 6.6 Maintenance 6.7 Tasks incidental to procurement of devices Hardware maintenance Software maintenance Application maintenance System infrastructure maintenance 6.8 Tasks incidental to procurement of iDC equipment ・ 設備) 6.9 Network procurement 6.12 Security Table 6.3-1 Items corresponding to the classification of procurement of services 6.3.1. Definition of procurement areas Services in system integration (design/development) are classified into four groups in accordance with the situation in which information systems are developed: namely, new development, system renewal, hardware renewal, and function addition. The definition of each group is described below. Service Definition New development Referring to a system development project to develop a new information system for services in which no information system currently exists. System renewal Referring to a system development project due to changes in laws and operations, such as full-fledged application renewal and system integration. 297 Hardware Referring to a system development project for application migration due renewal to hardware renewal. Function addition Referring to a function addition project at a subsystem level, design of existing system and a system improvement projects outside the contract to be executed by the development contractor/maintenance contractor. Please refer to “6.3.3 Application maintenance” for additions lower than subsystem level. 6.3.2 Services to be included in specifications 6.3.2.1. Typical service operations The following table shows services to be included in specifications. The corresponding SLCP-20077 activities are also given. For actual procurement, correspondence to SLCP activities should be examined so as not to omit necessary information. Items corresponding to the Basic Guidelines on Procurement (BGP) 8 are also listed. To write specifications, a draft of procurement specifications should be prepared by selecting appropriate items while coordinating with the corresponding Program Management Office (PMO). Service operations Outline of service operations Activities of SLCP-2007 1.Preparation for development environment Securing devices (hardware, development tools, etc.), and work site for development 1.6.1 Preparation for process initiation 2.Creation of the development plan Creating design/development plans (schedule, framework, division of roles, work details, development environment, development tools, product, etc.) 1.6.1 Preparation for process initiation 3.Basic design Function design (business function, etc.,), data design (conceptual model/logical model), screen design, form design, system architecture design, external interface design and information security design, which are based on the requirements definition. * The above is partially applied to function addition. 4.Detailed design Program design (list of development programs and definition of specifications, etc.), data design (physical model), screen design, form 1.6.2 Definition of system requirements 1.6.3 System architecture design 1.6.4 Definition of software requirements 1.6.5 Software architecture design 1.6.6 Detailed software design 7 Chapter and section of specifications corresponding to BGP Chapter II (5.1) Description of work Chapter XII (2) Method of development Chapter II (5.1) Description of work Chapter XII (2) Method of development Chapter II (5.1) Description of work Chapter XII (2) Method of development Chapter II (5.1) Description of work Chapter XII (2) Method of development Software Life Cycle Processes-Japan Common Frame 2007 (SLCP-JCF 2007), Information-technology Promotion Agency, Japan (in Japanese) 8 The “Basic Guidelines for Government Procurement Related to Information Systems”, March 2007, Ministry of Internal Affairs and Communications (in Japanese) http://www.soumu.go.jp/main_content/000070266.pdf 298 Service operations Outline of service operations 5.Unit test,, integration test, system test, connectivity test with other systems design, system architecture design, external interface design and information security design, which are based on the basic design Creating source code based on detailed design Creating test plans and gaining approval from the relevant sections Preparing for test devices/tools Implementing tests and response to detected faults Creating test result report 6.Acceptence test support 7.Migration Support for acceptance tests carried out by procurer, such as creation of drafts of acceptance test procedures, implementation of investigation on and countermeasures against faults and implementation of operation tests Migrating data necessary for operations and inputting initial data Migration form development to the live environment Activities of SLCP-2007 1.6.7 Creation of software code and test 1.6.8 Software integration 1.6.9 Software qualification test 1.6.10 System integration 1.6.11 System qualification test 1.6.13 Software acceptance support Chapter II (5.1) Description of work Chapter VIII Definition of test requirements Chapter XII (2) Development method 1.8.5Migration Chapter II (5.1) Description of work Chapter IX (1) Requirements concerning migration Chapter XII (2) Development method Chapter II (5.1) Description of work Chapter IX (2) Requirements concerning education Chapter II (5) Description of operations/ Deliverable product 8.User education Creating education plans and system usage manuals Implementing training for government officials 1.6.13 Software acceptance support 9.Transfer to operation/maintenance contractors Operation design Transfer to operation /maintenance contractors 10.Project management Implementing project management for design/development operations, including progress management, document management, information security management, issue/problem management, change management and configuration management Delivering necessary products, and making corrections if deemed necessary 1.7.1 Preparation for process initiation 1.8.1 Preparation for process initiation 3.1.2 Planning 3.1.4 Implementation and management 11.Acceptance Chapter and section of specifications corresponding to BGP 1.2.7 Delivery and completion 299 Chapter II(5.1) Description of work Chapter XII(2) Development method Chapter II (5.1) Description of work Chapter XII (2) Development method Chapter II (5) Description of work/deliverable product 6.3.2.2. Explanation on services and examples of descriptions in specifications Many services mentioned in the preceding section are common to all service types, whether it is new development, system renewal, hardware renewal, or function addition. Therefore, items in this section are applied to all service types unless otherwise stated, and a specific service type is indicated when necessary. 1. Preparation for development environment Item Outline of service Description Securing of necessary development devices and work site operations Suggested input Outline of new system infrastructure (scheduled) (Prepared by Operating environment procurer) Operating conditions Requirements definition document - Product (Prepared by contractor) Matters to be stated in [1. Basic requirements to be listed] specifications ・ Construction of system design and development environment (work site, devices and expendables) ・ Management of development environment Example/explanation Examples of descriptions in specifications of descriptions in ・ System design and development devices shall be prepared and specifications borne by the contractor. ・ Sufficient security measures for development environment (devices/work site, etc.) shall be taken. Notes on If development environment cannot be prepared on site, there is characteristics of room for considering creating a development repository. projects/information systems Notes on security Security measures for development environments ・ When a contractor prepares development environment (devices, work site, etc.), it shall take sufficient information security measures for the environments. 300 2. Creation of development plan Item Outline of service operations Suggested input (Prepared by procurer) Product (Prepared by contractor) Matters to be stated in specifications Example/explanation of descriptions in specifications Description Creation of design/development plan ・ ・ ・ ・ ・ ・ ・ ・ ・ Requirements definition document List of major operations Relationship between contractor and related contractors Outline of operations of concerned contractors Operation schedule Table of division of roles Document standards of the government Project plan Design/development plan [1. Basic requirements to be listed] ・ Contractor shall create a design/development plan in accordance with the central government’s standards, such as optimization guidelines, and shall finalize the plan upon coordination with ministries. ・ The project plan shall be created, including WBS (Work Breakdown Structure), critical path and milestones. [2. Requirements to be listed when necessary] ・ The contractor shall define documentation standards and development rules, and implementation of reviews to confirm that the development is being conducted accordingly. Examples of descriptions in specifications ○Project plan Contractor shall create a project plan. The following operations shall be implemented when creating the project plan. ・ Prior to the creation, necessary operations for the full-fledged operation of this system shall be organized and WBS documents shall be compiled. Details of operations and deliverable product, commencement and completion conditions shall be clarified by each task. Tasks shall be detailed as much as possible before the commencement so that actual progress and actual cost (AC) can be measured. ・ A dependence relationship of tasks and critical paths (group of tasks that cannot be delayed to avoid delay of the completion of project as a whole) shall be clarified and dates of commencement and completion and interim milestones for each task shall be established. ○Design/development plan ・ Prior to systematization, a document defining work the schedule related to the product, description of operations, personnel in charge, review plan, check-points, conditions for commencement/completion, and work process of the project shall be complied into a “Project Plan,” which shall be approved 301 by the Ministry upon consultation. Actual design/development operations shall be implemented based on the relevant “Project Plan.” ○Schedule ・ Creation of a schedule including an overall schedule and major milestones. ○Project framework ・ Entry of the necessary information of the project participants, such as the leaders and personnel in charge of each organization, and contact list, etc. ・ Clarification of assignments of management responsibility in the entire project and details of management. Notes on characteristics of projects/information systems Notes on security ○Division of roles ・ Clarification of roles of each project participant so that each can be aware of its own roles in the entire project. Some ministries require submission of documents separately. It is desirable to conform to procurement policies/guidelines stipulated by each ministry. In the case of considering the possibility of additional projects or correction projects, it is necessary to mention in the specifications that creation of estimates and calculation of the necessary number of processes may become necessary. Two types of documents describing tasks and schedules may be prepared: one for external use and another for internal management use. It is desirable to create the one for internal management use which contains the status of progress in the WBS. It is desirable to define the tasks of any responsible persons other than a contractor, such as compete relevant ministries, in addition to the tasks of the contractor. When defining the tasks of responsible persons other than a contractor, coordination becomes necessary. Thus, consultation with relevant ministries is necessary when making a rough draft. - 302 3. Basic design Item Description Outline of service Function design, data design, screen design, form design, system operations architecture design, external interface design, information security design, which are based on requirements definition. Suggested input ・ Requirements definition document (Prepared by ・ Basic design document for existing systems (excluding new procurer) development) ・ Security policies prescribed by each ministry ・ Standards for Information Security Measures for the Central Government Computer Systems Product ・ Basic design document (Function design document, data design (Prepared by document, screen design document, form design document, contractor) system architecture design document and external interface design document may be separately published) Matters to be stated in [1. Basic requirements to be listed] specifications ・ Items in the basic design document. ・ Design environment and work site are prepared by a contractor at the responsibility and expense of the contractor. ・ Response when there are changes in design due to a law amendment. ・ Cooperation with other contractors concerning the system to be procured. ・ Design of test environment and maintenance environment. [2. Requirements to be listed when necessary] ・ When developing a design mainly for a generic package, it is necessary to describe the process of the project and a fit and gap analysis to see if there are any gaps between the processes described in the requirements definition document and those of the package (excluding function addition). Example/explanation Examples of descriptions in specifications of descriptions in ○ Items in the basic design document. specifications ・ Function design (design for business function, exception handling design and operational function, etc.). ・ Data design (design of conceptual model and logical model using E-R diagram). ・ Screen sign. ・ Form design. 303 ・ System architecture design (technical design basis for software configuration and hardware configuration, etc.) ・ External interface design ・ Information security design ○Common requirements for design ・ Design of a live environment where this system runs, in addition to test environment and maintenance environment. ・ Design of environment (hardware and middleware for design and design tools, etc.) and work site, etc. shall be prepared by a constructor at the responsibity and expense of the constructor. ・ Management based on the Guidelines for Management of Configuration/Change stipulated in the project plan. ・ Work shall be implemented in cooperation with a process management contractor, project partners of this system and contractors concerning other system, which are to be procured separately. ○Design mainly for generic packages ・ Since this system will be developed under the premise of using generic packaged software, it is necessary to carry out a fit/gap analysis to determine the degree of fitness between the business requirements in the specifications and the introduced generic packaged software. Notes on Depending on a project, one contractor may carry out both the characteristics of requirements definition and design/development. Please refer to projects/information “6.2.1 Requirements definition” for descriptions concerning the systems requirements definition. Notes on security Information security design ・ Information security design in conformity with the Standards for Information Security Measures for the Central Government Computer Systems and information security policies of each ministry. 304 4. Detailed design Item Outline of service operations Suggested input (Prepared by procurer) Product (Prepared by contractor) Matters to be stated in specifications Example/explanation of descriptions in specifications Notes on characteristics of projects/information systems Notes on security Description Program design, data design, screen design, form design, system architecture design, external interface design and information security design, which are based on the basic design. ・ Detailed design of the existing system and program source (excluding new development) ・ Detailed design documents (Program design documents, detailed design documents, detailed screen design documents, detailed form design documents, detailed system architecture design documents and detailed external interface design documents are often published separately.) [1. Basic requirements to be listed] ・ Output items of detailed design [2. Requirements to be listed when necessary] ・ Cooperation for related contractors Examples of descriptions in specifications ○ Output items of detailed design ・ Program design (the list of programs to be developed, of specifications, etc.) ・ Data design (physical model) ・ Screen/form design (design based on development tools to be used) ・ System architecture design (design based on the software/hardware to be used) ・ Information security design (design based on the software/hardware to be used) ○Related contractors ・ Design materials shall be presented to related contractors and questions and inquiries shall be answered when necessary. - Information security design ・ Information security design shall be carried out in conformity with the Standards for Information Security Measures for the Central Government Computer Systems and information security policies of each ministry. 305 5. Unite test, integration test, system test, and connectivity test with other systems Item Description Outline of service Creation of source code based on detailed design operations Creation of test plans and gaining approval from relevant section Preparation for test devices and tools Implementation of each test and response to detected faults Creation of test results report - Suggested input (Prepared by procurer) Product The following data and documents are related to unit tests, (Prepared by integration tests and system tests: contractor) ・ Test data ・ Test plan ・ Test procedures (test specifications) ・ Test result/quality assessment report Matters to be stated in [1. Basic requirements to be listed] specifications ・ Creation of test plans ・ Creation of test procedures ・ Creation of test data ・ Outline of unit tests, integration tests and system tests ・ Handling of fault correction and investigation of causes ・ Creation of test results/quality assessment report Example/explanation Examples of descriptions in specifications of descriptions in ○Creation of test plans specifications The contractor shall submit test plans describing test policies, test procedures and the reason for tests for each test: unit test, integration test and system test. Below are the items to be listed in the test plan (1) Framework of implementation and roles of contractors (2) Detailed tasks and test schedule (3) Test environment (lines and equipment structure in test, and test coverage) (4) Test tools (5) Test data (6) Assessment criteria ○Creation of test procedures 306 Preparing test procedures by organizing a series of test cases (input and output and test criteria), test scenario and test data and procedures. ○Creation of test data (a) A contractor shall basically prepare the test data (b) Describe types of test data in the test plan by each test process ○Outline of unit test, integration test, and system test (1) Unit test To test if a program can properly work by the unit of the developed module. (2) Integration test The contractor shall verify the integrity of the software through tests in which the system is integrated in a stepwise manner to see programs or modules can function in the entire system. (3) System test (a) To see if this system is constructed as required. (b) To confirm that this system is deliverable. (c) To implement tests upon setting up assessment criteria to confirm that the software complies with specifications and is usable in the live environment. (d) Performance and stress tests are to confirm that the system works properly by putting it under stress similar to that of the live environment. (e) To confirm the following items: (i) Functionality ・ Both normal and abnormal system functions can operate according to the specifications. ・ Business coordination processing with other systems can function normally. ・ Meeting information security requirements. (ii) Reliability ・ Meeting reliability requirements. ・ Appropriate recovery processing at the time of failure. (iii) Operability ・ The system operates in accordance with the requirements and instruction and is easy to use. 307 (iv) Performance ・ Appropriate online processing, response time of batch processing and through-put. ・ The system works normally under limiting conditions (data volume, processing volume). ○Handling of fault correction, investigation of causes ・ When a correction is made, confirm that the relevant correction will not negatively affect other programs In addition to investigating the causes, such as mistakes in programing or design defect, investigation and analysis shall be performed with respect to the personnel in charge (for instance, if faults occur often in modules or components designed/developed by a specific staff member, investigation shall be focused on other modules and components designed/developed by the relevant staff member.) ○Test results/quality assessment report Report the number of test cases in proportion to program size, total number of detected faults, rate of detected faults in proportion to program size, number of completed tests/number of planned tests and actual number of faults/ estimated faults. - Notes on characteristics of projects/information systems Notes on security Security measures for test environment ・ If the test environment (devices, work site, test data, etc.) is prepared by a contractor, sufficient security measures shall be taken for the environment. 308 6. Acceptance test support Item Outline of service operations Description Support for acceptance tests conducted by a procurer, including creation of acceptance test procedures, implementation of investigation and contingency measures at the time of the occurrence of faults, and implementation of operation tests. Suggested input (Prepared by procurer) Product (Prepared by contractor) Matters to be stated in specifications Example/explanation of descriptions in specifications Notes on characteristics of projects/information systems Notes on security - ・ Acceptance test procedures ・ Report on acceptance tests [1. Basic requirements to be listed] ・ Creation of acceptance test procedures ・ Securing support staff for acceptance tests ・ Creation of the environment for an acceptance test ・ Preparation of acceptance test data ・ Analysis of faults and presentation of countermeasures ・ Implementation of program modification in line with the countermeasures prescribed by ministries Examples of descriptions in specifications ○Creation of acceptance test procedures ・ To create acceptance test procedures including specific procedures taken by acceptance testers and its results. It should be easy to understand for any person who is not familiar with system operations. ○Securing support staff for acceptance test ・ Acceptance test is led by the Ministry: however, support staff shall be employed when required. ○Creation of the environment for an acceptance test ・ Prepare an environment for an acceptance test as close to the actual live environment as possible. ○Preparation of acceptance test data ・ Prepare test data necessary for acceptance test ○Analysis of faults and presentation of countermeasures ・ Analyze faults detected in acceptance tests and gain the approval of the Ministry on countermeasures ○Implementation of program correction in line with the countermeasures prescribed by ministries ・ Correction based on the approved countermeasures It is desirable to conduct a preliminary acceptance test at a selected site in the case of a large scale project in which the system is installed at many locations. - 309 7. Migration Item Outline of service operations Suggested input (Prepared by procurer) Description Creation of various plans and procedures related to migration operations System migration rehearsal the under live environment and migration to the live environment ・ Input target data ・ Diagram of migration operations Matters to be stated in specifications ・ Migration plan ・ Migration procedures ・ Migration rehearsal specifications/quality assessment report ・ Migration program ・ Migration data ・ Report on migration results [1. Basic requirements to be listed] New development ・ The contractor shall help the procurer determine the specifications of migration data and coordinate with concerned parties. The contractor shall develop migration tools and programs when required ・ Data entry from paper-medium materials and data extraction/migration operations from the existing system Example/explanation of descriptions in specifications The following shall be entered only for migration from the development environment to the live environment in the case of new development, and are compulsory in cases of other service types. ・ Creation of migration plan ・ Creation of migration procedures ・ Creation of migration rehearsal specifications ・ Implementation of migration rehearsal under the live environment ・ Creation of migration rehearsal results/quality assessment report ・ Implementation of migration to the live environment ・ Creation of migration result report Examples of descriptions in specifications ○New development ・ The contractor shall confirm in advance contents and formats of data and implement migration operations upon confirming with responsible officers of the Ministry of ___ with respect to the method of migration (how to handle white space, sections without data and difference in data format, etc.). The contractor shall develop migration tools and/or programs to carry out migration, on as needed basis. ・ Migration operations include creation and registration of master data necessary for use of this system and conversion and installation of past data. Thus, migration framework shall be developed upon clarifying the roles of ministries related to the division of work necessary for migration. Migration operations Product (Prepared by contractor) 310 shall be carried out in accordance with the following procedures: (1) Organize migration target data upon consultation with the supervising section, (2) Determine data format for migration to this system and create tools to integrate the data into this system from that format when necessary, (3) Create migration data by newly inputting data in accordance with the data format or converging the existing data, (4) Integrate data into this system using a migration tool, etc., (5) Examine if migrated data is correctly integrated, and (6) Correct data and reconfirm that the data are properly corrected. Notes on characteristics of projects/information systems Notes on security ○Migration ・ Contractor shall implement various operations for migration, such as design/development of migration programs to the database of this system, migration operations and validation confirmation of migrated data, when necessary, presuming that existing data is provided. ・ Data shall be migrated into the live environment after installation in accordance with migration plan. At the time of migrating data, a preliminary rehearsal shall be carried out in accordance with migration plan. Explanation ・ Migration plan This document shall describe interested parties and roles, detailed schedule for migration, migration environments, migration methods and methods of preparing migration tools, etc. ・ Migration procedures This document shall describe the following in connection with migration to the production environment: detailed operations, verification methods, verification criteria, contingency plans and time schedules, etc. ・ Migration rehearsal specifications This document shall describe the following in connection with the migration rehearsal: detailed operations, verification methods, verification criteria, contingency plans and time schedules, etc. It is important to clarify tasks to identify which party is responsible for what tasks, as it is often the case that a number of concerned parties cooperate in the migration process; for instance, specifications for migration data extraction are defined by the design/development contractor and data extraction is done by the operation contractor - 311 8. User education Item Description Outline of service Creation of an education plan and operation manual operations Holding training for ministry officers Suggested input ・ Target, venue and period of educational training (Prepared by ・ Operation manual (existing) (excluding new development) procurer) Product ・ Education plan (Prepared by ・ Training text contractor) ・ Operation manual Matters to be stated in [1. Basic requirements to be listed] specifications ・ Creation of an operation manual ・ Requirements for holding training for system users (size and period, etc.) [2. Requirements to be listed when necessary] When a system is large in terms of the number of users and locations, the following operations are stated to offer an effective educational environment. ・ Creation of an education plan ・ Provision for an e-Learning function Example/explanation ・ Examples of descriptions in specifications of descriptions in ○Creation of the operation manual specifications ・ Create operation manual containing the method of operation of devices and usage of this system. ○Requirements for holding training for system users (size and period) ・ Implement group training of this system for system users. Create self-learning materials and compile a training guidebook, including methods of education and training and usage of teaching materials. ・ Create a training text upon consultation with the Ministry. When creating the text, care must be taken in the method of explanation and wordings, so that users can acquire the operation skills of this system in a short period of time. The contractor shall also give care to make the text understandable so that users can sufficiently understand by reading it through. ○Creation of the education plan ・ Create the education plan, including education and training 312 environment and the method of education and training, etc. ・ The contractor shall provide an e-Learning function so that learners can easily understand how to use this system in training conducted by trainees of the central training; and take necessary measures, such as providing videos of the central training as an additional training material, when necessary. When distributing teaching materials, the contractor shall prepare the necessary number of copies. - Notes on characteristics of projects/information systems Notes on security User education ・ Education on information security shall be offered to system users. 313 9. Transfer to operation/maintenance contractors Item Description Outline of service Operation design operations Transfer to operation management contractor and maintenance contractor Suggested input (Excluding new development) (Prepared by ・ Operation design (existing system) procurer) ・ Operation manual (existing system) Product ・ Operational design (Prepared by ・ Operation manual contractor) ・ Table of maintenance framework (draft) ・ Transfer plan ・ Transfer report Matters to be stated in [1. Basic requirements to be listed] specifications ・ Operation design for operational systems and applications to be developed ・ Creation of operation manuals ・ Creation of transfer plans and transfer reports ・ Transfer to operation contractor and maintenance contractor prior to the full-fledged operation of a new system ・ Answering to questions and handle requests for amendments regarding operation manuals during the term of the contract Example/explanation Examples of descriptions in specifications of descriptions in ○Operation design specifications ・ Carry out operation design for operational systems and applications to be developed. Identifying operation works as “works necessary for safe and stable operations of business and applications,” the system shall be designed by defining necessary work requirements in a systematic and comprehensive manner. ○Operation manual ・ Create an operation manual for the operation of this system ○Transfer plan Contractor shall create a transfer plan, including transfer framework/roles in transfer, detailed tasks and schedules, methods of transfer, assessment methods/criteria for transfer results. 314 The contractor shall handover in accordance with the transfer plan. After completing transfer, the contractor shall write transfer reports. ○Transfer to maintenance contractor Operations of software maintenance contractor concerning System , which is to be separately procured, will commence from Month, Fiscal Year N, contractor shall consult with relevant officer and implement content transfer of this Transfer software at the responsibility and expense of the contractor by the end of Month, Year, after selecting a maintenance contractor. ○Transfer to operation contractor ・ In order to contribute to the smooth implementation of operation works of the operation contractor after the start of full-fledged operations in Fiscal Year N, contractor shall develop, create and provide necessary documents for the operations of this system, which is followed by the provision of necessary training for the operation contractor by establishing a training period. Notes on Operation tools and procedure manual shall be provided when characteristics of necessary. projects/information systems - Notes on security 315 10. Project management Item Description Outline of service Implement project management for design/development operations, operations such as progress management, document management, information and security management, issue/problem management, change management, configuration management, etc. Suggested input - (Prepared by procurer) Product ・ Materials for progress management (Prepared by ・ Table of task management contractor) Matters to be stated in [1. Basic requirements to be listed] specifications ・ Progress management ・ Document management ・ Issue/problem management ・ Configuration management ・ Change management ・ Information security management Example/explanation Explanation of descriptions in ○Progress management specifications ・ Based on progress management materials, the status of progress shall be quantitatively analyzed and operation statuses shall be reported. Conference/information transmission plans by each operation process shall be created, and periodical reviews shall be implemented. When a delay occurs, operation modification plans, such as addition of workers and revision of the framework, shall be presented. ○Document management ・ When a contractor makes a correction/renewal of the result of the basic design, it must follow the guidelines for standard management for the “Plan of Design/Development Phase” (essentials for document management, essentials for change management), prepared by the Ministry of XXX. ○Issue/problem management ・ To manage operational issues in a unified manner, establish a 316 process of issue awareness, consideration of countermeasures, solution and reporting. ○Configuration management ・ To maintain consistency in the development of this software and establish traceability of changes in the project environment. ○Change management ・ When changes to matters listed in the procurement specifications and requirements definition document are necessary, approval from the relevant ministry shall be gained at an early stage, after confirmation of the location of change, description, reason, affected area and the magnitude of influence, etc. ○Information security management ・ Accident and fault in security systems shall be prevented in advance in each operational stage. Any damage shall be minimized when it occurs. Notes on This section describes project management services for the characteristics of design/development contractor. projects/information Please refer to “6.2.3 Project management” for project management systems services concerning the entire information system procurement. Carry out EVM progress management in the case of a large-scale project. When EVM is conducted by the procurement support service contractor (process management), the procurement specifications for the design/development need to include the information to be reported for progress management. Notes on security Information security management ・ Accident and fault in security system shall be prevented in advance in each operation stage. Any damage shall be minimized when it occurs, after promptly reporting to procurer. 317 11. Acceptance Item Description Outline of service Make necessary product delivery and carry out repair if deemed operations necessary Suggested input - (Prepared by procurer) Product ・ Report of project completion (Prepared by ・ Each document contractor) ・ Set of programs, including source code, implementation module, etc. Matters to be stated in [1. Basic requirements to be listed] specifications ・ Report of project completion ・ Delivery based on the requirements listed as “deliverable product” in the specifications ・ Making corrections if the deliverables are deemed to need correction Example/explanation Examples of descriptions in specifications of descriptions in ・ Deliver deliverable product based on the requirements described specifications in the specifications ・ When the Ministry decides that all or part of the deliverables need corrections, the contractor shall take back the deliverables immediately, conduct the necessary changes, and provide the deliverables to which the corrections have been made by the designated date and time. Notes on characteristics of - projects/information systems - Notes on security 318 6.3.3. Timing of delivery of deliverable product The following table shows the deliverable product and delivery timing information. It is necessary to list the official name and delivery timing of each product in accordance with the actual situation. The delivery timing shall be set in expectation of an inspection and correction period. Service operations 1.Preparation for development environment 2.Creation of development plan Deliverable product 3.Basic design Project plan Design/development plan Basic design 4.Detailed design Detailed design 5.Unit test, integration test, system test, connectivity test with other system The following data and documents concerning unit test, integration test, and system test: Test data Test plan Test essentials (test specifications) Test result/quality assessment report 6.Acceptance test support Draft of acceptance test procedures Report of acceptance test 7.Migration Migration plan Migration procedures Migration rehearsal specifications Migration rehearsal result/quality assessment report Migration program Migration data Migration result report 8.User education 9. Transfer to operation and maintenance contractors 10.Project management 11.Acceptance Delivery timing - Education plan Training text Operation manual Operational design Operation manual Table of maintenance framework (draft) Transfer plan Transfer report Progress management material Table of issue management Project completion report Each document Set of programs, such as source code, implementation module 319 Within two weeks after receipt of order (ARO) At the completion of basic design At the completion of detailed design Two weeks prior to each test Two weeks prior to each test Two weeks prior to each test At the completion of each test Two weeks prior to the test At the completion of the test Prior to migration Prior to migration Prior to migration At the completion of the project At the completion of the project At the completion of the project At the completion of the project At the completion of the project At the completion of the project On as needed basis On as needed basis At the completion of the project 6.3.4.Suggested input The following table shows the input and timing to be presented to procurers (or proposers) in advance. It is necessary to list the official name and delivery timing of each input in accordance with the actual situation. Service operations 1.Preparation for development environment 2.Creation of development plan 3.Basic design 4.Detailed design 5.Unit test, integration test, system test, connectivity test with other system 6.Ascceptance test support 7.Migration 8.User education 9.Transfer to operation/maintenance contractors 10.Project management 11.Acceptance Input Outline of new system infrastructure (tentative) Operation environment Operating conditions Requirements definition document Requirements definition document List of major operations Relations between procurer and concerned contractors Outline of operations of concerned contractors Operation schedule Tale of division of roles Document standards in ministries Requirements definition document Basic design document for existing system (excluding new development) Security guidelines stipulated by each ministry Standards for Information Security Measures for the Central Government Computer Systems Detailed design for existing system, program source (excluding new development) Timing to present input To be included in procurement specifications and appendices at the time of tender publishing To be included in procurement specifications and appendices at the time of tender publishing To be included in procurement specifications and appendices at the time of tender publishing At the time of commencement of detailed design - - - - Input target data Diagram of migration installation operations Target, venue and period of education (existing) Operation manual (excluding new development) (Excluding new development) Operational design (existing system) Operation manual (existing system) To be included in procurement specifications and appendices at the time of tender publishing To be included in procurement specifications and appendices at the time of tender publishing To be included in procurement specifications and appendices at the time of tender publishing - - - - 320 6.3.5. Division of roles In separated/breakout procurement, the division of roles among procured services, related procurement and the relevant procurement should be clarified in accordance with the scope of separated orders and the ministerial policies and presented at the time of tender publishing. When considering procurement, services to be realized in the entire procurement should be identified. A clear division of roles and services should be specified and a table of the division of roles should be compiled so that the concerned parties can agree that there are no omissions/errors in services/roles in the breakout procurement Except for new development, it is necessary to refer to the involvement of concerned contractors, such as the existing contractors of operation and maintenance. The table of division of roles shown below is cited from the Application Manual of the Basic Guidelines for Government Procurement Related to Information Systems and describes the main operations and the operational roles of each concerned contractor in a typical separated procurement project. Example of the table of division of roles Procurement section Supporter of process management Common infrastructure contractor Creation of project scope ◎ ◆ □ Establishment of project framework ◎ ◆ □ Creation of method of operating conferences ◎ ◆ □ Setting up schedule and major milestone ◎ ◆ □ Setting up common WBS ◎ ◆ □ Creation of standard management essentials ◎ ◆ □ ◎ ◆ □ Document management ◎□ ◆□ ○□ □ □ □ □ Guidelines for information security measures ◎□ ◆□ ○□ □ □ □ □ ◎ ◆ ○□ △ ◎ ◆ △ □ ◎ ◆ ○□ △ △ △ △ ◎ ◆ ○□ △ ◎ ◆ △ □ ◎ ◆ ○□ △ △ △ △ ◎□ ◆ ○□ △ ◎□ ◆ △ □ ◎ ◆□ ○□ △ △ △ △ ◎□ ◆□ ○□ □ □ □ □ ◎ ◆ ○□ □ □ □ □ Main operations Individual function contractor Hardware delivery contractor, etc. Operation contractor Software maintenance contractor Project management/promotion Example ◎:Approval or confirmation ◆:Support for verification ○:Request for cooperation and coordination □:Implementation △:Support Blank:Participation on as needed basis Formulation of project plan (revision) Creation of project standards Project promotion (implementation of project management) Progress management Progress management for common infrastructure system Progress management for individual function system Progress management in integrated operations Quality management Quality management for common infrastructure system Quality management for individual function system Quality management in integrated operations Issue/problem management Issue/problem management for common infrastructure system Issue/problem management for individual function system Issue/problem management in integrated operations Change management Configuration management Creation of procurement plan and implementation of procurement 321 Main operations Revision of procurement plan Procurement section Supporter of process management Common infrastructure contractor ◎□ □ △ Individual function contractor Hardware delivery contractor, etc. Operation contractor Software maintenance contractor □ □ Creating of procurement specifications and implementation of procurement Procurement of production control support service ◎□ Procurement of common infrastructure service ◎□ ◆□ Procurement of individual function service ◎□ ◆□ □△ Procurement of hardware, etc. ◎□ ◆□ △ △ Procurement of operation service ◎□ ◆□ △ △ Procurement of software maintenance service ◎□ ◆□ △ △ ◎ ◆ □ ◎ ◆ ◎ ◆ △ □ ◎ ◆ ○□ □ □ Integration test ◎ ◆ ○□ □ △ System test ◎ ◆ ○□ □ △ □ ◎□ ◆□ △ △ △ △ △ ・Operation manual ◎ ◆ ○□ □ △ △ △ ・User manual ◎ ◆ ○□ □ △ △ Training ◎ ◆ ○□ □ △ △ Construction and operation of test environment ◎ ◆ ○□ □ □ △ △ Construction of live operation environment ◎ ◆ ○□ □ □ △ △ Operations concerning migration ◎ ◆ ○□ □ △ △ △ Creation of Service Level Agreement (SLA) ◎ ◆ ○□ △ △ □ △ Transfer to operation contractor ◎ ◆ ○□ □ △ □ ◎ ◆ ○□ □ Design/development operations Organizing basic items Design/development operation for common infrastructure system Design/development operations for individual function system Implementation of integrated operations □ △ Promotion of works implemented in cooperation of all participants Acceptance test Creation of various manuals Transfer to software maintenance contractor ・・・・・・ 322 □ 6.4. Operation 6.4.1. Definition of procurement area The term “Operation” in this Section refers to service procurement to carry out operation services for information systems. The Helpdesk may be considered as part of the procurement of operation services (in some cases, the helpdesk is handled independently), but this Section (6.4 Operation) does not include specifics regarding helpdesk services. If concomitant procurement of helpdesk operations is necessary at the time of the procurement of operation services, it is desirable to create specifications referring to the Section “6.5 Helpdesk,” in addition to this Section. Planning phase Requirements definition 要件定義 phase Operation/maintenance 運用・保守フェーズ phase Development phase 開発フェーズ 6.2 6.2.3 Support for ( 等) procurement (Project management, etc.) 6.3 6.4 運用 6.4 Operation 6.5 Helpdesk 6.1 Support 6.1全体計画 for master 策定支援 plan formulation 6.2.2 Support for procurement 6.2 1 調達支援 (requirements ( 等) definition, etc.) 6.3 System integration (design/development) 6.3 ハードウェア更改 6.3 機能追加 6.6 Maintenance 6.7 Tasks incidental to procurement of devices Hardware maintenance Software maintenance Application maintenance System infrastructure maintenance 6.8 Tasks incidental to procurement of iDC equipment ・ 設備) 6.9 Network procurement 6.12 Security Figure 6.4-1 Items corresponding to the areas of procurement of services 323 6.4.2. Services to be listed in specifications 6.4.2.1 Typical service operations The following table shows services to be included in specifications. The corresponding SLCP-2007 activities are also given. For actual procurement, correspondence to SLCP activities should be examined so as not to omit necessary information. Items corresponding to the Basic Guidelines on Procurement (BGP) are also listed. To write specifications, a draft for procurement specifications should be prepared by selecting the appropriate items while - coordinating with the corresponding Program Management Office (PMO). Chapter and section of specifications Service operations Outline of service operations Activities of SLCP-2007 corresponding to BGP (and its title) 1.Formulation of Formulation of implementation 1.7.1.1 10.Requirements operation plan plan of operation and creation of Creation of operation process definition of operation operation plan. plan Receiving approval from competent officers. 2.Transfer for Receiving explanations and 1.7.1.2 9.Requirements definition operation documents from system Transfer of assets for operation of migration developers, operators of existing (1) Requirements systems (in the case of existing concerning migration systems), installer, etc. 3.Construction of Procurement and installation of 3.3.3 Construction of 10.Requirements operation utensils to be prepared by the environment definition of operation environment contractor required for system operation 4.Education for Training for system operators. In 1.7.2.4 Training for system 9. Requirements operators the case of transfer, receiving operation definition of migration training/education from the (2) Requirements existing operator. Implementation concerning education of contingency/security training. 5.System Implementation of operation 1.7.4.1 System operation 10.Requirements operation services necessary for system 1.7.4.2 definition of operation operation. Monitoring operation and ・System operation monitoring collection of operation data, ・Server device monitoring identifying problems, recording ・Network monitoring and finding solutions, ・Job monitoring improvement of operation 324 ・Log monitoring environment ・Resource distribution 1.7.4.3 Identifying and ・Backup and restore improving problems ・Media management, 1.7.4.4 Improvement of expendables management operation environment ・Incident management ・Problem management ・Change management ・Release management ・Configuration management ・Capacity management ・IT service continuity management ・Availability management ・Response to inquiries 6.Service level Report, improvement at a service 1.7.7 Assessment of system 10. Requirements operation level operation definition of operation 7.Holding Business report at regular 1.2.6 Review and assessment 10. Requirements operation conferences. Consideration for conferences issues and resolutions when definition of operation necessary (monthly, weekly, annual, immediate reporting, to ministries) 325 6.4.2.2. Explanation on services and examples of descriptions in specifications 1. Operation plan Item Outline of service operations Suggested input (Prepared by the procurer) Product (Prepared by the contractor) Matters to be described in specifications Example/explanation on a description in specifications Description To receive approval from the officer of a competent authority after formulating operation implementation plans and creating operation plans. Overall schedule Operation overview Operation design document Organizational chart (business entities related to the relevant system and the procurer) Role-sharing table (business entities related to the relevant system and the procurer) Outline of system subject to operation Configuration information on system subject to operation Requirements of details for operation tasks and volume of work, etc. Operation plan document Organizational chart, etc. (Some ministries require separate submission of installation plans and organizational chart, etc. It is then desirable to comply with procurement policies/guidelines issued by each ministry/agency) To formulate an operation implementation plan, which includes the following items, after coordination with design/development entities and the current operator. [1. Basic requirements to be listed] ・Tasks to be implemented ・Role-sharing table, chain of instruction and command system in implementation framework ・Designation of work hours and work place, etc. and constraints ・Requirements for personnel in charge (skill/ experience/qualification) ・Notification of personnel in charge, compliance with rules when changed, etc. [2. Requirements to be added depending on type/characteristics of project] ・Plan of relevant tasks when contingency tasks are generated, such as construction of operation environments, etc. Examples of descriptions in specifications ○Implementation framework, etc. (1) The contractor shall create an operation plan document (including schedule, implementation framework, etc.) within seven days after a successful bid, and submit it to the supervising section and receive approval. (2) Prior to implementation of the operation, the contractor prepares 326 Notes on characteristics of project/information system Notes on security implementation framework assigning at least two operation support personnel who are engaged in relevant tasks and at least two assistants who assist the operation support personnel, and provide relevant officials with an organizational chart, which includes affiliation/title/name/contact number of the operation support personnel and their assistants. (3) Operation support personnel and assistants shall be stationed at ___ Section and carry out the relevant tasks. (4) When operation support personnel and assistants are to be changed due to circumstances of the contractor, the contractor shall consult with personnel in charge by at least two weeks prior to the change. (5) When changing operation support personnel or assistants, the contractor shall create a transfer document and carry out sufficient transfer and training so as to avoid any disruption to business. (1) There are cases where a design/development contractor formulates operation plans. In such cases, it is necessary to finalize the plan after coordinating with the design/development contractor. (2) If coordination with the existing operator and cooperation/ coordination with the existing operation plan, such as continuity and additional procurement, are needed, a statement to that effect shall be included. (3) When the work place is more than one or re-commissioning is necessary, a statement to that effect shall be included and roles to be shared and a responsibility matrix shall be clarified. (1) When personal information is included in organizational charts, etc., such documents shall be treated in conformity to the degree of significance pursuant to regulations. 327 2. Transfer for operation Item Outline of service operations Suggested input (Prepared by the procurer) Product (Prepared by the contractor) Matters to be described in specifications Example/explanation on a description in specifications Description Personnel in charge of the operation of the contractor shall take part in training/education provided by the existing operator or the contractor in charge of system integration (design/development). The contractor shall offer security training to personnel in charge of the operation after commencement of operation, when necessary. When terminating operations due to a change in entity contractor, transfer of business and necessary training shall be conducted for personnel who will take over the operations. A transfer plan document from predecessors (system constructor in the case of new system integration; hereinafter the same shall apply) Transfer materials from predecessors ○ When receiving a transfer of operation Report on implementation of operation transfer ○When conducting transfer Transfer plan (draft) and transfer materials (to successor) Below are the requirements for the contractor when receiving a transfer of business and conducting transfers. [1. Basic requirements to be listed] ・Requirements for transfer from predecessors ・Formulation of transfer plan to successor and creation of transfer materials ・Response to other concerned entities, such as coordination, explanation and training, etc. Examples of descriptions in specifications ○When receiving transfer of operation (Coordination with concerned contractors and creation of a transfer plan) (1) The contractor of the relevant procurement shall consult with concerned contractors in order to collect the necessary information for the execution of the operation tasks of the operation system and shall create a “transfer plan” in consideration for “operation procedures” issued by the Ministry of ___. (Response to training, etc.) (1) The contractor of the relevant procurement shall receive training for personnel in charge of system operations, read thoroughly the user manual for system operators and develop operation framework before the commencement of operation tests. ○When conducting transfer (1) Operators after Fiscal Year ___ will be separately procured. Thus, if the successor after Fiscal Year ___ (hereinafter referred to as “next winning bidder”) is different from the current winning bidder, the current one shall steadily carry out the transfer to the next winning bidder for smooth operation tasks, under the burden and 328 Notes on characteristics of project/information system Notes on security responsibility of the current winning bidder within contract period of service. The following points shall be observed during transfer. (a) Reporting to the authority concerned in advance on personnel in charge of transfer and details of transfer, etc. and to receive approval before transfer. (b) Creating “Statement of Transfer” which includes an outline of tasks implemented during the contract period, and carry out the transfer to the next winning bidder using the said “Statement of Transfer” after receiving approval from the authority concerned. Details and progress of project tasks, which will not be completed by March 31, ____, shall be appended separately in the “Statement of Transfer.” (c) Based on the transfer plan, approval of the authority concerned shall be gained with respect to the result of the transfer. If approval is not gained, operations shall be carried out by extending the contract period so as not to interfere with operations under the responsibility and burden of the winning bidder. (1) If there are several stakeholders requiring coordination during the preparation for operations, the contractor needs to clarify contractors which receive coordination and explanations. (2) When the contract period of the current operator is expired at the time of selection of the next winning bidder, a hands-on transfer from the current to the next winning bidder cannot be conducted. Thus, operation transfer shall be substituted by handing over of operation-related documents and materials from the procurer. - 329 3. Construction of operation environment Item Outline of service operations Description Procurement/installation of utensils necessary for system operation to be prepared by the contractor Suggested input (Prepared by the procurer) Product (Prepared by the contractor) Matters to be described in specifications List of utensils to be prepared (when utensils to be prepared by the contractor in charge of the operation have been defined) Example/explanation on a description in specifications Task report (environment construction) When utensils are to be prepared by the operator, a statement to that effect shall be included. If necessary utensils, etc. have been determined, their models shall be listed. [1. Basic requirements to be listed] ・Selection of appropriate utensils/software in accordance with requirements specifications ・Necessary on-site studies ・Results of on-site studies and output, such as diagrams, etc. are to be designed and created ・Implementation of on-site studies and timing of submission of outputs ・Constraints on implementation of on-site studies ・Installation space and electricity capacity for on-site installation ・Availability of internet lines and monitoring lines connection for on-site connection, etc. Examples of descriptions in specifications ○Selection of appropriate utensils/software in accordance with requirements specifications (1) Utensils deemed to be necessary shall be prepared by the contractor on its burden. Examples for such utensils include desks, chairs, shelves, copiers, fax machines, hardware and software necessary for information management, telephone lines, and internet lines, etc. When installing internet lines, it is prohibited to connect to the intra-ministerial LAN. (a) The contractor shall file applications for delivery and installation of utensils (b) The contractor shall conduct preliminary studies for the delivery/installation of utensils (c) The contractor shall prepare components necessary for delivery/installation (d) The contractor shall remove and dispose the packaging of utensils, tools used for delivery and other unnecessary materials as soon as installation is completed. Considering the impact on the environment, efforts shall be made to minimize waste materials as 330 Notes on characteristics of project/information system Notes on security much as possible. (e) The contractor shall basically carry out delivery/installation within business hours on weekdays. Details shall be separately instructed by the Ministry of ___. (1) It is necessary to clarify the roles to be shared by preparation/installation contractors of utensils to be procured, etc. - 331 4. Education of operational workers Item Outline of service operations Suggested input (Prepared by the procurer) Product (Prepared by the contractor) Matters to be described in specifications Example/explanation on a description in specifications Notes on characteristics of project/information system Notes on security Description Operation staff shall receive education from the current operator or system constructor (design/development). Operational procedures manual Operational procedures manual (revised version) Work report (staff education) The following are the details of education to be offered to the system operators: [1. Basic requirements to be listed] ・Compulsory training ・Details of education/training to be implemented [2. Requirements to be added depending on type/characteristics of project] ・Periodical training for operation staff after the commencement of operation, such as security training, etc. Main tasks to be listed in specifications ○Compulsory training (1) Training for personnel in charge of system operation The relevant contractor shall implement training for personnel in charge of system operation on setting methods and operation methods that will be necessary for system operation, before the commencement of operation of each system. The relevant contractor shall participate in such training and acquire the necessary skills (the rest omitted.) (1) If the contract period of the predecessor has expired when successor is selected, a hands-on transfer from the predecessor to the successor will not be carried out; thus, it is necessary to substitute staff education with the transfer of operation-related documents and materials from the procurer. - 332 5. System operation Item Description Outline of service To carry out necessary operations, using an operation outline, operations operation procedures manual and operation tools that have been handed down from the design/development entity or from the existing operator. Suggested input Operation design document (Prepared by the Operation outline procurer) Operation procedures manual Documents for application/management concerning tasks (change/release) Security policies issued by ministries/agencies, etc. Product Operation report (Prepared by the Work report (operational tasks) contractor) Operation procedures manual (additions and revisions made), etc. Matters to be To carry out operations necessary for system operation. To extract described in tasks necessary for the contractor from the operation requirements specifications for the relevant information system and to extract the roles of the procurer and to list them in the specifications. To indicate the timing of implementation of each task. When implementing each task, security policies of each ministry/agency are expected to be observed. ・System operation monitoring ・Server device monitoring ・Network monitoring ・Job monitoring ・Lob monitoring ・Distribution of materials ・Backup and restore ・Media management, expendables management ・Incident management ・Problem management ・Change management ・Release management ・Configuration management ・Capacity management ・IT services continuity management ・Availability management ・Response to inquiries (*Details of services of helpdesk are described in 6.5 Helpdesk), etc. Example/explanation Examples of descriptions in specifications on a description in specifications ○ Actual operations 333 The relevant contractor shall carry out the following items in accordance with the regulations stipulated in the operation procedures manual: (A) Monitoring of operation of each system (1) The relevant contractor shall monitor the online status and batch processing. (2) At the time of regular maintenance/scheduled shutdown, each system shall be shut down and started up again. (B) Server device monitoring (1) The relevant contractor shall monitor operations of server devices installed in the iCD and the Ministry concerned, etc. (2) At the time of regular maintenance/scheduled shutdowns, each system shall be shut down and started up again. (C) Network monitoring (1) The relevant contractor shall monitor the operational status of LAN/WAN networks in the Ministry of ___, as well as networks constructed in the iCD and each center (the Ministry concerned and local branches). (D) Job monitoring (1) The relevant contractor shall monitor the job execution of each system. (2) The relevant contractor shall confirm that batch processing has been properly carried out. (3) The relevant contractor shall carry out a batch job that requires manual startup in accordance with the startup instructions. (4) In cases of abnormal processing, the relevant contractor shall re-run, analyze the failure/recover from failure in accordance with the operation procedures manual, or contact the personnel in charge. (E) Log management (1) The relevant contractor shall manage the log of each system. (2)The relevant contractor shall collect log data on unauthorized use, detection of unauthorized intrusions, information leakage, availability/reliability/confidentiality, hardware breakdown, software breakdown, etc. and shall offer cooperation when an officer of the Ministry of ___ performs a log analysis. (F) Distribution of resources (1) Program files, etc. are automatically distributed to servers and clients’ network computers. If it becomes necessary to distribute 334 resources manually due to extraordinary distribution or failure of automatic distribution, etc., the relevant contractor shall do so in accordance with instructions. (G) Backup and restore (1) An automatic backup system is in place. If a restore (reinstating data) becomes necessary for temporal backup operations or recovery, the relevant contractor shall perform the restore in accordance with instructions. (H) Media management and expendables management (1)The relevant contractor shall store media and keep records for information on the media/date of storage, in accordance with the prescribed method of storage. (I) Incident management (1) To uniformly manage incidents detected by the service desk or system monitoring (system failure, device breakdown, generation of error/warning messages, etc.). (2) To implement responses and solutions, if there are any applicable events through searching for incidents in the past. (3)To upgrade the incident to problem management, considering urgency, priority and the scope of impact, if there are no applicable events through searching for incidents in the past. (J) Problem management ・Separation of failure (1) To uniformly manage incidents those have been upgraded from incident management as problems. (2) To separate problems in accordance with the boundary of responsibility among concerned business entities. (3) To convene an extraordinary conference by instructing concerned parties to carry out investigations, on an as needed basis. ・Investigation of/recovery from failure (1) Following the separation of failure, to instruct the concerned contractor in charge of the relevant failure to identify the root cause and to carry out recovery tasks. (2) To supervise the work until recovery and to confirm recovery. (3) To organize a series of responses to failure. (4) To take temporary measures if the problem cannot be fundamentally solved in the short term. To formulate and request the concerned business entity to formulate a permanent solution. (K) Change Management 335 (1) To receive and uniformly manage requests for change presented by a supervising officer from the Ministry of ___ or problem management. (2)To clarify impacts and risks that may be generated by the change and to formulate a change plan in accordance with the request for change. To confirm the change plan with the supervising officer from the Ministry of ___. (3)To judge propriety of the release after a verification test if a program modification is required, following the confirmation of the change plan. (L) Release management (1) To receive and uniformly manage requests for the release of new hardware, new software and new versions of software those are listed in the activities of change management. (2)To formulate release plans and to implement release. Upon consultation with supervision officer from the Ministry of ___, to implement renewal of a pattern file for antivirus measures and patch application for operating system and middleware, etc. (3)When related business entities are in operation, such as a change in hardware devices, etc., the relevant contractor shall observe the work and confirm the result of the work. (M) Configuration management (1)To record and sort information on the network/hardware/ software/facility which comprises a system, and keep it in the most recent and complete form at all times. (N) Service delivery To respond to plans and improvement on mid- and long-term system operations management: specifically, to carry out the following tasks: (1) Capacity management To monitor, measure, collect data and record performance of resources and report these matters in order to prevent problems such as degradation of performance or lack of resources. (2) To make efforts to maintain appropriate processing capacity, number of servers and network bandwidth, keeping an eye on the trends of usage. (O) IT service continuity management (1) To implement backups and store backup data in preparation for large scale disasters or data loss. To provide support for discussions on recovery plans and alternative means to be prepared by supervising ministries and related business 336 entities. (P) Availability management (1)To support strengthening quality and security for the stable supply of services. Notes on (1) Please also refer to 6.5 Helpdesk if it is necessary to set up a characteristics of helpdesk serving as an information resource in response to project/information inquiries from users. system Notes on security - 337 6. Service level management Item Outline of service operations Description To report to ministries on the service level of operations in accordance with the concluded Service Level Agreement (SLA). Suggested input (Prepared by the procurer) Product (Prepared by the contractor) Matters to be described in specifications Service level items/definition document Service Level Agreement (SLA) Example/explanation on a description in specifications Service level report To manage and report concluded service level items and to improve non-attained items. [1. Basic requirements to be listed] ・Status report and assessment on service level items Examples of descriptions in specifications ○ Service level items (1) Service level management To report on attainments of service level, based on the concluded “Service Level Evaluation Items and Requirement Standards” and “Evaluation Method for Service Level.” To make specific proposals as a “Service Improvement Plan,” when service level is unattained. ○ Examples of descriptions concerning the conclusion of a Service Level Agreement (SLA) When implementing the relevant tasks, a Service Level Agreement (SLA) shall be concluded between the concerned authority and the winning bidder. Service level evaluation items and required standards will be decided upon during consultation between the concerned authority and the winning bidder after the concluding of an SLA, based on the following requirements: It is necessary to make specific proposals as a basis for the consultation with respect to the “Service Level Evaluation Items and Required Standards,” “Service Level Evaluation Method” and “Service Improvement Plan for Unattained Items.” 1. Normal operation (1) No occurrence of an event that cannot ensure completeness of business data concerning ___ business (such as data falsification). Events attributable to the winning bidder are counted in the number of occurrences, excluding events attributable to other business contractors or events where business has not been affected by implementing recovery measures. (2)Availability of each system is at least 99.9%. However, this is not applied to the period of system shutdown caused by reasons not attributable to the winning bidder. 338 Notes on characteristics of project/information system (3) Annual service availability of the support service office (proportion of cases in which appropriate responses have been taken to the total number of inquiries: for example, recording the frequency of inappropriate responses due to inadequate design of management framework or response manual, etc.) is at least 99.9%. 2. Quality of services (1) When implementing the relevant tasks, to make efforts to gain understanding of ___business and the function of ___system, while seeking coordination with the contractors in charge of system development/maintenance, at the expense of the winning bidder. (2) Winning bidder, at their own expense, shall make efforts to understand the product, while seeking coordination with the business entities which deliver hardware and software products to be installed. (3) The winning bidder shall make efforts to understand the entire network configuration, including the next system and peripheral systems, and be aware that the relevant system should work in association with peripheral systems. (4) The winning bidder shall take responsive measures, at their expense and responsibility, in cases where the winning bidder has failed to provide the transfer operations and normal operations at the time of implementation of the relevant business, or exerted influence or troubles to the system of ___ business data. (5) The relevant authority will lend documents necessary for the execution of the relevant operations of a winning bidder, on an as needed basis. Documents lent out shall be returned to the authority when requested or after expiration of the execution period. <<omission>> (9)The winning bidder shall address problems while reporting the situation to and seeking advice from the relevant authority whenever necessary for operations. (10) In the event of violating the provisions stated above, submissions of a report shall be requested and an SLA point may be added. ○ Matters to be noted at the time of concluding a Service Level Agreement (SLA) (1) Since operation procurement is in the purchase of services, it is necessary to conclude Service Level Agreement (SLA) as an evaluation index. Non-availability of systems may often be caused by procured hardware/software, and not always attributable to the operation. Shortening of non-available time due to activation of backup operations at the time of system failure may be different depending on architecture. It is therefore necessary to set and evaluate service level values as an index for evaluation of operations with due considerations to these facts. (2)It is also desirable to evaluate the quality of operation report and monitoring. (3) There is an approach of imposing a penalty in accordance with 339 the attainment of service level items. Based on the concept of a contingency fee as part of the “amount of payment (winning bid) = basic rate + contingency fee,” the amount of payment shall be determined in accordance with the attainment of service level items agreed between the procurer and winning bidder. In general, in cases where winning bidder infringes conditions agreed with the procurer, winning bidder’s liability for the damage may be seen as an obligation under socially accepted conventions; however, the most important wish of the procurer is the provision of high quality services from the winning bidder, and the concept of reward should be determined for that purpose. It is not meant to impose unfairly severe conditions on winning bidder. Example of condition (1) The ratio of the basic rate of a contingency fee shall be 9:1. Example of condition (2) The proportion of contingency fee shall be as follows: (2-1) 10% (full amount): Prescribed conditions attained in all service level requirements (2-2) 5%: Unattained prescribed conditions account for less than 5% of total conditions. (2-3) 2%: Unattained prescribe conditions account for more than 5% and less than 10%. (2-4) 0%: Unattained prescribed conditions account for more than 10% of total conditions. Notes on security - 340 7. Holding an operation conference Item Outline of service operations Suggested input (Prepared by the procurer) Product (Prepared by the contractor) Matters to be described in specifications Example/explanation on a description in specifications Description To hold operation conferences to report business performance to the competent office of ministries. To discuss issues and solutions when necessary (monthly, weekly, annual, extraordinary briefing session, etc.). Date of operation for conference (draft) Daily report Weekly report Monthly report Report on an extraordinary conference Operation report Minutes of an operation conference The following are the list of necessary reviews and their timing and method, such as periodical conferences, dates of conferences, reports to be submitted and details of the reports, etc. [1. Basic requirements to be listed] ・Name of the conference ・Participants ・Name of the report to be submitted ・Details of the report Examples of descriptions in specifications ○Holding of operation conference The relevant contractor shall hold the following conferences and create reports for each conference. When necessary, the relevant contractor may apply for the participation of related business entities upon confirming with competent an officer of the Ministry of ___. (1) Daily operation conference ・Participant: Relevant contractor ・Date of conference: Open days of government offices and when working on holidays for inspection, etc. ・Name of the report: Daily report ・Details of the report -Occurrence of incidents and failures on the preceding day and its response (number of occurrences/devices/completion) -Response of the helpdesk on the preceding day (number of inquiries) -Operation status of systems on the preceding day (start and closing time of service, details/time/personnel in charge/confirmer of operations) - Schedule of operations work on the relevant day, etc. 341 (2) Weekly operation conference ・Participants: Competent officers of the Ministry of ___ and relevant contractors ・Date of conference: Weekly ・Name of the report: Weekly report ・Description: Details of the report - Weekly occurrence of incidents and failures and its responses (Number of occurrences/devices/completion, progress) - Weekly responses of the helpdesk (total number of inquiries, tendency, distribution) - Outline of system operations for the week - Schedule and plan of operations on the following week, etc. (3) Monthly conference ・Participant: Competent officers of the Ministry of ___ and relevant contractors ・Date of conference: Monthly ・Name of the report: Monthly report ・Details of the report: - Monthly occurrence of incidents and failures and its responses (Number of occurrences/devices/completion, progress) - Monthly responses of the helpdesk (total number of inquiries, tendency, distribution) -Outline of system operations of the month (status of problems, changes) - Attainment of service level for the month - Results of performance monitoring for the month - Usage of resources for the month - Security status for the month (number of detected unauthorized accesses, number of detected viruses, number of detected falsifications, number of detected unauthorized e-mails, changes in the number of users, number of account locks, new information on vulnerability) - Schedule and plan of operations on the relevant month, etc. (4) Briefing session on inventory status of configuration management ・Participants: Competent officers of the Ministry of ___ and relevant contractors ・Date of conference: semiannually ・Name of the report: Configuration management inventory table ・Details of the report: Result of system configuration results, such as server devices and software, etc. (5) Extraordinary conference ・Participant: Competent officers of the Ministry of ___ and relevant contractors 342 ・Date of conference: On an as needed basis (in cases where an emergency event occurs) ・Name of the report: Extraordinary conference report ・Details of the report: Report, confirmation, analysis and consideration for the event or problem. Notes on characteristics of project/information system Notes on security - - 343 6.4.3. Deliverable product and timing of submission The table below lists deliverable products and timing of delivery. The official name of each product and its delivery deadline need to be entered in accordance with the actual situation. Service 1.Creation of operation plan Deliverable product Operation plan document Organizational chart Delivery deadline Within the designated date after the conclusion of an agreement. If changed, on an as needed basis 2.Business transfer for operation ○Transferee Within one week after the completion of a transfer Operation transfer implementation report Prior to transfer ○Transferor Transfer plan (Draft), Transfer materials (to transferee) 3.Construction of operation environment Task report (Environmental construction) Prior to installation of devices At the time of environmental construction At the completion of environmental construction work 4.Education of operation staff Operation procedures manual (Revised version) Task report (Staff education) 5.system operation After training After training Operation report Daily, weekly, monthly, annually Task report (Operational tasks) On an as needed basis Operation procedures manual 6.Service level management 7.Holding of operation conference (Revised) Submission after revision Service level report Designated date Daily report Daily Weekly report Weekly Monthly report Monthly Report on an extraordinary On an as needed basis conference Operation report Designated date, at the time of final delivery Within designated days following the conference Conference minutes 344 6.4.4. Suggested input The following table shows input and timing to be presented to the procurer (proposer) in advance. The official name of each product and its delivery deadline need to be entered in accordance with the actual situation. Service 1.Creation of operation plan 2.Transfer for operation 3.Construction of operation environment 4.Education of operation staff 5.System operation 6.Service level management 7.Holding of operation conference Input Overall schedule Timing for presenting input At the time of tender publishing/during the tender period During the tender period Operation outline Operation design document Organizational chart (related business entities and contractors of the relevant systems, the procurers) Role-sharing table (related business entities and contractors of the relevant systems, the procurers) Outline of system subject to operation Configuration information of system subject to operation Details of relevant operations /requirements, such as volume of work Transfer plan from the predecessor (system constructor in the case of new system integration; hereinafter the same shall apply) Transfer materials from the predecessor Utensils subject to preparation, etc. At the time of tender publishing Operation procedures manual Disclosed to expected bidders during the tender period. Lent to contractors after conclusion of an agreement. After conclusion of an agreement Disclosed to expected bidders during the tender period. Lent to contractors after conclusion of an agreement. Operation design document Operation outline Operation procedures manual Documents on the application/management of tasks (change/release) Security policies prescribed by ministries Service level items/Definition document Service Level Agreement Schedule of operation conference (draft) After conclusion of an agreement At the time of tender publishing At the time of tender publishing At the time of conclusion of an agreement At the time of tender publishing 345 Item number 1 2 3 4 5 6 7 8 9 10 11 12 13 Service level item Details of regulation Unit Period of operation service provision Method of reporting operation service provision status/ Time interval Batch processing time Frequency of monitoring physical resources Failure notification process/duration until notification Acquisition of backup Period of implementing operation services Period Method of reporting operation status and operation plan/time interval Time Time spent on batch processing Frequency of monitoring physical resources, such as performance Presence or non-presence of communication process at the time of an occurrence of operation failure and duration until notification Details/methods/frequency the of acquisition of backup Time necessary for backup Storing period of backup media Time Time/day Time spent from system shutdown to data recovery Details/methods/frequency of acquisition of logs that can be provided to users Storing period of media storing logs System recovery/support system for failure Time necessary for developing environments for implementation of operation services/time for removing operation environment Time spent on various education programs for operation staff At the time of commencement of business, regular training, etc. Regular report Time Backup time Storing period of backup data Backup recovery time Acquisition of log Storing period of log Failure recovery Developing operation environment/removal time Staff education time 14 15 Report Table 6.4-2 Examples of service level items 346 Presence/non-presence Time Presence/non-presence Time Time Presence/non-presence Period Presence/non-presence Time Time Item 6.4.5. Division of roles In this Section, examples of roles divided among the relevant contractor, authorities and contractors of other operations are described. In separated/breakout procurement, the division of roles among procured services, related procurement and the relevant procurement should be clarified in accordance with the scope of separated orders and the ministerial policies and presented at the time of a bid announcement. When considering procurement, services to be realized in the entire procurement should be identified. A clear division of roles and services should be specified and a table of the division of roles should be compiled so that concerned parties can agree that there are no omissions/errors in services/roles in the breakout procurement. ○: Main personnel in charge, △: Support, advice Supervisory Tasks 1.Creation of operation plan 2.Transfer for operation Operator section △ ○ ○ Succeeding operator Related business entity *1 *2 △ △ 3.Construction of operation environment 4.Education of operation staff ○ △ ○ △ 5.System operation ○ △ 6.Service level management △ ○ △ 7.Holding of operation conferences △ ○ △ *1 Succeeding operator: Transferee of operation or business entity conducting operation transfer *2 Related business entity: Business entity working in corporation with operators, including maintenance (hardware, software) business entities, iDC business entities, and helpdesk business entities. 347 6.5. Helpdesk 6.5.1. Definition of procurement area Procurement of helpdesks refers to the procurement of services to construct and operate helpdesk environments enabling appropriate responses to users’ inquiries in the operation of information systems (primary response, secondary escalation, data registration, FAQ management, etc.). In procurement of helpdesk services, helpdesk contractors that manage overall operation services should be procured separately. There are two cases: one in which the helpdesk is procured independently and the other in which the operation contractor provides helpdesk services comprehensively as part of their operation services. This Chapter applies to helpdesk services of the latter case, and it is necessary to refer to “6.4 Operation” for other operation services. Independent procurement of a helpdesk is for a large-scale system in most cases. In most of small-scale system projects, it is procured as part of operations. In the classification of procurement of services, it is one of the procurement areas in operation/maintenance phase as shown in the figure below. Planning phase Requirements definition 要件定義 phase Operation/maintenance 運用・保守フェーズ phase Development phase 開発フェーズ 6.2 6.2.3 Support for ( 等) procurement (Project management, etc.) 6.3 6.4 運用 6.4 Operation 6.5 Helpdesk 6.1 Support 6.1全体計画 for master 策定支援 plan formulation 6.2.2 Support for procurement 6.2 1 調達支援 (requirements ( 等) definition, etc.) 6.3 System integration (design/development) 6.3 ハードウェア更改 6.3 機能追加 6.6 Maintenance 6.7 Tasks incidental to procurement of devices Hardware maintenance Software maintenance Application maintenance System infrastructure maintenance 6.8 Tasks incidental to procurement of iDC equipment ・ 設備) 6.9 Network procurement 6.12 Security Figure 6.5-1 Items corresponding to the areas of procurement of services 348 6.5.2 Services to be listed in specifications 6.5.2.1 Typical service operations The following table shows services to be included in the specifications. The corresponding SLCP-20079 activities are also given. For actual procurement, correspondence to SLCP activities should be examined so as not to omit necessary information. Items corresponding to the Basic Guidelines on Procurement (BGP)10 are also listed. To write specifications, a draft for procurement specifications should be prepared by selecting appropriate items while coordinating with the corresponding Program Management Office (PMO). Service operations 1.Creation of operation plan 2.Business transfer for operation 3.Development of working environment 4.Service level management 5.Helpdesk operation 6.Survey on user Activities of SLCP-2007 Outline of service operations To create an implementation plan, installation plan and business operation plan for helpdesk operations and submit them as plan documents to the supervisory section of ministries for approval. To implement periodical reviews or revision of plans if necessary for the progress of works. To receive explanations and necessary documents from general managers and helpdesk operators from the previous fiscal year. To create transfer plans and materials to be handed to transferees. To implement transfer. To prepare telephone, fax, PBX, CTI, servers and software and wiring that are necessary for helpdesk operations. To conclude SLA and report service levels in preparation for helpdesk operations. Primary reception, primary response, escalation. To record and analyze details of inquiries. To extract and renew matters posted on FAQ. Remote control of user’s terminal server, etc. Survey and report on system 1.7.1.1 Creation of operation process plans Chapter and section of specifications corresponding to BGP (and its title) Chapter X Requirements definition of operation (and outline shall be listed in Chapter II (5) Work description/Deliverable product) 1.7.1.2 Transfer of assets for operation - 1.7.1.9 Setting operation assessment criteria 1.7.6.1 Business operation 1.7.6.2 User support Chapter X Requirements definition of operation (and outline shall be listed in Chapter II (5) Work description/Deliverable product) - 9 Software Life Cycle Processes-Japan Common Fram-2007 (SLCP-JCF 2007), Information-technology Promotion Agency, Japan (in Japanese) 10 The “Basic Guidelines for Government Procurement Related to Information Systems”, March 2007, Ministry of Internal Affairs and Communications (in Japanese) http://www.soumu.go.jp/menu_news/s-news/2007/pdf/070301_5_bs2.pdf 349 Service operations Activities of SLCP-2007 Outline of service operations satisfaction users’ satisfaction 7.Helpdesk operation conference To report on operation of helpdesk operations at regular conferences. To create conference minutes. To discuss issues and solutions when necessary (monthly, weekly, annually, extraordinary briefing session, etc.). To create and submit a helpdesk operations manual and other reports. 1.2.6 Review and assessment 1.7.1.5 Establishment of procedures for system operation 2.1 Documentation process 350 Chapter and section of specifications corresponding to BGP (and its title) 6.5.2.1. Explanation on services and examples of descriptions in specifications 1. Creation of operation plan Item Description Outline of service To create implementation plans, installation plans and business operations operation plans for helpdesk operations and submit them as plan documents to competent sections of ministries for approval. To implement periodical reviews or revision of plans if necessary for the progress of works. Suggested input ・Expected installation and rough estimates of the number of users (Prepared by the ・Statement of Work procurer) ・Overall schedule (draft) ・Organizational chart (draft) ・Operational framework (draft) Product ・Implementation plan (Prepared by the ・Helpdesk environmental construction diagram contractor) ・Installation plan ・Operation plan, outline of operation implementation (Some ministries require separate submission of documents, such as installation plans and organizational charts, etc. Procurement policies/guidelines issued by each ministry should be followed.) Matters to be To state the following requirements in specifications, which will be described in necessary for the judgment of validity of plans by ministries specifications Other materials requiring submission in advance as project plan documents shall be listed as requirements. [1.Basic requirements to be listed] ・Formulation of business implementation plans ・Formulation of installation plans ・Formulation of business operation plans ・Operation management [2. Requirements to be added depending on type/characteristics of project] ・In the case of separate procurement for operations, it is necessary to clarify the consistency with the operation plan of the operator. Example/explanation Examples of descriptions in specifications on a description in specifications ○Formulation of business implementation plans The contractor shall, in advance, create a helpdesk business operation plan as a part of formulation the of business implementation plan (hereinafter referred to as the “business implementation plan document”) and gain approval of the supervisory department of the Ministry of ___. The following are the details of the business implementation plan (1) Overall schedule 351 Item Description (2) Product (3) Procedures for revision of plan and procedures for change management ○Formulation of installation plan The contractor shall, following the formulation of a business implementation plan, create a helpdesk business installation plan, which describes work plans during the installation period, (hereinafter referred to as the “implementation plan document”) and obtain approval from the supervisory department of the Ministry of ___. The following are the details of the installation plan. (1) Installation schedule (2) Environment development plan for helpdesk operations (3) Education plan for helpdesk staff (4) Implementation framework (5) Conferences (6)Staffing plan (during installation period) ○Formulation of business operation plan (1) Formulation of business operation plan The contractor shall, prior to the commencement of the relevant service, create a helpdesk business operation plan, which describes helpdesk operations after the start of the service, (hereinafter referred to as the “business operation plan document”) and obtain approval from the supervisory department of the Ministry of ___. The following are the details of creating a business operation plan. (i) Helpdesk business operation plan (ii) Implementation framework (iii) Conferences (iv) Staffing plan (during the period of service provision) (v) Procedures for revision of plans and procedures for change management (2) Formulation of the outline of business operation implementation The contractor shall, prior to the commencement of the relevant service, create an outline of helpdesk business implementation, which describes helpdesk operations after the start of the service, (hereinafter referred to as the “business operation implementation outline”), based on the “Outline of Operation and Maintenance of Information Operation Center Related to ___ operations) (Day__ Month__ Year__) (hereinafter referred to as the “Operation/Maintenance Management Outline”) and obtain approval from the supervisory department of the Ministry of ___. For the formulation of the business operation implementation outline, the contractor shall seek coordination with the general manager and 352 Item Description personnel in charge of operation services. Flow, communication means and details of escalation shall also be reflected on the business operation implementation outline upon consultation with the manager and personnel in charge of operation services. The following are the business operation implementation outlines to be created. If the prepared business operation implementation outline is not sufficient, a decision shall be made upon consultation with supervisory department of the Ministry of ___ after contract is made. (i) Outline of document management (ii) Outline of service index management (iii) Outline of issue/problem management (iv) Outline of communications management ○Operation management The contractor shall carry out operation management of the relevant business, based on the business implementation plan, installation plan and business operation plan, mentioned above. Notes on When a helpdesk is procured together with an operation, it is characteristics of necessary to add the details of a formulating service operations plan project/information prescribed in 6.4 Operation, in addition to the relevant matters listed system here. Notes on security Compliance with the outline of implementing information security measures 353 2. Business transfer for operations Item Description Outline of service To receive explanations and documents from the general manager operations and former helpdesk operator, etc. To create transfer plans and materials for transferee and implement the transfer. Suggested input ・Transfer plan from predecessors (system constructor, in the case of (Prepared by the new system integration; hereinafter the same shall apply). procurer) ・Training on transfer materials, business details, operational tasks, and security etc. from predecessors. Product ・Transfer plan to successors (Prepared by The ・Transfer materials to successors contractor) ・Report on transfer Matters to be [1. Basic requirements to be listed] described in ・Transfer requirements from predecessors specifications ・Creation of transfer plan and transfer materials to the successors [2. Requirements to be added depending on type/characteristics of project] ・To state requirements for data transfer in cases where data, such as data on FAQ, are to be transferred. Example/explanation Examples of descriptions in specifications on a description in specifications ○Transfer from predecessors The contractor shall receive necessary matters for the tasks of relevant operations, such as know-how in helpdesk operations from the integrated operation monitoring (under transition) company. The contractor shall hand over data related to the relevant systems. The contractor shall create transfer plans and report the completion of transfer. (1) Transfer works from predecessors (i) Predecessors shall create a “transfer plan” in accordance with the instructions of the integrated operational monitoring contractor (under transition). Predecessors shall also create a “report on completion of transfer” when the transfer work has been completed. The overall schedule shall be listed in the “preparation and transfer of the integrated operational monitoring.” (ii) The contractor shall receive the transfer from the integrated operational monitoring (under transition) contractor and prepare the environment, while the integrated operational monitoring (under transition) contractor implements the actual integrated operational monitoring work. The contractor must not cause delays in operational work of the integrated operational monitoring (under transition) contractor. 354 Item Description (iii) The contractor shall initiate the transfer. The transfer shall be carried out in consideration to the following matters. (a) To proactively acquire system configuration and operation details from the design document and documents related to operation, etc. (b) When making inquiries to the integrated operational monitoring (under transition) contractor, such inquiries shall be made upon gaining the full understanding of the design document and documents related to operations, etc. (c)Upon consulting with the integrated operational monitoring (under transition) contractor, the method of making questions and inquiries shall be selected so as not to interfere with the operations of the integrated operational monitoring (under transition) contractor. (iv) Data transfer The contractor shall receive all the following data concerning the relevant system from the integrated operational monitoring (under transition) contractor. The contractor shall make efforts to understand the transferred data. ・Business data ・Operation related data (indent management data, FAQ data of the helpdesk, configuration management data, etc.) ・All the data filed in the library management system (design documents, procedures manuals, definition files, etc.) ・All data in the registry (Backup tape registry, iCD visitor registry, etc.) ・Other data (paper data, data stored in external media, etc.) ○Transfer to successors Training on business details, operational tasks and security, etc. shall be carried out promptly after the conclusion of an agreement with the successor. Transfer work is planned under the assumption of actual operation. (1) The contractor shall carry out the transfer to the successors with respect to the tasks and operation results, before termination of the contract. (2) The contractor shall enable successors to receive system maintenance and expansions without depending on specific product/technology, when implementing the transfer. (3) The contractor shall formulate transfer plans, create transfer materials, and obtain approval from the office of ____. (4) The contractor shall follow the instructions of the office of ___ with respect to transfer period and deadlines, etc. (5) The contractor shall answer questions from the successors when 355 Item Description there is an omission in transfer materials, etc. even after the termination of the contract. Notes on In the case of new development, it is desirable to receive the transfer characteristics of from the design/development business entity. It is also desirable to project/information receive the transfer from the supervisory section if it is difficult to carry system out transfer from predecessors. Notes on security - 356 3. Development of work environments Item Outline of services Description To prepare telephone, fax, PBX, CTI, servers and software and wiring, which are necessary for helpdesk operations. Suggested input ・Constraints on wiring (Prepared by the ・Details of system reform and system improvements that are needed procurer) for the revision of the helpdesk operations manual Product ・Helpdesk educational materials (Prepared by the ・Helpdesk manual contractor) ・Telephone lines for the helpdesk ・Telephone line installation diagram for the helpdesk ・Telephone lines for an Interactive Voice Response (IVR) server ・Telephone line installation diagram for the IVR server Matters to be [1. Basic requirements to be listed] described in ・Construction of the helpdesk environment specifications ・Wiring [2. Requirements to be added depending on type/characteristics of project] ・Organizing helpdesk tasks ・Creation of the helpdesk manual ・Education for helpdesk staff ・Report on the helpdesk installation status ・Revision of the manual due to organizational changes and system improvements. Example/explanation Examples of descriptions in specifications on a description in [1. Basic requirements to be listed] specifications ・Construction of the helpdesk environment (preparing telephone, fax, PBS, CIT, servers and software) (1) Preparation of utensils necessary for operations (i) The contractor shall prepare utensils deemed necessary for operations at its own expense. Utensils include desks, chairs, shelves, media storage cabinets, copiers, fax machines, hardware and software for information management, internet connections, and telephone lines, etc. When installing an internet line, it is prohibited to connect to the intra-ministerial LAN. (ii) When the contractor concludes that the number of helpdesk terminals and operation management terminals is not enough, the contractor shall prepare the similar terminals as those prepared by Bureau of ___, on an as needed basis. (iii) The contractor shall file an application for delivery and installation 357 Item Description of utensils. (iv) The contractor shall conduct a preliminary study for delivery and installation of utensils. (v) The contractor shall prepare the necessary components for delivery and installation. (vi) The contractor shall remove and dispose of the packaging of utensils and tools used for delivery and other unnecessary materials as soon as installation is completed. Considering the impact on environment, efforts shall be made to minimize waste materials as much as possible. (vii) The contractor shall basically carry out delivery/installation within business hours on weekdays. Details shall be separately instructed by the Bureau of ___. (2)Construction of the helpdesk environment The contractor shall construct the helpdesk installation place and environment. When implementing remote monitoring, the contractor shall develop an environment which enables remote monitoring. The contractor shall also prepare lines connecting with the office of ___. ○Requirements concerning wiring (1) The contractor shall perform an on-site study on wiring: specifically, confirmation of pathway of optical fiber and LAN cables, etc. (under the floor, on the floor, vertical pipeline, in-ceiling piping, etc.) is required. (2) The contractor shall gain the approval of the Bureau of XXX for a wiring pathway. (3) The contractor shall carry out wiring operations. (4) The place of operations in the data center should not be wired. The contractor shall secure communication means in other places at its own expense. [2. Requirements to be added depending on type/characteristics of project] ○Organizing helpdesk operations As a preparation for helpdesk operations, the contractor shall implement the following operations. The contractor shall also be responsible for any other necessary operations. (1) Preparation for access to FAQ information In ___ system, FAQ information will be disclosed via the Kasumigaseki WAN to system users. Since the contractor cannot refer to this FAQ information, it shall prepare its own environment for reference for helpdesk operators, etc. by receiving initial FAQ 358 Item Description information from the supervisory department of the Ministry of ___. Refer to “Response to FAQ information for system users” for details of operations concerning FAQ information. (2) Creation of an operations manual The contractor shall, by the commencement of the relevant business, create a helpdesk operations manual concerning the duties of telephone operators and operation procedures of the helpdesk system(note) (hereinafter referred to as the “operations manual”), based on the business operation plan and the business operation implementation outline. (Note) It refers to the environment in which the contractor in charge of operation services and the one in charge of the helpdesk confirm the operations of ___ system, allowing the operation of the same business applications with ___ system by registering pseudo data. ○Education for helpdesk staff In order to make smooth implementation of the relevant operation, the contractor shall, at its responsibility, provide education necessary for helpdesk staff, including operators, before the commencement of service. When providing education for helpdesk staff, the contractor shall make effective use of FAQ contents and simulations (mock environment) and create educational materials, such as education manuals, thus providing efficient and effective education within the contractor’s capacity. The following are details of education for helpdesk staff and support of the Ministry of ___. (1) Education The contractor shall carry out efficient and effective education with respect to the following educational contents: (i) Details of the overall operations of ___. (ii) Function and operations of the ___ system (iii) Details of the operation implementation outline (iv) Details of the operations manual (v) Information security measures (vi) Other necessary education ○Report on helpdesk installation status Status of helpdesk installation operations shall be reported to the supervisory department of the Ministry of ___ on the occasions of the following conferences. The contractor shall convene meetings when necessary to confirm the installation status, in an attempt to grasp the situation. 359 Item Description In the event of an emergency or a serious problem that may disrupt the commencement of a relevant service, the contractor shall immediately report to the supervisory department of the Ministry of ___ ○ Responses through organizational changes and improvements of ___ system, etc. When the revision of documents, including the business operation plan document, business operation implementation outline, and manuals, etc., becomes necessary along with organizational changes and/or system improvements, the contractor shall promptly revise the relevant documents upon consultation with the supervisory department of the Ministry of ___. When necessary, the contractor shall receive information from the design/development contractor with respect to the details of improvements in the ___ system necessary for the revision. Efforts shall also be made not to interfere with the execution of the relevant operation through information sharing and thorough education and information provision to employees engaged in operations. Notes on characteristics of project/information - system Notes on security Helpdesk staff education To provide helpdesk staff with education concerning information security measures to be taken during helpdesk operations. 360 4. Service level management Item Outline of service operations Description To conclude a SLA necessary for helpdesk operations and provide report on the service level. Suggested input (Prepared by the procurer) Product (Prepared by the contractor) Matters to be described in specifications ・Service level items/definition document Example/explanation on description in specifications Examples of descriptions in specifications ・Service Level Agreement (SLA) ・Service level report *When a helpdesk is procured together with an operation, it is necessary to add the details of service works for the formulating plan prescribed in 6.4 Operation. “6.5.4 Suggested input” lists service level items in the examples of specifications for independent procurement of helpdesk operations. [1. Basic requirements to be listed] ・Service level items (operation ratio, abandon rate, backlog rate, call back rate, target response time, response time adherence rate, target support time, support time adherence rate, etc.) ・Creation of an SLA ・Support when the service level has not been achieved ○Service level items Requirements for the relevant category are as follows: (1) Index for service level By assessing the status of achievement of each item of service level in the following table on a monthly basis, the contractor shall report its three months’ result to the Ministry of ___. The degree of achievement of service level during the relevant period shall be confirmed based on the consultation between the contractor and the Ministry of___, by adding some elements, such as an improvement plan, to the monthly status of service level achievement reported by the contractor every month. Table: Index of the degree of service level achievement Achievement level Conditions A: Achieved designated conditions in every service level item B: The number of unachieved service level items accounts for less than 5% of the total number of service level items in the preceding three months C: The number of unachieved service level items accounts for more than 5% and less than 10% of the total number of service level items in the preceding three months D: The number of unachieved service level items accounts for more 361 Item Description than 10% of the total number of service level items in the preceding three months (2) Measures for improving the service level achievement rate When unachieved service level items are attributable to the contractor, the contractor shall make efforts to improve the achievement rate through the following measures: (i) Free response When the SLA has not been consummated for reasons attributable to the contractor, the contractor shall consider and implement its own improvement measures (revision of procedure, installation of framework/tools, tests/inspections, etc.,) and the necessary operations shall be provided for free at the expense of the contractor. (ii) Revision of organization/appointment of full time chief supervisor In the cases of “achievement level C” or lower, the contractor shall not make the chief supervisor (manager of assistant manager) be engaged in other works than those cited in the relevant agreement. (3) Measures for the cases in which the achievement of service level continues to be difficult When the quality of service is extremely abysmal for reasons attributable to the contractor and prospect of improvement is low, the reward may be reduced. ○ Creation of an SLA and conclusion of a Service Level Agreement. The contractor, based on the definition of service level, shall create a service level agreement (SLA) (draft) clarifying the items of service level to be provided, to the supervisory department of the Ministry of ___ and their index before one month of the commencement of services and conclude the Service Level Agreement (hereinafter referred to as “SLA”) with the supervisory department of the Ministry of ___. The contractor shall comply with the concluded SLA. ○ Response when service level has not been achieved. SLA shall prescribe responses to the cases where the service level has not been achieved, which includes revision of service index and review of the contents of agreement, etc. Notes on characteristics of project/information system Notes on security - - 362 5. Helpdesk operations Item Outline of services Description Primary reception, primary response, escalation Recording and analysis of inquiries Extraction and renewal of matters to be posted on the FAQ Remote control or users’ terminal, etc. Suggested input (Prepared by the - procurer) Product ・FAQ information (Prepared by the ・Report on availability status contractor) ・Information on history of inquiries and responses ・Daily report ・Weekly report ・Monthly report Matters to be [1. Basic requirements to be listed] described in ・Primary reception, primary response, escalation specifications -Reception time -Unitary support -Escalation -Primary response -Inquiries handled at the helpdesk ・Recording and analysis of inquiries, extraction and renewal data posted on the FAQ: ・Requirements for completion of inquiries Example/explanation Examples of descriptions in specifications on a description in specifications ○Primary reception, primary response, escalation (1) In principle, operator services shall be available between 9:00 and 18:00 excluding holidays (days stipulated in Article 1 of the Act on Holidays of Administrative Organs). Inquiries by fax and telephone calls shall be accepted 24 hours a day. If operator services are to be shortened or closed for several days, the contractor shall notify the Ministry of ___ to that effect in advance, and the restricted time zone mentioned above can be lifted only when the Ministry of ___ has approved of it. (2) Inquiries from officers of the Ministry of ___ by fax, telephone calls or e-mail shall be handled in a unified manner. (3) Decisions shall be made on whether an inquiry can be answered at the helpdesk. If it is solvable at the helpdesk, a primary response shall be made. If not, the inquiry shall be shifted to the secondary level. (4) Prepare responses to inquires that are deemed to be solvable at 363 Item Description the helpdesk and provide answers to users. (5) Inquiries to be handled at the helpdesk shall be as follows: ・Breakdown of a network computer and/or printer of a client ・Matters related to functions of the business system ・Operating procedures of software and/or devices ・Other matters related to the overall system, etc. ○ Recording and analysis of inquiries, extraction and renewal of data posted on the FAQ (1) To record user information and details of inquires with respect to all the inquires in the helpdesk system (2) To record details of answers in the helpdesk system after the answers have been made. (3) To select and post frequently asked questions and answers in the FAQ Notes on characteristics of project/information - system Notes on security - 364 6. Survey on user satisfaction Item Outline of service operations Suggested input (Prepared by the procurer Product (Prepared by the contractor) Matters to be described in specifications Example/explanation on a description in specifications Description Implementation of survey on system user satisfaction and report of the results Questionnaire survey Report on the survey on user satisfaction [1. Basic requirements to be listed] ・Implementation of a user satisfaction survey ・Target group and method of questionnaire survey ・Report on survey results ・Operational improvement of helpdesk upon consultation with competent officers Examples of descriptions in specifications ○Implementation of a satisfaction survey for system users, report on its results and implementation of operational improvement programs The contractor shall conduct the user satisfaction survey and report its results. Based on the survey results, the contractor shall implement improvements in helpdesk operations, based upon discussions between the supervisory department of the Ministry ___and the contractor. Notes on characteristics of project/information system Notes on security - - 365 7. Helpdesk operation conference Item Description Outline of service To report on helpdesk operations at regular conferences, etc. To operations discuss issues and solutions when necessary (monthly, weekly, annually, special briefing session, etc.). To create and submit reports on conferences. Suggested input ・List of deliverable products (Prepared by the ・Implementation schedule (draft) [Dates of operation conferences procurer) (draft)] Product ・Monthly report (Prepared by the ・Minutes contractor) Matters to be To select written documents to be reported and submitted and described in indicated to that effect. Review and approval process shall be specifications conducted at an appropriate timing. [1. Basic requirements to be listed] ・Creation and review of reports ・Outline, frequency and participants of conferences that require reporting and approval processes. Example/explanation Examples of descriptions in specifications on a description in specifications ○Creation and review of reports The contractor shall report to the supervisory department of the Ministry of ___ with respect to the status of helpdesk operations in the following conferences. The contractor shall make efforts to understand the status by holding conferences to confirm availability status, on an as needs basis, and prepare reports. In the event of an emergency or serious problem that may interfere with the relevant business, a report shall be made immediately for the consideration of countermeasures, without waiting for a regular conference. ○Outline, frequency and participants of conferences that require reporting and approval processes The contractor shall participate in the following conferences that are held by the entire operation center. Operational briefing sessions and annual assessment conferences shall be held at a venue (scheduled to be in Tokyo) designated by the supervisory department of the Ministry of ____. The venue of individual coordination conference shall be coordinated among concerned parties, when necessary. Details of conferences shall be determined after the conclusion of an agreement, based upon 366 Item Description consultation with the supervisory department of the Ministry of ___. (i) Conference on installation reports To report on the progress of developing the helpdesk environment and staff education, etc., during the period of helpdesk installation. Frequency: Every other week Participant ・Secretariat of ___ system ・General manager ・Helpdesk management contractor (ii) Operation briefing session To report to the Secretariat of ___ system on the operational status and service level index. Frequency: Once a month Participant ・Secretariat of ___ system ・General manager ・Operation service contractor ・Helpdesk management contractor ・Application maintenance service contractor ・Hardware maintenance service contractor (iii) Annual assessment conference To report on the performance of services and responses from the preceding year and make assessments of the validity of the service level index. Frequency: Once a year Participant ・Secretariat of ___ system ・General manager ・Operation service contractor ・Helpdesk management contractor ・Application maintenance service contractor ・Hardware maintenance service contractor (iv) Individual coordination conference To be held whenever coordination is separately needed. Frequency: On an as needed basis Participant: To be arranged on an as needed basis Notes on characteristics of project/information - system Notes on security - 367 6.5.3. Deliverable products and timing of delivery The table below lists typical deliverable products and the timing of delivery. The official name of each product and its delivery deadline need to be entered in accordance with the actual situation. Service 1.Creation of operation plan Delivery deadline Deliverable product Implementation plan document Within two weeks after the conclusion of an agreement Helpdesk environmental construction diagram Within two weeks after the conclusion of an agreement Establishment plan document Within one month after the conclusion of an agreement Before commencement of service Operation plan document, outline of operation implementation 2.Business transfer for operation Transfer plan document to successors 3.Development of operation environment Helpdesk education materials One month prior to transfer Transfer materials to successors Before commencement of service Helpdesk operations manual Telephone lines for the helpdesk Installation diagram of telephone lines the for helpdesk Telephone lines for IVR server Installation diagram of telephone lines for IVR server 4.Service level management SLA Service level report Monthly 5.Helpdesk operations FAQ information Monthly Report on operation status Information on inquires/responses: at the time of the completion of a task Before commencement of service Information on inquires/responses 6.Survey on user satisfaction Report on the results of the survey on user satisfaction By designated date 7.Helpdesk operation conference Monthly report Monthly Report on completion By designated date Minutes 368 6.5.4. Suggested input The following table shows input and timing to be presented to the procurer (proposer) in advance. the official name of each product and its delivery deadline need to be entered in accordance with the actual situation. Service 1.Creation of operation plan Input Timing for presenting input Planned establishment and estimated number of users To be listed in specifications and appendix at the time of tender publishing Table of division of roles Overall schedule Organizational chart Operational framework 2.Business transfer for operation Transfer documents from predecessors (system constructor in the case of new system integration) To be listed in specifications and appendix at the time of tender publishing Transfer materials, operational procedures, operational tasks, and training on security, etc. from predecessors 3.Development of work environment Restrictions on installation of lines 4.Service level management Service level items/definition document Details of organizational changes and system modifications required for changes in helpdesk manuals To be listed in specifications and appendix at the time of tender publishing To be listed in specifications and appendix at the time of tender publishing 5.Helpdesk operations - - 6.Survey on user satisfaction - - 7.Helpdesk operations conference List of deliverable products To be listed in specifications and appendix at the time of tender publishing 369 Examples of service level items Number. Service level item Regulations Unit Open hours of helpdesk (response to failures) Open hours of the helpdesk dealing with faults Open hours of helpdesk (regular inquiries) Open hours of the helpdesk for regular inquiries Average response time Primary response time Time spent on resolving problems Time spent by operator from receiving failure report to providing primary response Average number of inquiries per day Hour(s) Hour(s) Call busy rate Call abandonment rate Call busy rate: Calls failed to be connected Call abandonment rate: Calls failed to be answered % Percentage of problems solved (closed) within the designated period of time % 7 Rate of problems solved at helpdesk (time) Percentage of time spent and frequency until escalation 8 Hour/times of helpdesk escalations %・number of times Helpdesk backlog rate Percentage of unsolved problems at the end of the day % Helpdesk call back rate % Service hours for the application of use related to service desk information system Percentage of call backs for inquiries once completely answered or fixed Application for intranet/internet use (application for the use of common ID management system (LDAP)), application for e-mail use and application for mobile use, etc. 12 Date of service desk application process Time (days) to process various applications for use 13 Report 1 2 3 4 5 Number of inquiries to helpdesk 6 From hour to hour Case/day 9 10 11 14 From hour to hour Day Regular report To make reception status available on the website, enabling understanding of the inquiry status, in cases of changes in the business system 370 Item Item 6.5.5. Division of roles In this Section, examples of roles divided among helpdesk operators, authorities and contractors of other services are described. In separated/breakout procurement, the division of roles among procured services, related procurement and the relevant procurement should be clarified in accordance with the scope of separated orders and the ministerial policies and presented at the time of tender publishing. When considering procurement, services to be realized in the entire procurement should be identified. A clear division of roles and services should be specified, and a table of division of roles should be complied so that concerned parties can agree that there are no omissions/errors in the services/roles in breakout procurement. Example of the table of division of roles ○: Main operator, △: Support, advice HW maintenance contractor SW maintenance contractor AP maintenance contractor △ - - - ○ △ △ △ - - - - ○ - - - - △ - ○ - △ - △ - △ ○ - △ ○ - ○ Supervisory section Task Creation of operation plan Business transfer for operation Development of work environment Service level management Helpdesk operations Survey on user satisfaction Helpdesk operations conference (report) Helpdesk operations conference (assessment) ○ ○ △ System constructor Operation contractor iDC contractor Helpdesk contractor △ △ ○ △ ○ △ △ ○ △ △ - ○ ○ - - △ - ○ △ △ ○ △ ○ ○ ○ ○ ○ ○ △ * System constructor applies only in the cases where new system integration and transfer for operations are to be carried out. 371 6.6. Maintenance Maintenance operations are services to repair errors that occurred after the start of information system operations and to respond to requests for minor modification of functions in the system. Services in this phase include regular maintenance (regular inspection) carried out to prevent faults and problems, emergency maintenance in the event of a problem or fault, and support for system users and the supervisory sections, etc. Since the details of services in this phase are formulated in the preceding phase of “design/development,” the product of maintenance design is the input in this phase. Details of four services implemented in maintenance are shown in Table 6.6.1. Classification of detailed services Definition 6.6.1. Hardware maintenance HW maintenance, (server, storage, common network computer, office printer, network function: router, switch, etc.) (including software installed in hardware) 6.6.2. Software maintenance 6.6.3. Application maintenance 6.6.4. System infrastructure maintenance Maintenance of commercial OS, commercial middleware, and commercial application software(excluding OS, middleware, business software of OSS) Maintenance of business application software, excluding commercial OS and commercial package software (including OS, middleware and business software of OSS) Maintenance of “EIP,” “open webservers, “groupware, fileserver, mail server,” “integrated account management, authentication, authorization (access control),” “integrated directory,” “WAN, intra-ministerial LAN, DNS/DHCP/Proxy, remote access,” and “network lines,” which are listed in “Chapter V: Description of Technical Domain” of technology reference model. Table 6.6.1 Classification of detailed services and definition of maintenance 372 6.6.1. Hardware maintenance 6.6.1.1. Definition of procurement areas Hardware maintenance is the maintenance service for hardware (server, network computer, printer, storage, office printer, network functions: router and switch, etc.). In service procurement concerning hardware maintenance, goods (provision of devices), installation/coordination of devices, and development of environment may be procured under the same agreement. However, this section exclusively describes services concerning hardware maintenance. Planning phase Requirements definition 要件定義 phase Operation/maintenance 運用・保守フェーズ phase Development phase 開発フェーズ 6.2 6.2.3 Support for ( 等) procurement (Project management, etc.) 6.3 6.4 運用 6.4 Operation 6.5 Helpdesk 6.1 Support 6.1全体計画 for master 策定支援 plan formulation 6.2.2 Support for procurement 6.2 1 調達支援 (requirements ( 等) definition, etc.) 6.3 System integration (design/development) 6.3 ハードウェア更改 6.3 機能追加 6.6 Maintenance 6.7 Tasks incidental to procurement of devices Hardware maintenance Software maintenance Application maintenance System infrastructure maintenance 6.8 Tasks incidental to procurement of iDC equipment ・ 設備) 6.9 Network procurement 6.12 Security Table 6.6.1-1 Items corresponding to the areas of procurement of services 373 6.6.1.2. Services to be listed in specifications 6.6.1.2.1. Typical service operations The following table shows services to be included in the specifications. The corresponding SLCP-2007 activities are also given. For actual procurement, correspondence to SLCP activities should be examined so as not to omit necessary information. Items corresponding to the Basic Guidelines on Procurement (BGP) are also listed. To write specifications, a draft of procurement specifications should be prepared by selecting the appropriate items while coordinating with the corresponding Program Management Office (PMO). Service operations Outline of service operations 1.Formulation of hardware maintenance plan 2.Service level management Formulation of the hardware maintenance plan (maintenance work plan, work framework, etc.) Concluding an SLA and recording work status in relation to service the level management index, when ensuring the quality (level) of service is necessary. Preventative inspection and changing of expendables to be carried out once or more times per year, pursuant to the requirements for maintenance, etc. On-site support for hardware faults 3.Regular maintenance/regular inspection 4.Fault support Activities of SLCP-2007 1.8.1.2 Creation of plan and procedures - 1.8.2.1 Problem report or analysis of request for modification 5.Support for version upgrade Providing release information, such as firmware, etc., and upgrading work 1.8.3.1 Analysis and decision on modification part 1.8.3.2 Implementation of modification 1.8.3.2 Implementation of modification 6. Technical support Technical support based on requests made by the supervisory section or operation support contractor, etc. 1.7.6.2 User support 1.8.2.2 Replay or inspection of problems 374 Chapter and section of specifications corresponding to BGP (and its title) Chapter VI (2) Requirements for hardware maintenance (and outline shall be listed in Chapter II (5) Work description/ deliverable product) 6.6.1.2.2. Explanation on services and examples of descriptions in specifications 1. Formulation of hardware maintenance plans Item Description Outline of service To formulate hardware maintenance plans (including maintenance operations work plans and organizational charts listing emergency and non-emergency contact numbers, etc.) Suggested input ・Maintenance outline (Prepared by the ・Maintenance procedures procurer) ・Maintenance plan (draft) ・SLA (draft) ・Statement of Work (concerned business entities and the procurer of the relevant system) Product ・Hardware maintenance plan documents (including progress chart, (Prepared by the emergency/non-emergency contact list, maintenance organizational contractor) chart, etc.) Matters to be To indicate requirements for the formulation of a maintenance plan described in specifications [1. Basic requirements to be listed] ・Maintenance time ・Details to be included in the plan (work schedule, emergency contact list, list of maintenance centers, etc.) ・Deadline for submission of the plan ・Roles of concerned parties in maintenance work (refer to 6.6.1.5 for an example of division of roles) [2. Requirements to be added depending on type/characteristics of project] ・Compliance with the SLA Example/explanation Examples of descriptions in specifications on a description in specifications [1. Basic requirements to be listed] (i) Hours of on-site maintenance work shall be from 9:00 to 18:00 excluding days public offices are closed (including holidays and national holidays). However, if hardware failure may cause serious impact on business, maintenance and inspections involving system shutdown shall be available outside of the above hours. (ii) The contractor shall create a maintenance plan for regular inspections, hardware maintenance work and a maintenance organizational chart for emergency/non-emergency cases, which shall be submitted and approved by the supervisory section within 14 days of receiving the order. (iii) When formulating a maintenance work plan, the contractor shall be fully careful not to interfere with business by (for example) avoiding system shutdowns (service suspension). The contractor shall be 375 Item Description prepared to work on holidays if the maintenance work may influence business, based upon consultation with the supervisory section with respect to the dates of work. The contractor shall create a maintenance plan by arranging workdays and time tables in consideration for minimizing system shutdown time/maintenance time, while coordinating the work schedule of regular inspections/regular maintenance with operation/maintenance-related companies. (iv) The contractor shall establish a helpdesk to be able to respond quickly to inquiries during regular service hours in the event of fault of devices as well as when requests are made from the supervisory section, and gain approval from the supervisory section. Maintenance staff shall be engineers with sufficient knowledge and experience on devices covered by maintenance. [2. Requirements to be added depending on type/characteristics of project] (v) The contractor shall conclude an SLA, based on specifications and proposals submitted at the time of procurement by the contractor. The contractor shall also create a maintenance plan giving due consideration to the maintenance framework for preventive maintenance and trouble-shooting that are necessary for attaining the index for service level management. Notes on characteristics of project/information - system Notes on security - 376 2. Service level management Item Description Outline of service To manage service level by setting a service level index and target operations values when it is necessary to ensure the quality (level) of services associated with hardware maintenance. Suggested input (Prepared by the ・SLA (Draft) (including service level management index) procurer) Product (Prepared by the contractor) ・SLA (including service level management index) ・Service level management plan ・Service level report Matters to be To be specifically stated in service level management index and the SLA. described in Such documents as the service level management index and SLA are specifications drafted by the contractor and shall state to the effect that an agreement (contract) will be concluded upon consultation between the two parties and may change after consultation. If strict compliance with an SLA is demanded, the documents shall mention periodical reviews on the performance of the service index as well as the improvement process or penalties for cases of non-compliance. Since service level management is not a compulsory requirement, full discussions shall be conducted on whether an SLA needs to be applied to a given procurement project. [2. Requirements to be added depending on type/characteristics of project] ・Service level management index (draft) ・Implementation of consultation prior to concluding an SLA ・Concept of surcharge and penalty ・Measurement of performance of the service level management index and periodical reviews on SLA attainment ・Requirements in the case of non-compliance with the SLA (approaches to responses and improvements for free) 377 Item Example/explanation Description Examples of descriptions in specifications on a description in specifications [1. Basic requirements to be listed] (i) In the relevant procurement, a Service Level Agreement (SLA) shall be concluded upon consultation with the contractor for the purpose of verifying that the quality of maintenance provided by the contractor is kept high. The contractor shall formulate the draft of the service level agreement contributing to maintenance and improvement of service level, based on the draft of service level management index described in the relevant specifications, and shall present the draft in the form of a proposal. No Service level Specifics management index 1 Index value Mean Time To Repair Mean Time To Repair is Within (MTTR) the monthly average 6 hours time that a device took to recover from any failure, during service operation. Time of occurrence of failure is the time when a failure has been detected or recognized by notice. Recovery from failure is the state in which causes of failure of the device has been removed, normal operation has been observed and the device is available for use. (ii) Based on the Service Level Agreement concluded with the supervisory section, the contractor shall measure the implementation status by the service level management index every month, and report the attainment status at the service level briefing sessions to be held every three months. [2. Requirements to be added depending on type/characteristics of project] (iii) Consultation between the contractor and the supervisory section shall be held based on the report of service level attainment status 378 Item Description submitted by the contractor, to determine the degree of attainment of the SLA during the relevant period. When non-attained SLA items accounts for less than 90%, the contractor shall make an improvement proposal at its own expense and implement countermeasures upon gaining approval of the supervisory section. Degree Percentage of of attainment payment A 100%(full) Conditions Attained prescribed conditions in all SAL items. 97% Percentage of non-attained SLA items accounts for less than 5% of total SLA B items. 94% C Percentage of non-attained SLA items accounts for more than 5% and less than 10% of total SLA items. 90% D Percentage of non-attained SLA items accounts for more than 10% of total SLA items. Notes on Service level management is not a compulsory requirement, but is the characteristics of requirement to be set when the quality of maintenance service is project/information emphasized. system One should be careful because setting a service level index and objectives and adding excess requirements may raise commission fees. Notes on security - 379 3. Regular maintenance/regular inspection Item Outline of service operations Suggested input (Prepared by the procurer) Product (Prepared by the contractor) Matters to be described in specifications Description To implement regular inspections more than once per year and carry out expendable changes and device adjustments, based on the maintenance outline, etc. Maintenance outline Maintenance procedures ・Report on regular maintenance [1. Basic requirements to be listed] ・Number and frequency of regular maintenance ・Details of maintenance work (cleaning, inspection, diagnosis by test programs, confirmation of operation following the maintenance work) ・Devices subject to regular maintenance ・Restrictions on work hours ・Creation of maintenance reports and reports on completion of regular maintenance ・Response at the time of fault detection Example/explanation Examples of descriptions in specifications [1. Basic requirements to be listed] on a description in (i) The contractor shall carry out maintenance/inspections once a specifications year, based on the “maintenance plan,” “maintenance outline,” and “maintenance procedures,” etc. (ii) The contractor shall give due consideration to the impact on business associated with the relevant system shutdown. If a regular inspection causes system shutdown, the contractor shall consult with the supervisory section in advance, and gain approval. (iii) Every time the contractor implements maintenance work based on the “maintenance plan,” the contractor shall create a “post-maintenance report” and gain approval of the work result from the supervisory section. (iv) The contractor shall formulate response plans against detected failures/troubles as a result of maintenance/inspections, and gain the approval of the supervisory section. In the cases where countermeasures have been taken during a regular inspection, a “post-maintenance report” may serve as a substitute. Notes on characteristics of - project/information system Notes on security 380 4. Fault support Item Outline of service operations Description To receive hardware fault notices and carry out on-site support for fault recovery. Suggested input (Prepared by the procurer) Product (Prepared by the contractor) Matters to be described in specifications ・Maintenance outline ・Maintenance procedures ・Fault separation procedures ・Fault report Example/explanation on description in specifications Notes on [1. Basic requirements to be listed] ・Definition of the date/time of support service when a hardware fault occurs ・Creation of a fault repair work report [2. Requirements to be added depending on type/characteristics of project] ・To erase data completely at the time of disposal/change of a hard disk due to physical breakdown. ・Devices applicable for send-back maintenance services, the hardware maintenance contractor shall prepare an alternate device in advance, and carry out the replacement promptly when a fault occurs. Examples of descriptions in specifications [1. Basic requirements to be listed] (i) The contractor shall dispatch maintenance staff in response to fault notifications of devices or requests made from the supervisory section. However, in the event of an emergency, maintenance work shall be carried out outside maintenance hours upon consultation with the supervisory section. (ii) The contractor shall promptly carry out procurement, replacement and repair of parts and make efforts for early recovery of devices. (iii) When re-installation and data recovery are necessary due to hard disk change, the contractor shall request the application maintenance contractor and system maintenance contractor to carry out the work through the supervisory section. [2. Requirements to be added depending on type/characteristics of project] (iv) When external memory media, such as hard disks and /or tape media, are broken, which are then taken away from the installation site, data stored in the external memory media shall be completely erased or physically destroyed and taken away from the venue upon gaining approval from the supervisory section. (v) When the relevant device is subject to send-back service alone, the contractor shall, in advance, prepare an alternative device, and promptly replace the relevant device when a fault occurs. Since fault support shall be carried out in cooperation among the 381 Item characteristics of project/information system Description operation contractor, software maintenance contractor, application maintenance contractor, system infrastructure maintenance contractor and related system contractor, etc., it is necessary to clarity the roles with the concerned parties and the scope of responsibility of each contractor. Notes on security - 382 5. Support for version upgrade Item Description Outline of service To acquire release information on firmware, etc., and provide the operations information to the supervisory section. To carry out the upgrading of firmware, etc., upon consultation with the supervisory section. Suggested input ・Maintenance outline (Prepared by the ・Maintenance procedures procurer) Product ・Task report (Prepared by the contractor) Matters to be [1. Basic requirements to be listed] described in ・Report and provision of patch updates specifications ・Time spent from release to report of patch updates ・Type of submitted files, etc. ・Change operations, such as environment settings associated with firmware renewal, etc. Example/explanation Examples of descriptions in specifications on a description in specifications [1. Basic requirements to be listed] (i) The contractor shall acquire information on firmware updates for devices from manufactures/agents of the relevant devices, and report to the supervisory section within seven days after the disclosure of the update information. (ii) The contractor shall apply the update information to the relevant devices, when such information is deemed to be necessary, upon gaining approval from the supervisory section within one month after the approval of ministries. (iii) Upon approval of the supervisory section, the version upgrade of firmware, etc. shall be carried out with due consideration to work schedule and time so as not to cause an impact on system operations. When configuration change is necessary along with a firmware upgrade, such change shall be carried out at the time of the upgrading work. Notes on characteristics of project/information - system Notes on security Renewal of firmware, configuration change, etc. The latest information for firmware related to security and hardware stability, such as BIOS, shall be constantly obtained and the hardware maintenance contractor shall be requested to implement renewal work whenever necessary. 383 6. Technical support Item Description Outline of service To implement technical support in response to requests made by the operations supervisory section or operator. Suggested input Maintenance procedures (Prepared by the Maintenance outline procurer) Affiliation/number (expected) of the source of inquiry Product ・Technical support implementation report (Prepared by the contractor) Matters to be [1. Basic requirements to be listed] described in Time of receiving request for support specifications Response to technical inquiries Support for separating trouble [2. Requirements to be added depending on type/characteristics of project] Deadline of response to inquiry Submit implementation result report to the supervisory section and operation support company Example/explanation Examples of descriptions in specifications on a description in specifications [1. Basic requirements to be listed] The contractor shall promptly answer and give advice to inquiries made by the supervisory section or the operator. The contractor shall dispatch maintenance staff to the site in response to an escalation notice from the supervisory section/operator, and provide support for solutions in cooperation with concerned parties (such as the supervisory section, operator, or other maintenance companies, etc.). The contractor shall carry out a hardware log analysis, confirmation/provision of hardware configuration information when necessary, to solve problems. When the cause of the problem is stemmed in the hardware, the contractor shall promptly offer recovery service. Inquiries are accepted, in principle, from 9:00 to 18:00 on days excluding the holidays of public offices (days stipulated in Article 1, paragraph 1 of the Act on Holidays of Administrative Organs (law no. 91, 1988). The contractor shall report to the supervisory section on work results immediately after the problem has been solved or recovery work has been completed. [2. Requirements to be added depending on type/characteristics of project] The contractor shall report on response and analysis results within two days after receiving an inquiry [excluding the holidays of public offices 384 Item Description (days stipulated in Article 1, paragraph 1 of the Act on Holidays of Administrative Organs (law no. 91, 1988))]. When response cannot be presented within the deadline, the contractor shall inform the source of inquiry about progress and the expected date of response. The contractor shall provide the supervisory section and operation support company with a work report immediately after the completion of support work. Notes on When a comprehensive inquiry reception desk, such as an integrated characteristics of helpdesk, is established, specifications shall be added to enable project/information escalation from the reception desk. system Notes on security - 385 6.6.1.3. Deliverable products and timing of submission The table below lists typical deliverable products and the timing of delivery with respect to hardware maintenance services. The official name of each product and its delivery deadline need to be entered in accordance with the actual situation. Service 1.Formulation of hardware maintenance plan 2.Service level management 3.Regular maintenance/ regular inspection 4.Fault support Deliverable product Hardware maintenance plan Maintenance outline/ maintenance procedures (revised version) SLA Service level management plan Report on the results of service level management Regular maintenance reports Fault report 5.Support for version upgrade Work report 6.Technical support Inquiry management table Work plan (for request for support) Report on the implementation of support work Delivery deadline Within 14 business days after conclusion of the agreement Within 14 business days after conclusion of the agreement On the designated date, every time service level is measured Within seven days after completion of work Within seven days after completion of work Within seven days after completion of work Designated date Fourteen days prior to implementation of work Within seven days after completion of work 6.6.1.4. Suggested input The following table shows input and timing to be presented to the procurer (proposer) in advance. The official name of each product and its delivery deadline should be entered in accordance with the actual situation. Service 1.Formulation of hardware maintenance plan Input Maintenance plan (draft) Service level items/definition SLA Statement of Work (SOW) Maintenance outline Maintenance procedures 2.Service level management 3.Regular maintenance/ regular inspection 4.Fault support Service level items / definition SLA Maintenance outline Maintenance procedures 5.Support for version upgrade Maintenance outline Maintenance procedures 6.Technical support Maintenance outline Maintenance procedures Maintenance outline Maintenance procedures Timing for presenting input Included in procurement specifications or as attachment During tender period: Disclosed to bidders After conclusion of the agreement: Lent to the contractor Included in procurement specifications or as attachment During tender period: Disclosed to bidders After conclusion of the agreement: Lent to the contractor During tender period: Disclosed to bidders After conclusion of the agreement: Lent to the contractor During tender period: Disclosed to bidders After conclusion of the agreement: Lent to the contractor During tender period: Disclosed to bidders After conclusion of the agreement: Lent to the contractor 386 6.6.1.5. Division of roles Examples of roles divided among the hardware maintenance contractor, authorities and contractors of other works are described below. In separated/breakout procurement, the division of roles among procured services, related procurement and the relevant procurement should be clarified in accordance with the scope of separated orders and the ministerial policies and presented at the time of tender publishing. When considering procurement, services to be realized in the entire procurement should be identified. A clear division of roles and services should be specified, and a table of division of roles should be compiled so that concerned parties can agree that there are no omissions/errors in the services/roles in breakout procurement. ○: Main operator, △: Support, advice Supervisory section Tasks Planning and procurement of operation maintenance plan for hardware, packaged software, and network, etc. On-site support for hardware Provision of packaged software in batches and implementation of off-site support On-site support for networks ○ HW maintenance contractor △ SW maintenan ce contractor AP maintenance contractor Operation contractor iDC contractor △ △ △ - △ △ - △ - ○ - - - - ○ - - △ ○ Helpdesk contractor △ - △ - - - - - - Daily system operation System and network monitoring Security monitoring - - - - ○ - - - - ○ - - - - ○ △ ○ - - - - △ - Handling inquiries from users Response to inquiries from the supervisory section and escalation from the joint Helpdesk Primary separation in the event of problems Secondary response to the problem (hardware fault) Secondary response to the problem (software/application software fault) Secondary response to the problem (iDC equipment fault) System recovery process in the event of faults Maintenance of application software Collection, analysis, report, suggestions concerning operation management information Expendables management - ○ - ○ ○ ○ ○ ○ ○ △ △ △ ○ △ △ △ - ○ △ △ - △ △ △ ○ △ △ - △ △ △ △ ○ - △ △ ○ - - △ - - ○ - - - △ △ - △ ○ △ - △ - △ - △ - - ○ - ○ - - Table 6.6.1.5.1 Table of Division of Roles for Operation/Maintenance Contractor (example) 387 6.6.2. Software maintenance 6.6.2.1. Definition of procurement area Software maintenance includes the maintenance services for products, including commercial OSs, middleware and application software, etc.; any software other than commercial products, such as newly developed software or open software (OSS), is not included in this category. Software maintenance is often procured together with hardware maintenance; however, this section exclusively deals with the services related to software maintenance. Planning phase Requirements definition 要件定義 phase Operation/maintenance 運用・保守フェーズ phase Development phase 開発フェーズ 6.2 6.2.3 Support for ( 等) procurement (Project management, etc.) 6.3 6.4 運用 6.4 Operation 6.5 Helpdesk 6.1 Support 6.1全体計画 for master 策定支援 plan formulation 6.2.2 Support for procurement 6.2 1 調達支援 (requirements ( 等) definition, etc.) 6.3 System integration (design/development) 6.3 ハードウェア更改 6.3 機能追加 6.6 Maintenance 6.7 Tasks incidental to procurement of devices Hardware maintenance Software maintenance Application maintenance System infrastructure maintenance 6.8 Tasks incidental to procurement of iDC equipment ・ 設備) 6.9 Network procurement 6.12 Security Figure 6.6.2-1 Items corresponding to the areas of procurement of services 388 6.6.2.2. Services to be listed in specifications 6.6.2.2.1. Typical service operations The following table shows services to be included in the specifications. The corresponding SLCP-2007 activities are also given. For actual procurement, correspondence to SLCP activities should be examined so as not to omit necessary information. Items corresponding to the Basic Guidelines on Procurement (BGP) are also listed. to write specifications, a draft for procurement specifications should be prepared by selecting appropriate items while coordinating with the corresponding Program Management Office (PMO). Service operations 1.Formulation of software maintenance plan 2. Provision of correction (patch) file and version upgrade program 3.Technical support Outline of service operations Formulation of software maintenance plan containing details of maintenance services for various products and emergency/non-emergency contact list, etc. Provision of release information on correction (patch) file, etc., and correction file Provision of technical support (off-site support) for software products covered by maintenance Activities of SLCP-2007 1.8.1.2 Creating of plan and procedures 1.8.1.2 Creation of plan and procedures 1.8.3.1 Analyzing and deciding on the parts to be corrected 1.8.3.3 Implementation of correction of purchased package 1.7.6.2 User support 389 Chapter and section of specifications corresponding to BGP Chapter XI (1) Requirements for software maintenance (and the abstract shall be included in Chapter II (5) Details of work/deliverable products) 6.6.2.2.2. Explanations and examples of descriptions in specifications concerning services 1. Formulation of software maintenance plan Item Outline of service operations Suggested input (Prepared by the procurer) Product (Prepared by the contractor) Matters to be described in specifications Example/explanation of a description in specifications Notes on characteristics of project/information system Notes on security Description To formulate software maintenance plans (details of maintenance services of products and emergency/non-emergency framework, etc.) and gain the approval of the supervisory section ・Maintenance outline ・List of software products covered by maintenance ・Maintenance plan (including progress chart, emergency/non-emergency contact list, and maintenance organizational chart, etc.) To indicate requirements for the formulation of maintenance plans [1. Basic requirements to be listed] ・Required framework and products of the contractor ・Support service hours (Open hours for inquiry desk) Examples of descriptions in specifications [1. Basic requirements to be listed] (i) The contractor shall create and deliver a maintenance plan, based on the “relevant procurement specifications,” as well as “maintenance design” and “maintenance procedures” (issued separately), etc., and receive the approval of the supervisory section. (ii) The contractor shall establish a helpdesk to be able to respond quickly to inquiries during regular service hours in the event of software faults as well as in response to requests from the supervisory section, and gain approval from the supervisory section. Maintenance staff shall be engineers with sufficient knowledge and experience on software products covered by maintenance. Unlike other type of maintenance, software maintenance characteristically does not provide on-site work, but provides off-site support only. The contractor should consider an extension of inquiry service hours for software maintenance in the core system. - 390 2. Provision of correction (patch) files and version upgrade program Item Outline of service operations Suggested input (Prepared by the procurer) Product (Prepared by the contractor) Matters to be described in specifications Examples of a descriptions in specifications Notes on characteristics of project/information system Notes on security Description To provide correction (patch) files and version upgrade programs of software products covered by maintenance, as well as release information on the said programs. ・List of software products covered by maintenance ・Maintenance status report [1. Basic requirements to be listed] To promptly provide correction program and version upgrade information The subcontracting agreement shall be concluded with a software copyright holder when necessary to give the procurer the applied right to the correction (patch) file and version upgrade program. Examples of descriptions in specifications (i) When version upgrade programs responding to the function enhancement of software products covered by maintenance and minor version upgrade programs to respond to the correction of faults are released, the contractor shall immediately notify the supervisory section. The contractor shall also provide a license for version upgrade and minor version upgrade programs that have been released during the maintenance period. (ii) For the provision of the said program and license, the contractor shall conclude a contract and carry out coordination with the license provider of the relevant software product, when necessary, and this shall be the responsibility of the contractor. The right to upgrade some software products, in the case of major version upgrades, etc., may not be exercised due to the license regulations of the relevant software product. The contractor should inform the application maintenance contractor or the mainboard maintenance contractor about information pertaining to software bugs, patch and version upgrades, etc., immediately after such information becomes available and instruct the application maintenance contractor or the mainboard maintenance contractor to a conduct preliminary assessment of the possibility of patch application. In order to make early decisions on the possibility of patch application, there is a way to include the application maintenance contractor and the mainboard maintenance contractor in the list of recipients of information on software version upgrades provided by the software maintenance contractor. 391 3. Technical support Item Outline of service operations Description Response to technical inquiries concerning software products covered by maintenance Suggested input (Prepared by the procurer) Product (Prepared by the contractor) Matters to be described in specifications Examples of a descriptions in specifications ・List of software products covered by maintenance Notes on characteristics of project/information system Notes on security ・Solutions to inquiries [1. Basic requirements to be listed] ・Establishment of software technical support desk An example of a description in specifications ・ To establish a support desk for inquiries about software products covered by maintenance and to provide support for the relevant software Unlike other types of maintenance, software maintenance does not provide on-site work, but often provides off-site support through phone calls, emails or websites, etc. The contractor should consider an extension of inquiry service hours for software maintenance in the core system. - 392 6.6.2.3. Deliverable products and timing of submission The table below lists deliverable products and timing of delivery with respect to software maintenance services. The official name of each product and its delivery deadline need to be entered in accordance with the actual situation. Service 1.Formulation of maintenance plan 2. Provision of correction (patch) files and version upgrade programs 3.Technical support Deliverable product Maintenance plan Correction (patch) file and version upgrade program Solution to inquiry Delivery deadline Within two weeks after conclusion of the agreement At the time of patch release or update program release At the time of inquiry (on an as needed basis) 393 6.6.2.4. Suggested input The following table shows input and timing to be presented to the procurer (proposer) in advance. The official name of each product and its delivery deadline should be entered in accordance with the actual situation. Service Input 1.Formulation of List of software products covered by maintenance plan maintenance 2.Provision of correction List of software products covered by (patch) files and version maintenance upgrade programs 3.Technical support List of software products covered by maintenance 394 Timing for presenting input Included in procurement specifications or as an attachment at the time of tender publishing Included in procurement specifications or as an attachment at the time of tender publishing Included in procurement specifications or as an attachment at the time of tender publishing 6.6.2.5. Division of roles In separated/breakout procurement, the division of roles among procured services, related procurement and the relevant procurement should be clarified in accordance with the scope of separated orders and the ministerial policies and present at the time of tender publishing. When considering procurement, services to be realized in the entire procurement should be identified. A clear division of roles and services should be specified, and a table of division of roles should be compiled so that concerned parties can agree that there are no omissions/errors in the services/roles in breakout procurement. ○: Main operator, △: Support, advice Tasks Plan and procurement of operation maintenance plans for hardware, packaged software and networks, etc. On-site support for hardware Provision of packaged software in batches and implementation of off-site support On-site support for networks Supervisory section ○ HW maintenance contractor △ SW maintenance contractor AP maintenance contractor Operatio n contract or iDC contractor Helpdesk contractor △ △ △ - △ △ - △ - ○ - - - - ○ - - △ ○ △ - △ - - - - - - Daily system operation System and network monitoring Security monitoring - - - - ○ - - - - ○ - - - - ○ △ ○ - - - - △ - Handling inquiries from users Response to inquiries from the supervisory section and escalation from the joint Helpdesk Primary separation in the event of a problem Secondary response to the problem (hardware fault) Secondary response to the problem (software/application software fault) Secondary response to the problem (iDC equipment fault) System recovery process in the event of a fault Maintenance of application software Collection, analysis, report, suggestions concerning operation management information Expendables management - ○ - ○ ○ ○ ○ ○ ○ △ △ △ ○ △ △ △ - ○ △ △ - △ △ △ ○ △ △ - △ △ △ △ ○ - △ △ ○ - - △ - - ○ - - - △ △ - △ ○ △ - △ - △ - △ - - ○ - ○ - - Table 6.6.2.5.1 Table of Division of Roles for Operation/Maintenance Contractor (example) 395 6.6.3. Application maintenance 6.6.3.1. Definition of procurement area Application maintenance is the maintenance services for operational applications developed from scratch and customized packaged software (the customized part or the entire packaged software including customized part). This Section includes OSS (OS, middleware, business software) to which there is no fixed-style of maintenance service or maintenance services that have not been provided by distributors, etc. Planning phase Requirements definition 要件定義 phase Operation/maintenance 運用・保守フェーズ phase Development phase 開発フェーズ 6.2 6.2.3 Support for ( 等) procurement (Project management, etc.) 6.3 6.4 運用 6.4 Operation 6.5 Helpdesk 6.1 Support 6.1全体計画 for master 策定支援 plan formulation 6.2.2 Support for procurement 6.2 1 調達支援 (requirements ( 等) definition, etc.) 6.3 System integration (design/development) 6.3 ハードウェア更改 6.3 機能追加 6.6 Maintenance 6.7 Tasks incidental to procurement of devices Hardware maintenance Software maintenance Application maintenance System infrastructure maintenance 6.8 Tasks incidental to procurement of iDC equipment ・ 設備) 6.9 Network procurement 6.12 Security Figure 6.6.3-1 Items corresponding to the areas of procurement of services 396 6.6.3.2. Services to be listed in specifications 6.6.3.2.1. Typical service operations The following table shows services to be included in the specifications. The corresponding SLCP-2007 activities are also given. For actual procurement, correspondence to SLCP activities should be examined so as not to omit necessary information. Items corresponding to the Basic Guidelines on Procurement (BGP) are also listed. To write specifications, a draft for procurement specifications should be prepared by selecting appropriate items while coordinating with the corresponding Program Management Office (PMO). Service operations Outline of service operations 1. Transfer from designers/developers Transfer from designers/developers 2. Formulation of application maintenance plan Formulation of application maintenance plan (including maintenance work plan and organizational charts with non-emergency/emergency contact lists, etc.) Conclusion of SLA Report on the compliance status of the service level management index On-site support for system failure 3.Service level management 4.Fault support 5.Program modification Partial modification and function addition for programs, development for bug fixes, tests, release in production environments, system impact analysis before patch applications, preliminary evaluations, and patch applications in operational environments 6.Technical support Implementation of technical support in response to requests made by the supervisory section and operators Activities of SLCP-2007 1.8.1.2 Creation of plan and procedures - 1.8.2.1 Problem report or analysis of request for modification 1.8.2.2 Replay or inspection of problems 1.6.6 Detailed software design 1.6.7 Creation of software code and test 1.6.8 Software integration 1.8.2 Problem identification and modification analysis 1.8.3 Implementation of modification 1.8.4 Maintenance review and acceptance 1.8.3 Implementation of modification 1.8.4 Maintenance review and acceptance 397 Chapter and section of specifications corresponding to BGP (and its title) Chapter XI (1) Requirements for software maintenance (and the abstract shall be included in Chapter II (5) Details of work/deliverable products) 6.6.3.2.2.Explanation on services and examples of descriptions in specifications 1. Transfer from designers/developers Item Outline of Service operations Description Transfer from design/development contractor Suggested input [Products related to operation and maintenance created by the design/development contractor] ・ Maintenance plan (draft) ・ Maintenance design ・ Maintenance procedures ・ Maintenance tools ・ Transfer implementation plan ・ Transfer implementation report ・ Maintenance plan ・ Organizational charts [1. Basic requirements to be listed] ・ Creation of a transfer implementation report ・ Implementation of the transfer from the design/development contractor before the full operation of the new system or the commencement of the contract period. ・ To make inquiries and requests for modification to the transferors, if questions arise about materials created by the transferors, such as maintenance plans/maintenance procedures, etc. ・ Creation of maintenance procedures based on the documents for the formulation of maintenance procedures ○Transfer from designers/developers, etc. ・ The contractor shall consult with the relevant officer immediately after the completion of a contract, and shall receive transfer of the details and maintenance work for the software covered by the maintenance contract from designers/developers. ・ The contractor shall develop a maintenance framework and a maintenance plan, based on the transfer concerning maintenance. (Prepared by procurer) Matters to be described in specifications Example/explanation of a description in specifications Notes on characteristics of a project/information system Notes on security - - 398 2. Formulation of application maintenance plan Item Outline of service operations Suggested input (Prepared by the procurer) Product (Prepared by the contractor) Matters to be described in specifications Example/explanation of a description in specifications Description To formulate application maintenance plans (including maintenance work plans and organizational charts with non-emergency/emergency contact lists, etc.) ・Maintenance outline ・Maintenance procedures ・Service level management index (draft) ・Table of the division of roles (contractors involved in the relevant systems and the procurers) ・Implementation plan, etc. To specify requirements for the formulation of maintenance plans [1. Basic requirements to be listed] ・Details of work to be included in the plan (organization, progress management, quality management, issue management, change management and configuration management, etc.) and division of the roles of the contractor (application maintenance contractor) [2. Requirements to be added depending on type/characteristics of project] ・<In the case of a multiple-year contract> Requirements concerning a revision of the work plan in each fiscal year (for example, a change in the plan in accordance with the attainment status of requirements, such as SLA, etc.) ・<In the case of application maintenance that requires specific skills or experience> Requirements for the framework of the contractor, such as qualifications and experience required for workers, etc. Examples of descriptions in specifications (1) The contractor shall create and deliver a maintenance plan, based on the “relevant procurement specifications,” as well as the “maintenance design” and “maintenance procedures” (issued separately), etc., and receive the approval of the supervisory section. (2) The maintenance work plan shall give sufficient consideration not to interfere with business, such as avoidance of system (service) shutdowns. Any work that may have an impact on business may be done on holidays, etc. through schedule coordination. (3) The contractor shall establish a framework that enables a rapid maintenance response during regular maintenance hours in preparation for faults of devices covered by the maintenance contract and/or response to requests made from the supervisory section, and shall gain the understanding of the supervisory section. Maintenance staff shall be engineers with sufficient knowledge and experience on the application software products covered by the maintenance and 399 Item Notes on characteristics of a project/information system Notes on security Description the entire system covered by that maintenance, including the relevant application systems. Specific requirements for key personnel should be described in detail in the case of a project requiring specific experience and skills: for instance, experience in maintenance/experience in design/development of the relevant system or other similar systems. With respect to maintenance work and fault support, clarification should be made regarding the division of roles and the scope of responsibility of the operator, hardware maintenance contractor, application maintenance contractor, concerned companies of related systems, and other concerned companies. With respect to the configuration management of the entire system, clarification should be made regarding the division of roles, the scope of responsibility and the procedures of configuration management of the operators in charge of the configuration management of the entire system. - 400 3. Service level management Item Outline of service operations Suggested input (Prepared by the procurer) Product (Prepared by the contractor) Matters to be described in specifications Description To conclude an SLA, measure performance concerning the service level management index, and review of non-attained SLA tasks, etc. At the time of procurement, a full discussion should be held to decide whether the application of an SLA is necessary because the service level management does not need to be applied to all projects. ・Service level management index (draft) ・Service level management plan ・Service level report [1. Basic requirements to be listed] None [2. Requirements to be added depending on type/characteristics of project] To include requirements for the SLA to be concluded between the procurer and the contractor and state to the effect that both parties may discuss issues about the service level management index. When demanding strict compliance with an SLA, periodical reviews and task requirements for non-compliance should be described. ・Implementation of discussions on service level management index between ministries and the maintenance contractor ・Definition and explanatory notes on SLA items ・Concept of the amount of payment and penalty ・Implementation of periodical reviews on SLA compliance ・Responsive requirements for non-compliance to SLA (free response and approaches to improvements) Example/explanation Example of a description in specifications of a description in [2. Requirements to be added depending on type/characteristics of specifications project] (1) In this procurement, the contractor shall conclude the Service Level Agreement (SLA) upon consultation with the procurer, shall formulate the SLA plan that will contribute to the maintenance and improvement of service level, based on the service level management index described in this specifications document, in order to ensure that the quality of maintenance provided by the contractor is kept high, and shall present it in the form of a written proposal. No Service level Explanation management index 1 Modification of Whether response had been application completed within a month after an software application defect had been detected 401 Item Description 2 Security maintenance Whether the preliminary evaluation and application to the operational environment have been completed within a month after the release of patches, such as the operating system (OS) of the system equipped with the application software covered by the maintenance contract and middleware, etc. (2) The contractor shall measure the performance status of each service level management index on a monthly basis, based on the SLA concluded with the supervisory section, and shall report the attainment status at the service level briefing session to be held every three months. (3) Based on the report on the service level attainment status from the contractor, the contractor and the supervisory section shall hold discussions to assess the attainment level of the SLA during the relevant period. The payment of the fee for the commissioned business shall be determined in accordance with the attainment level of the SLA. If the unattained SLA items accounts for less than 90%, the contractor shall make a proposal for improvements under its own responsibility, and implement the measures upon receiving approval from the supervisory section. Attainment Percentage Conditions Level of payment 100% (full Attained prescribed conditions in all A amount) SLA items The number of unattained SLA items 97% accounts for less than 5% of all SLA B items. The number of unattained SLA items 94% accounts for more than 5% and less C than 10% of all SLA items. The number of unattained SLA items 90% accounts for more than 10% of all SLA D items. Notes on characteristics of a project/information system Notes on security In the case of a multiple-year application maintenance project, more frequent assessment on the service level attainment shall be conducted, for example on a quarterly basis. Incessant efforts should be made for quality improvements, including reorganization in the cases where its attainment is insufficient. - 402 4. Fault support Item Outline of service operations Description To conduct on-site support for the escalation from the supervisory section or operator. Suggested input (Prepared by the procurer) Product (Prepared by the contractor) Matters to be described in specifications ・Maintenance designs ・Maintenance procedures ・Operation manual for hardware/software and attached documents ・Fault report Example/explanation of a description in specifications Notes on characteristics of a project/information system Notes on security In some cases, time spent on the investigation of causes, time spent until fault support and the success rate of cause investigation shall be included as service level management indexes. [1. Basic requirements to be listed] ・Implication of fault support ・Response time of fault support Examples of descriptions in specifications [1. Basic requirements to be listed] (1) Based on the primary separation by the operator, the contractor shall analyze fault causes on application software covered by the maintenance contract, consider solutions or countermeasures against problems and implement the countermeasures upon consultation with the supervisory section. (2) If the operator cannot identify the cause of a fault in the primary separation, the contractor shall provide support for the identification of the cause and temporary recovery in cooperation with the hardware maintenance contractor, software maintenance contractor and operation contractor, in accordance with the instructions from the supervisory section. (3) Response hours of fault support shall be 9:00 to 18:00 on weekdays (excluding holidays and national holidays). However, response outside of working hours shall be considered upon consultation with the supervisory section. - - 403 5. Program modification Item Outline of service operations Suggested input (Prepared by the procurer) Product (Prepared by the contractor) Matters to be described in specifications Description Partial modification of a program, function addition, development for bug fixing, tests, releases into the production environment, patch applications, analysis of the impact of patch applications on the system Procedures (maintenance procedures, operation procedures) Design documents (maintenance design, operation design, system design, program design, database design, screen/form design, operation design, migration design, hardware design, etc.) Source code, etc. Project standards Test standards Coding regulations Change requirements for applications covered by the maintenance contract [Revised version] Procedures (maintenance procedures, operation procedures) [Revised version] Design documents (maintenance design, operation design, system design, program design, database design, screen/form design, operation design, migration design, hardware design, etc.) [Revised version] Source code, etc. Program files Test specifications (specifications for unit tests, integration tests, system tests, acceptance tests) Report on test results Release plans Release procedures Report on the results of release work [1. Basic requirements to be listed] ・Modification of application software in response to problems detected after the commencement of operation ・Patch applicability assessment for the maintenance of application software generated after the commencement of operation ・Partial and slight improvement of application software and function addition associated with system change, etc. (including incidental tasks, such as revision of design documents, program modification, tests and, migration) [2. Requirements to be added depending on type/characteristics of project] ・Modification of application software in order to respond to performance problems originating in the application software 404 Item Example/explanation of a description in specifications Notes on characteristics of a project/information system Description Example of a description in specifications [1. Basic requirements to be listed] (1) The contractor shall implement modification of defects in application software covered by the maintenance contract based on the incident management document issued by the supervisory section or operations management contractor, in accordance with the design/development process of this system. However, this shall not apply to the warranty period of the designers/developers. (2) The contractor shall implement light function addition/modification described in the appendix of the specifications, in accordance with the design/development process of this system. (3) When a patch file is released for an operating system (OS) and middleware used for the system in which application software covered by the maintenance contract is installed, the contractor shall implement a preliminary evaluation of the application within one month after the release of the relevant patch file. The preliminary evaluation shall be carried out under the maintenance environment controlled by the supervisory section and the result of the preliminary evaluation and path application procedures shall be promptly presented to the supervisory section in written form. [2. Requirements to be added depending on type/characteristics of project] (4) Application of patch files, such as an evaluated operating system (OS) and middleware, into the operation environment shall be promptly carried out in accordance with the design/development process of the relevant system, upon consultation with the supervisory section. Defects of applications may take a long time to be corrected after the need for correction was found due to various reasons (difficulty in finding causes, wide range of correction needs, impact on other systems, etc.). Therefore, there is an option to specify in the specifications that a service requirement is limited to “formulate an application modification plan upon consultation with relevant personnel when application defects are found,” instead of including the implementation of modifications as a requirement. The implementer of a “patch application for evaluated software” is different depending on the application subject. For instance, application of evaluated patch files for servers (for example, departmental file server) not equipped with PCs or business systems shall be carried out by the operator. On the other hand, the service for servers equipped with the business system shall be carried out by the application maintenance contractor. Notes on security - 405 6. Technical support Item Outline of service operations Description ・To implement technical support in response to requests made by the supervisory section or operator. Suggested input (Prepared by the procurer) Product (Prepared by the contractor) Matters to be described in specifications ・Design documents and maintenance procedures of systems covered by the maintenance contract Example/explanation of a description in specifications Notes on characteristics of a project/information system Notes on security ・Report on the implementation of support tasks [1. Basic requirements to be listed] ・Response to inquiries ・Support for separating problems ・Dispatch of engineers when necessary (on-site support ) [2. Requirements to be added depending on type/characteristics of project] ・Preliminary evaluation/impact analysis of patch application in OS/middleware, etc. ・Application of evaluated patch, etc. Example of a description in specifications (1) The contractor shall implement additions/changes to the system in which is running the application software covered by the maintenance contract, such as revision of the system environment in which addition and change have become necessary after the commencement of operation, additions/changes of parameter, etc., revision/change of data base definitions, and the addition/change of exceptional characters/system codes, etc. Information provision and application of patches To immediately provide ministries with information pertaining to technical problems involved in the information system, security vulnerabilities (security holes), software bugs, patches and version upgrades, etc. To provide services, such as verification of patch applications and patch application tasks, and technical advice on software when requested by ministries - 406 6.6.3.3. Deliverable products and timing of submission The table below lists typical deliverable products and timing of delivery with respect to application maintenance services. The official name of each product and its delivery deadline need to be entered in accordance with the actual situation. Service 1. Transfer from design/development contractor 2. Formulation of maintenance plan 3.Service level management Deliverable product Transfer implementation report Delivery deadline Within one week after the completion of transfer Implementation plan Within two weeks after the conclusion of contract Within 14 business days after the conclusion of contract SLA Service level management plan 4.Fault support Report on the results of service level management Fault report On the designated date, every time service level is measured Fault support Within one week after the completion of fault support 5.Program modification Work implementation plan Fourteen days prior to the commencement of work On an as needed basis (within 14 days after the completion of the release or at the time of collating) [Revised version] Procedures (maintenance procedures, operation procedures) [Revised version] design documents (maintenance design, operation design, system design, program design, database design, screen/form design, operation design, migration design, hardware design, etc.) [Revised version] Source code, etc. Program files Test specifications (various specifications, including unit test, integration test, system test, acceptance test) Report on test results Release plan Release procedures Report on release results 6.Technical support Report on support work implementation Within one week after the completion of work 407 6.6.3.4. Suggested input The following table shows input and timing to be presented to the procurer (proposer) in advance. The official name of each product and its delivery deadline should be entered in accordance with the actual situation. Service 1. Transfer from design/development contractors 2. Formulation of maintenance plan 3.Service level management 4.Fault support 5.Program modification 6.Technical support Input Maintenance plan (draft), maintenance design, maintenance procedures, maintenance tools, transfer implementation plan (draft) Maintenance plan (draft) SLA (draft) Service level management index (draft) Table of the division of roles (SOW) (Statement of Work) Maintenance procedures Operation procedures Design documents (maintenance designs, operation designs, system designs, program designs, database designs, screen/form designs, operation designs, migration designs, hardware designs, system environment definitions, etc.) SLA (draft) Service level management index (draft) Maintenance procedures Operation procedures Design documents (maintenance designs, operation designs, system designs, program designs, database designs, screen/form designs, operation designs, migration designs, hardware designs, system environment definitions, etc.) Source code Maintenance procedures Operation procedures Design documents (maintenance designs, operation designs, system designs, program designs, database designs, screen/form designs, operation designs, migration designs, hardware designs, system environment definitions, etc.) Source code Maintenance procedures Operation procedures Design documents (maintenance designs, operation designs, system designs, program designs, database designs, screen/form designs, operation designs, migration designs, hardware designs, system environment definitions, etc.) Source code Information indicating the volume of maintenance work 408 Timing of presenting input At the time of transfer from the designers/developers Included in procurement specifications or as an attachment During tender period: Disclosed to bidders After conclusion of an agreement: Lent to contractor Included in procurement specifications or as an attachment During tender period: Disclosed to bidders After conclusion of an agreement: Lent to contractor During tender period: Disclosed to bidders After conclusion of an agreement: Lent to contractor During tender period: Disclosed to bidders After conclusion of an agreement: Lent to contractor 6.6.3.5. Division of roles In separated/breakout procurement, the division of roles among procured services, related procurement and the relevant procurement should be clarified in accordance with the scope of separated orders and the ministerial policies and presented at the time of tender publishing. When considering procurement, services to be realized in the entire procurement should be identified. A clear division of roles and services should be specified, and a table of division of roles should be compiled so that concerned parties can agree that there are no omissions/errors in the services/roles in breakout procurement. ○: Main personnel in charge, △: Support, advice Supervisory section Tasks Planning and procurement of operation maintenance plan for hardware, packaged software and network, etc. On-site support for hardware Provision of packaged software in batches and implementation of off-site support On-site support for networks ○ HW maintenance contractor △ SW maintenance contractor AP maintenance contractor iDC contractor Helpdesk contractor △ △ △ - △ △ - △ - △ - ○ - - - - ○ - - Operation contractor △ ○ △ - △ - - - - - - Daily system operation System and network monitoring Security monitoring - - - - ○ - - - - ○ - - - - ○ △ Handling inquiries from users Response to inquiries from the supervisory section and escalation from the joint Helpdesk Primary separation in the event of problems Secondary response to the problem (hardware fault) Secondary response to the problem (software/application software fault) Secondary response to the problem (iDC equipment fault) System recovery process in the event of a fault Maintenance of application software Collection, analysis, reporting, suggestions concerning operation management information Expendables management ○ - - - - - ○ - ○ ○ ○ ○ ○ ○ △ △ △ ○ △ △ △ - ○ △ △ - △ △ △ ○ △ △ - △ △ △ △ ○ - △ △ ○ - - △ - - ○ - - - △ △ - △ ○ △ - △ - △ - △ - - ○ - ○ - Table 6.6.3.5.1 Division of roles among operation and maintenance contractor (example) 409 - 6.6.4. Maintenance of system infrastructure 6.6.4.1. Definition of procurement areas Maintenance of system infrastructure is the maintenance services for technologies included in “Chapter V: Explanations on Technical Domain” of the technical reference model, such as “EIP,” “open web server,” “groupware, file server, mail server,” “integrated account management/authentication/authorization (access control),” “integrated directory,” “WAN/ministerial LAN, DNS/DHCP/Proxy, remote access,” and “network lines.” There are cases where procurement of these maintenance services is made under the same contract as the installation of devices, introduction of setup devices and development of the environment. However, this section describes only the services related to maintenance. Planning phase Requirements definition 要件定義 phase Operation/maintenance 運用・保守フェーズ phase Development phase 開発フェーズ 6.2 6.2.3 Support for ( 等) procurement (Project management, etc.) 6.3 6.4 運用 6.4 Operation 6.5 Helpdesk 6.1 Support 6.1全体計画 for master 策定支援 plan formulation 6.2.2 Support for procurement 6.2 1 調達支援 (requirements ( 等) definition, etc.) 6.3 System integration (design/development) 6.3 ハードウェア更改 6.3 機能追加 6.6 Maintenance 6.7 Tasks incidental to procurement of devices Hardware maintenance Software maintenance Application maintenance System infrastructure maintenance 6.8 Tasks incidental to procurement of iDC equipment ・ 設備) 6.9 Network procurement 6.12 Security Figure 6.6.4-1 Items corresponding to the classification of procurement of services 410 6.6.4.2. Services to be listed in specifications 6.6.4.2.1. Typical service operations The following table shows services to be included in the specifications. The corresponding SLCP-2007 activities are also given. For actual procurement, correspondence to SLCP activities should be examined so as not to omit necessary information. To write specification, a draft for procurement specifications should be prepared by selecting appropriate items, while coordinating with the corresponding Program Management Office (PMO). [Maintenance of system infrastructure] Service operations Outline of service operations SLCP-2007 activity 1. Transfer from designers/developers Transfer from designers/developers 1.8.1.1 Transfer from development process 2.Formulation of maintenance plan Formulation of maintenance plans for system infrastructure (including a maintenance work plan and organizational charts with non-emergency/emergency contact lists, etc.) Concluding SLA, recording SLA index and improving non-attained SLA items 1.8.1 Preparation for process initiation (maintenance process) 4.Fault support Provision of fault support in cooperation with the hardware maintenance contractor, software maintenance contractor and operator to resolve a system fault which cannot be solved by the operator 5.Updating basic software Software maintenance tasks necessary for the sustainable provision of services 6.Technical support Each task of system engineers necessary for system operation 1.8.2 Problem identification and modification analysis 1.8.3 Implementation of modification 1.8.4 Maintenance review and acceptance 1.8.2 Problem identification and modification analysis 1.8.3 Implementation of modification 1.8.4 Maintenance review and acceptance 1.8.3 Implementation of modification 1.8.4 Maintenance review and acceptance 3.Service level management - 411 Chapter/section corresponding to Basic Guidelines for Procurement Chapter XI Requirements for maintenance (however, not applicable to either (1) or (2)) 6.6.4.2.2. Explanations and examples of descriptions in specifications concerning services 1. Transfer from designers/developers Item Outline of service operations Description Transfer from design/development contractor Suggested input (Prepared by the procurer) [Products related to operation/maintenance created by the design/development contractor] ・ Maintenance plan (draft) ・ Maintenance design ・ Maintenance procedures ・ Maintenance tools ・ Transfer implementation plan ・ Transfer implementation report ・ Maintenance plan ・ Organizational chart [1. Basic requirements to be listed] ・ Creation of the transfer implementation report ・ Implementing transfer from the design/development contractor prior to the full operation of the new system ・ Making inquiries and requests for modification to the designers/developers, if questions arise about maintenance plans/maintenance procedures, etc. Creating maintenance procedures, based on the documents concerning the creation of maintenance procedures ○Transfer to the maintenance contractor ・ The contractor shall consult with the relevant officer immediately after the conclusion of the contract and shall receive the transfer of details of the system infrastructure covered by the maintenance contract and the maintenance works from the designers/developers by the end of (M/FY) at the contractor’s expense and responsibility. ・ Based on the transfer of materials concerning maintenance, the contractor shall develop a maintenance framework and create a maintenance plan. Product (Prepared by the contractor) Matters to be described in specifications Example/explanation of a description in specifications Notes on characteristics of project/information system Notes on security - - 412 2. Formulation of maintenance plans for system infrastructure Item Outline of service operations Suggested input (Prepared by the procurer) Product (Prepared by the contractor) Matters to be described in specifications Example/explanation of a description in specifications Notes on characteristics of project/information system Notes on security Description Submit the maintenance plan for system infrastructure (including a maintenance work plan and an organizational chart with a non-emergency/emergency contact list, etc.) to the supervisory section and gain the approval of the supervisory section [1.Input to be basically presented] ・Maintenance outlines ・Maintenance procedures ・Table of division of roles (companies related to the relevant system and the procurer) [2. Additional input necessary for presentation due to the type/characteristics of projects] ・Service level management index (draft) ・Maintenance plan for system infrastructure To state required items concerning the formulation of the maintenance plan [1. Basic requirements to be listed] To create and deliver the “maintenance plan” and gain the approval of the procurer in advance ・Detailed definition of the procedures of business implementation ・Formulation of the plan for organization, division of roles and communications methods Example of a description in specifications (1) The contractor shall create/deliver a maintenance plan for regular maintenance and system maintenance works, based on “these procurement specifications” and the separately issued “maintenance design” and “maintenance procedures,” and gain the approval of the supervisory section. (2) The maintenance work plan shall give sufficient consideration not to interfere with business, such as the avoidance of system (service) shutdowns. Any work that may have impact on business may be done on holidays, etc. through schedule coordination. (3) The contractor shall establish a framework that enables a rapid maintenance response during regular maintenance hours in preparation for a device fault covered by the maintenance contract and/or response to requests made from the supervisory section, and shall gain the understanding of the supervisory section. The division of roles among concerned business entities should be clearly specified, such as operators and business entities of related systems as well as the scope of responsibility of each business entity. - 413 3. Service level management Item Outline of service operations Suggested input (Prepared by the procurer) Product (Prepared by the contractor) Matters to be described in specifications Description Concluding an SLA, reporting service level and implementation of approaches to improvements, etc. Careful discussions shall be held to decide whether the application of an SLA is necessary because service level management does not need to be applied to all projects. ・Service level management index (draft) ・SLA (draft) ・SLA ・Maintenance report ・Service level report [1. Basic requirements to be listed] None [2. Requirements to be added depending on type/characteristics of project] To include requirements for SLA to be concluded between the procurer and the contractor and state to the effect that both parties may discuss issues about the service level management index. When demanding strict compliance with the SLA, periodical reviews and task requirements for non-compliance shall be specified. ・Implementation of discussions on the service level management index between ministries and the maintenance contractor ・Definition and explanatory notes on SLA items, such as frequency of version upgrades and fault support hours ・ Implementing periodical reviews on the results of compliance with the SLA ・Requirements for responses in the event of non-compliance with the SAL (for free response and approaches to improvements) 414 Item Example/explanation of a description in specifications Description Examples of descriptions in specifications [2. Requirements to be added depending on type/characteristics of project] (1) In this procurement, the contractor shall conclude the Service Level Agreement (SLA) upon consultation with the procurer, shall formulate an SLA plan that will contribute to the maintenance and improvement of service level, based on the service level management index described in this specifications document, in order to ensure that the quality of maintenance provided by the contractor is kept high, and shall present it in the form of a written proposal. No 1 2 Service level management index Modification of application software Security maintenance Explanation Whether countermeasures have been completed within a month after the application defect had been detected Whether the preliminary evaluation and application to the operational environment have been completed within a month after the release of patches, such as an operating system (OS) equipped with application software covered by maintenance contract and middleware, etc. (2) The contractor shall measure the performance status of each service level management index on a monthly basis, based on the SLA concluded with the supervisory section and shall report the attainment status at the service level briefing session to be held every three months. (3) Based on the report on the service level attainment status from the contractor, the contractor and the supervisory section shall hold discussions to assess the attainment level of the SLA during the relevant period. The payment of the fee for the commissioned business shall be determined in accordance with the attainment level of the SLA. If the unattained SLA items accounts for less than 90%, the contractor shall make a proposal for improvements under its responsibility, and implement the measures upon receiving approval from the supervisory section. 415 Item Description Attainment level A Percentage of payment 100%(full amount) 97% B 94% C 90% D Notes on characteristics of project/information system Notes on security Conditions Attained prescribed conditions in all SLA items The number of unattained SLA items accounts for less than 5% of all SLA items. The number of unattained SLA items accounts for more than 5% and less than 10% of all SLA items. The number of unattained SLA items accounts for more than 10% of all SLA items. - - 416 4. Fault support Item Outline of service operations Description To conduct on-site support for the escalation cases from the supervisory section or operator. Suggested input (Prepared by the procurer) ・Maintenance designs ・Maintenance procedures ・Operation manual for hardware/software and attached documents Product (Prepared by the contractor) Matters to be described in specifications ・Fault report Example/explanation of a description in specifications Notes on characteristics of project/information system Notes on security In some cases, time spent on cause investigation, time spent until fault support and success rate of cause investigation shall be included as service level management indexes. [1. Basic requirements to be listed] ・Implication of fault support ・Response time of fault support Examples of descriptions in specifications [1. Basic requirements to be listed] (1) Based on the primary separation done by the operator, the contractor shall analyze fault causes on application software covered by the maintenance contract, consider solutions or countermeasures against problems and implement the countermeasures upon consultation with the supervisory section. (2) If the cause of a fault cannot be identified in the primary separation by the operator, the contractor shall provide support for the identification of the cause and temporary recovery in cooperation with the hardware maintenance contractor, software maintenance contractor and operator, in accordance with the instructions issued by the supervisory section. (3) Response hours of fault support shall be 9:00 to 18:00 on weekdays (excluding holidays and national holidays). However, response outside of working hours shall be considered upon consultation with the supervisory section. If system continuity at the time of system failure is possible due to redundancy in the system, immediate countermeasures do not need to be carried out upon consultation with the relevant officer, which may be included in the maintenance specifications. - 417 5. Updating system infrastructure software Item Outline of service operations Suggested input (Prepared by the procurer) Product (Prepared by the contractor) Matters to be described in specifications Example/explanation of a description in specifications Description To update system infrastructure software and perform patch applications for function improvements and countermeasures against defects and vulnerabilities of the system infrastructure software etc. Procedures (maintenance procedures, operation procedures) Design documents (maintenance design, operation design, system design, program design, database design, screen/form design, operation design, migration design, hardware design, etc.), Source code, etc. [Revised version] Procedures (maintenance procedures, operation procedures) [Revised version] Design documents (maintenance design, operation design, system design, program design, database design, screen/form design, operation design, migration design, hardware design, etc.), [Revised version] Source code, etc., Program files, Testing specifications, Report on test results, Release plan, Release procedures, Report on the results of the release, etc. [1. Basic requirements to be listed] ・Implementation of preliminary evaluation in a maintenance environment ・Operation verification of related systems/software ・Revision of design/procedures documents, etc. ・Implementation of configuration management Example of a description in specifications [1. Basic requirements to be listed] (1) The contractor shall update system infrastructure software based on defect information, vulnerability information and incidence management slips presented by the supervisory section concerning the system infrastructure and its software covered by maintenance contract. Before implementing the update operations, the contractor shall perform preliminary evaluations in a maintenance environment and gain approval from the supervisory section. (2) At the time of update verification, the contractor shall carry out the operation verification for systems/software that will operate on the system infrastructure or in coordination with the system infrastructure. (3) When implementing update operations, the contractor shall use the revised design/procedures, in accordance with the configuration management process of this project. Notes on characteristics of 418 Item project/information system Notes on security Description Provision of information and application of security patches Information pertaining to technical problems, security holes, software bugs, patches, and version upgrades of the information system shall be immediately reported to ministries. The contractor shall also carry out such works as application verification work, patch application, and provision of technical advice on software, in response to requests from ministries. 419 6. Technical support Item Outline of service operations Suggested input (Prepared by the procurer) Product (Prepared by the contractor) Matters to be described in specifications Example/explanation of a description in specifications Description ・Preliminary evaluation associated with patch application, patch application to operational environments, slight changes not requiring source code change, impact analysis associated with the modification of external systems and networks, etc. ・Design documents for systems covered by the maintenance contract and maintenance procedures [Revised version] Source code, etc., program files, test specifications, test results, release plans, release procedures, reports on the results of release works [1. Basic requirements to be listed] ・Slight changes not requiring source code changes ・Impact analysis associated with the modification of external systems and networks, etc. (1) EIP ・Database maintenance, such as deletion/creation of database tables, data import, etc. ・Maintenance of fonts of exceptional characters (2) Open web server ・Replacing the certificate when the server-certificate has been expired ・Review of server security settings based on information of vulnerability, etc. (3) Groupware, file servers, mail servers ・Registration, renewal, deletion of user accounts (4) Management, authentication, authorization (access control) ・Registration, renewal, deletion of user accounts (5) Integrated directory ・Registration, renewal, deletion of user accounts (6) WAN/ministerial LAN, DNS/DHCP/Proxy, remote access ・Registration, renewal, deletion on DNS servers Example of a description in specifications [1. Basic requirements to be listed] When security patches and updates concerning the OS and middleware, on which the system infrastructure software covered by maintenance contract is operated become available, the contractor shall consider the necessity of its application. When the application is deemed to be necessary, the contract shall conduct a preliminary evaluation under the maintenance environment to ascertain that patch application will not cause defects, and then carry out the application to the operation environment upon reporting to the supervisory section. 420 Item Description [2. Requirements to be added depending on type/characteristics of project] [Matters associated with EIP] The contractor shall register the applications requested by the supervisory section so that the application can be integrated into the portal. The contractor shall implement maintenance works on data to be registered in the EIP. [Matters associated with open web servers] ・ Carrying out regular reviews on security settings so as to keep the security level of the open web server high, by occasionally checking on vulnerability information, etc. [Matters associated with groupware, file servers, mail servers] ・ Appropriately carrying out authority settings for groupware, file servers and mail servers associated with the hiring, leaving and changing of employees, etc. [Maters associated with integrated account management, authentication, and authorization (access control)] ・ Appropriately carrying out the addition, change, and deletion of user accounts associated with the hiring, leaving and changing of employees, etc. [Matters associated with the integration directory] ・ Solidly carrying out integration directory settings associated with the addition, change, and deletion of ministerial systems [Matters associated with WAN/ministerial LAN, DNS/SHCP/Proxy, remote access] ・ Carrying out changes in settings of the WAN/ministerial LAN, DNS/DHCP/Proxy, etc. associated with the addition, renewal or abolition of ministerial systems. Notes on characteristics of project/information system Notes on security - 421 6.6.4.3. Deliverable products and timing of submission The table below lists typical deliverable products and their timing of delivery with respect to maintenance services for system infrastructure. The official name of each product and its delivery deadline need to be entered in accordance with the actual situation. Service 1. Transfer from design/development contractor 2. Formulation of maintenance plan Deliverable product Transfer report Delivery deadline Within one week after the completion of transfer Maintenance implementation plan Within two weeks from the conclusion of a contract 3.Service level management SLA Service level management plan Report on the results of service level management Maintenance report Service level report (*Fault support, in the cases where fault support is included in the SLA) Within 14 business days after the conclusion of a contract On the designated date at every measurement of the service level Maintenance report: Monthly Service level report: At the time of collating or quarterly Work implementation plan At least 14 business days before the implementation of work On an as needs basis (within 14 days after the completion of the release or at the time of collating) 4.Fault support 5. Updating system infrastructure software [Revised version] Procedures (Maintenance procedures, Operation procedures). [Revised version] Design documents (maintenance design, operation design, system design, program design, database design, screen/form design, operation design, migration design, hardware design, etc.) [Revised version] Source code, etc., program files, test specifications, report of test results, release plan, release procedures, report on results on release works 6.Technical support Work implementation plan [Revised version] Sources code, etc., program files, test specifications (specifications of various tests, such as unit test, integration test, system test and acceptance test) report on test results, release plan, release procedures, report on results of release work 422 At least 14 business days before the implementation of work Within seven business days after the implementation of work 6.6.4.4. Suggested input The following table shows input and timing to be presented to the procurer (proposer) in advance. The official name of each product and its delivery deadline need to be entered in accordance with the actual situation. Service 1. Transfer from design/ development contractor 2. Formulation of maintenance plan 3.Service level management 4.Fault support 5.Update of system infrastructure software 6.Technical support Input Maintenance plan (draft), Maintenance design, Maintenance procedures, Maintenance tools, Transfer implementation plan (draft) Maintenance plan (draft) SLA (draft) Service level management index (draft) Statement of work Maintenance procedures Operation procedures Design documents (maintenance design, operation design, system design, program design, database design, screen/form design, operation design, migration design, hardware design, etc.) SLA (draft) Service level management index (draft) Maintenance procedures Operation procedures Design documents (maintenance design, operation design, system design, program design, database design, screen/form design, operation design, migration design, hardware design, definition of system environment, etc.) Source code Maintenance procedures Operation procedures Design documents (maintenance design, operation design, system design, program design, database design, screen/form design, operation design, migration design, hardware design, definition of system environment, etc.) Source code Maintenance procedures Operation procedures Design documents (maintenance design, operation design, system design, program design, database design, screen/form design, operation design, migration design, hardware design, etc.) Information indicating the volume of maintenance work Source code, etc. 423 Timing for presenting input At the time of implementation of transfer from designers/developers Included in procurement specifications or as an attachment During tender period: Disclosed to bidders After conclusion of an agreement: Lent to contractor agreement. Included in procurement specifications or as attachment During tender period: Disclosed to bidders After conclusion of agreement: Lent to contractor During tender period: Disclosed to bidders After conclusion of an agreement: Lent to contractor During tender period: Disclosed to bidders After conclusion of an agreement: Lent to contractor 6.6.4.5. Division of roles In separated/breakout procurement, the division of roles among procured services, related procurement and the relevant procurement should be clarified in accordance with the scope of separated orders and the ministerial policies and presented at the time of tender publishing. When considering procurement, services to be realized in the entire procurement should be identified. A clear division of roles and services should be specified, and a table of division of roles should be compiled so that concerned parties can agree that there are no omissions/errors in the services/roles in breakout procurement. ○: Main operator, △: Support, advice Supervisory section Tasks Plan and procurement of operation maintenance plan for hardware, packaged software and network, etc. On-site support for hardware Provision of packaged software in batches and implementation of off-site support On-site support for networks Daily system operation System and network monitoring Security monitoring Handling inquiries from users Response to inquiries from the supervisory section and escalation from the joint Helpdesk Primary separation in the event of problems Secondary response to problem (hardware fault) Secondary solutions in the event of problems (software/application software fault) Secondary response to the problem (iDC equipment fault) System recovery process in the event of a fault Maintenance of application software Collection, analysis, report, suggestions concerning operation management information Expendables management HW maintenance contractor ○ △ - ○ - SW maintenance contractor AP maintenance contractor Operation contractor iDC contractor Helpdesk contractor △ △ △ - - - △ △ - - ○ - △ △ - - - - - ○ - - - - - ○ △ - - - - ○ - - - - - ○ △ ○ - - - - ○ ○ △ △ △ - - - △ - ○ ○ ○ ○ ○ △ ○ △ △ △ - ○ △ △ - △ △ △ ○ △ △ - △ △ △ △ ○ - △ △ ○ - - △ - - ○ - - - △ △ - △ ○ △ - - - - - ○ - - △ △ △ - ○ Table 6.6.4.5.1 Division of roles among operation and maintenance contractor (example) 424 6.7. Tasks incidental to procurement of devices 6.7.1. Definition of procurement area The term “tasks incidental to procurement of devices” refers to services incidental to devices (including ready-made software for OSs inseparable from hardware) that are necessary to implement information systems (see Figure 6.7.1.). There are cases where procurement of the subsequent maintenance services is made under the same contract in addition to the installation of devices such as deployment and setting, and arrangement of the environment. However, this section describes only the services related to installation. Planning phase Requirements definition 要件定義 phase Operation/maintenance 運用・保守フェーズ phase Development phase 開発フェーズ 6.2 6.2.3 Support for ( 等) procurement (Project management, etc.) 6.3 6.4 運用 6.4 Operation 6.5 Helpdesk 6.1 Support 6.1全体計画 for master 策定支援 plan formulation 6.2.2 Support for procurement 6.2 1 調達支援 (requirements ( 等) definition, etc.) 6.3 System construction (design/development) 6.3 ハードウェア更改 6.3 機能追加 6.6 Maintenance 6.7 Tasks incidental to procurement of devices Hardware maintenance Software maintenance Application maintenance System infrastructure maintenance 6.8 Tasks incidental to procurement of iDC equipment ・ 設備) 6.9 Network procurement 6.12 Security Figure 6.7-1 Items corresponding to the classification of procurement of services 6.7.2. Services to be listed in specifications 6.7.2.1. Typical service operations The following table shows services to be included in the specifications. The corresponding SLCP-2007 11 activities are also given. For actual procurement, correspondence to SLCP activities should be examined so as not to omit necessary information. Items corresponding to the Basic 11 Software Life Cycle Processes-Japan Common Frame-2007 (SLCP-JCF 2007), Information-technology Promotion Agency, Japan (in Japanese) 425 Guidelines on Procurement (BGP) 12 are also listed. To write specifications, a draft of procurement specifications should be prepared by selecting appropriate items while coordinating with the corresponding Program Management Office (PMO). Service operations 1.Master plan formulation 2.Prior explanation/coordination with concerned parties 3.On-site investigation/design 4.Device installation 5.Device setup 6.Operation verification/test 7.Migration 8.Information provision to Outline of service operations Activities of SLCP-2007 Formulation of work details, schedule, process, implementation framework (division of roles), Creation of implementation plan Progress management, reviews to the persons in charge Prior explanation to and coordination with concerned contractors and ministries 1.2.4: Planning 1.2.5: Implementation and management 1.2.6: Review and assessment On-site investigation of the site where devices are to be installed Creation of on-site investigation report and working drawing Creation of on-site work plan Creation and submission of diagrams such as device installation layout, rack layout, network diagram (if network is included), and design documents such as security design and network design documents Work on power source and ventilation Emplacement/installation of devices Network installation in accordance with the design document (if a network is included), Installation and setting up of software, and connection with other systems Carrying out verification tests on installed hardware, software and the network (if a network is included) Support for tests performed by system development contractors 3.2.2 Environment construction process 3.2.1 Preparation for process initiation(environment development process) Migration of data, system, and business from the existing system or support for that work Provision of information to 3.2.2: Environment construction process 3.2.2 Environment construction process 1.6.12 Software installation process 2.4.1 Preparation for process initiation 2.4.2 Validation, 2.5.1 Preparation for process initiation 2.5.2 Confirmation of validity 1.8.5 Migration 1.6.13 Chapter and section of specifications corresponding to BGP (and its title) Chapter XII Framework and method of work (1)Framework of work (3) Introduction Chapter XII Framework and method of work (3)Introduction Chapter XII Framework and method of work (3)Introduction Chapter XII Work framework and method (3)Introduction Chapter XII Work framework and method (3)Introduction Chapter VIII Definition of requirements for tests Chapter IX Definition of requirements for migration (1) Migration-related requirements Chapter IX 12 The “Basic Guidelines for Government Procurement Related to Information Systems”, March 2007, Ministry of Internal Affairs and Communications (in Japanese) http://www.soumu.go.jp/main_content/000070266.pdf 426 Service operations operation/maintenance contractors 9. Information provision and training to users 10. Acceptance Outline of service operations operation/maintenance contractors, such as setting information for devices and software, and operation procedures Training of system operation procedures for end users and persons in charge of the system (if end users use the system) Preparation/delivery of a set of the necessary deliverables Support for acceptance tests by ministries Activities of SLCP-2007 Software acceptance support 1.6.13 Software acceptance support 1.2.7 Delivery and completion 427 Chapter and section of specifications corresponding to BGP (and its title) Definition of requirements for migration (2) Education-related requirements Chapter IX Definition of requirements for migration (2) Education-related requirements Chapter XII Framework and method of work (3) Introduction 6.7.2.2. Explanations and examples of descriptions in specifications concerning services 1. Master plan formulation Item Outline of service operations Description Deliberation of the overall structure, including work details, schedule, work site, and roles, and formulation of the master plan Suggested input (Prepared by the procurer) ・ Overall schedule ・ Table of division of roles Product (Prepared by the contractor) Matters to be described in specifications ・ Master plan Example/explanation of a description in specifications Notes on characteristics of project/information system [1. Basic requirements to be listed] ・ Tasks to be included in the plan ・ Roles of persons in charge ・ Organizational structure ・ Designation and constraints concerning working hours, locations, etc. [2. Requirements to be added depending on type/characteristics of project] ・ Required qualifications for workers ・ Requirements for the contractors, such as job experience ・ Detailed rules regarding work hours/locations ・ If conditions differ among locations, such as work days and hours, work plans for locations shall be submitted accordingly. ○Creation of an implementation plan The contractor shall create an “implementation plan” that includes work descriptions, a framework and a schedule of work, etc., prior to the installation of devices. (1) Creation of an implementation plan ・ The “implementation plan” shall include all the operations listed in the “Table __. Division of roles in installation work.” ・ If coordination is necessary for the cooperation with external parties in creating the “implementation plan,” the contractor shall consult with the relevant Ministry. In addition, the contractor shall provide support for the necessary coordination. (2) Working hours The emplacement and installation should be within business hours on weekdays. ・ Some ministries require separate submission of introduction plans and organization charts. The specifications should state that such matters shall be done in accordance with the procurement policies/guidelines of the ministry. ・ When a project requires specific experience or skills, detailed requirements for the personnel in charge shall be stated. ・ In case that the installation is carried out at many places, the 428 specifications should state that the contractor shall submit a list of persons in charge at each location, contact information and the like, and a general guideline for operation carried out on site. Notes on security - 429 2. Prior explanation/coordination for concerned parties Item Outline of service operations Description To give prior explanation to concerned contractors and ministries and discuss matters to be coordinated beforehand. Suggested input (Prepared by the procurer) ・ Contact information of sites and concerned contractors ・ List of sites where the system is to be deployed ・ List of devices to be installed Product (Prepared by the contractor) Matters to be described in specifications ・ Documents for prior coordination/explanation and minutes (drafts in case of support) Example/explanation of a description in specifications Notes on characteristics of project/information system [1. Basic requirements to be listed] ・ Prior coordination shall be carried out. ・ Matters needs to be coordinated beforehand (the statements should be described in concrete terms.) ・ Concerned parties to participate in prior coordination (the expected number of participants shall be given.) [2. Requirements to be added depending on type/characteristics of project] ・ The contractor shall convene or participate in conferences such as a meeting for prior explanation, if required. ・ Participants and subjects of explanations of conferences such as a meeting for prior explanation shall be described. ○ Prerequisite operation prior to delivery (A) The contractor shall take part in on-site explanatory meeting prior to delivery to give details of deliverable devices, delivery schedule, and other necessary explanations. (B) The contractor shall identify matters to be consulted with persons in charge on site, such as installation locations of existing products and preparation of power supplies, etc. (C) The contractor shall conduct prior coordination on the matters mentioned in the previous clause. In case that terminals and the like are deployed at many places, there will be different contractors involved in the work at each workplace. Therefore, the procurer needs to mention concerned parties, for which coordination is needed, in the specifications. In case that devices procured in the previous fiscal year (reusable products) are to be used, the procurer should state that the contractor should cooperate with other contractors, such as those have deployed the terminals in the previous fiscal year, persons in charge on site and so forth. Notes on security - 430 3. On-site investigation/design Item Outline of service operations Suggested input (Prepared by the procurer) Product (Prepared by the contractor) Matters to be described in specifications Example/explanation of a description in specifications Notes on characteristics of project/information system Notes on security Description To implement on-site investigation at places where devices are to be deployed and to make working drawings after writing a report on on-site investigation ・ Security policies issued by the ministry ・ Standards for Information Security Measures for the Central Government Computer Systems ・ Design documents concerning the existing system, such as working diagrams, layout diagrams for device installation, rack installation diagrams, and wiring diagrams ・ On-site investigation plan ・ Report on on-site investigation ・ Design documents, such as working diagrams, layout diagrams for device installation, rack installation diagrams, and wiring diagrams [1. Basic requirements to be listed] ・ Selection of appropriate devices/software based on the requirements in the specifications ・ Necessary on-site investigations ・ Results of on-site investigations, design ・ Outputs, such as diagrams to be created ・ Implementation of on-site investigations and timing of the submission of outputs ・ Constraints on the implementation of on-site investigations [2. Requirements to be added depending on type/characteristics of project] ・ Definition of security requirements in conformity with the standard security policies of the central government, etc. ・ “Definition of security requirements/design” shall be included in the requirements if a design should be tailored. Example of a description in specifications (1) As for the location of installation, “layout diagram for device installation” and a “rack installation diagram” should be createdafter conducting studies, etc. (2) On-site investigations necessary for the installation of a power source and LAN cables shall be conducted. The on-site and other studies shall be conducted in accordance with the “system switching work plan” presented by the relevant authority to the relevant site. If connecting to systems operated by other ministries is necessary, the contractor shall state to the effect that the network design will be formulated upon coordination with the relevant bureau of said ministries. In that case, the concerned parties shall be clearly specified for the coordination.. Security design The contractor shall create a security design following the Standards for Information Security Measures for the Central Government Computer Systems and information security policies issued by each ministry. The contractor shall also take information security measures based on the security design. 431 4. Device installation work Item Outline of service operations Suggested input (Prepared by the procurer) Product (Prepared by the contractor) Matters to be described in specifications Example/explanation of a description in specifications Notes on characteristics of project/information system Notes on security Description To implement work on power source/ventilation work and emplacement/installation of devices ・ Working diagram, layout diagram for device installation, rack installation diagram, wiring diagram, and various other design documents concerning the existing system ・ Materials concerning power source usage ・ Change documents concerning the result of works, including the working diagram, layout diagram for device installation, rack installation diagram, wiring diagram, and various other design documents Requirements for emplacement and installation work shall be included. Conditions for emplacement and installation and requirements for necessary tasks shall be stated. A statement on the advisability and timing of system shutdown as prerequisites shall also be necessary. Responsibility boundary and necessity for curing of the emplacement and displacement may also be stated separately as prerequisites for work. [1. Basic requirements to be listed] ・ Works to be carried out in the installation of devices. ・ Prerequisites for installation [2. Requirements to be added depending on type/characteristics of project] ・ Specific conditions for the installation of devices ・ Working conditions ・ Physical connections of the network, such as LAN, etc. Example of a description in specifications 1. Details of device installation The contractor shall carry out the following works for the installation of devices. (1) Emplacement/installation A. Emplacement/installation work of procured devices B. Application for the emplacement/installation work of devices C. Necessary studies prior to the emplacement/installation of devices D. Arranging components necessary for the emplacement/installation E. Removal and disposal of the containers of devices, packing and protective materials used for emplacement, and other materials that have become unnecessary after the completion of installation F. Handling of damage caused by emplacement G. Appropriate anti-seismic work In the case of a large-scale separated procurement project, the responsibility demarcation for installation/connection of devices, etc. may become unclear. Thus, the responsibility should be clarified in advance by, for example, creating a table of the division of roles. - 432 5. Device setup Item Outline of service operations Suggested input (Prepared by the procurer) Product (Prepared by the contractor) Matters to be described in specifications Example/explanation of a description in specifications Notes on characteristics of project/information system Description To implement network settings, software installation and settings, and of device settings and other tasks necessary for the connection with other systems based on the prescribed design documents., thus making the device ready for use. ・ Requirements for hardware, requirements for software, requirements for networks and requirements for operation and maintenance ・ Definition of environment Requirements for settings and coordination work shall be specified to make installed devices usable. For the description, specifications shall include the necessary requirements for each project by clarifying the roles shared between the contractor of the relevant project and the contractors of other procurement projects. [1. Basic requirements to be listed] ・ Hardware settings ・ Software installation (Personnel in charge of design/installation/setting for each piece of software should be clarified by, for example, creating a table of the division of roles) ・ Settings [2. Requirements to be added depending on type/characteristics of project] ・ Network settings ・ Connection with networks ・ Other necessary associated work, such as backup, etc. Example of a description in specifications Device setup (A) The contractor shall carry out hardware settings, software installation and settings, and network settings of deliverable devices in this procurement (B) The contractor shall apply update programs with regard to software installed on the devices for this system and firmwares for the network devices. However, the propriety of the application shall be discussed before implementation. (C) The contractor shall carry out network settings, various environmental settings, such as disk allocation, security settings, and install all deliverable software products, upon due coordination with the modification contractor. In the case of a large-scale separated procurement project, the responsibility demarcation for the installation/connection of devices, etc. may become unclear. Thus, the responsibility should be clarified in advance by, for example, creating a table of the division of roles (see 6.7.5). 433 Notes on security Security settings/adjustment To carry out environment settings and adjustment work necessary for this system, using the procedures for the existing system, the installation procedures and the prepared security design documents. Updating of virus definition file Virus software/virus definition files shall be updated to the newest version. 434 6. Operation verification/test Item Outline of service operations Suggested input (Prepared by the procurer) Product (Prepared by the contractor) Matters to be described in specifications Example/explanation of a description in specifications Notes on characteristics of project/information system Description To perform operation verification tests on installed hardware, software and the network and provide support for tests performed by system developers. ・ List of items subject to operation verification ・ Information necessary to perform tests, such as coordination policies with other functions ・ Test specifications ・ Report on test results (Operation test report) To list inspections to be implemented as operation verification for installed devices and software and their requirements and targets. Documents to be presented by the procurer shall be specified, as well as any documents to be reported in response to the test results. [1. Basic requirements to be listed] ・ Subjects of the operation verification/test ・ Implementation and validation of the operation verification/test ・ Response to generated problems ・ Cooperation with concerned parties ・ Report on the operation verification/test [2. Requirements to be added depending on type/characteristics of project] ・ Tests to be performed (and details of support) and application in case that the project requires integration with the existing system ・ To specifically clarify the division of roles with the operation contractor, etc. Example of a description in specifications ○Operation/connection verification test ・ The contractor shall perform an operation verification test and connection verification test for devices of this system to verify the compliance with the specifications ・ The contractor shall perform system test of the relevant system in cooperation with the renewal contractor, after the introduction of devices for this system and the renewal of ___system separately procured by the relevant ministry. When defects attributable to this procurement are found in system test, the contractor shall analyze the cause and carry out the change in environment settings, and other necessary tasks until the system works properly. Since items subject to operation verification and its details are different depending on the scale and system subject to connection, test requirements should be clarified in advance. When testing, cooperation with the application construction contractor may at times become necessary. Thus, the division of roles should be clarified beforehand. 435 Notes on security - 436 7. Migration Item Outline of service operations Suggested input (Prepared by the procurer) Product (Prepared by the contractor) Matters to be described in specifications Example/explanation of a description in specifications Notes on characteristics of project/information system Notes on security Description To carry out migration of data, systems, and operations, etc. from the existing system (in the case of renewal that is not associated with the application change, etc.) or support for migration work carried out by the design/development contractor. ・ Outline of the types/volume and location of migrated data ・ Migration plan ・ Migration design ・ Report on the results of migration data validation When the contractor carries out data migration, conditions for data transfer, etc. shall be described. When a system developer carries out data migration, service requirements for migration support shall be described. [1. Basic requirements to be listed] ・ Items subject to migration ・ Details of migration work ・ Details of support for migration work ・ Prerequisites for migration work ・ Conditions for migration work (possible working hours, possible period of implementation, migration method, etc.) Example of a description in specifications ○Requirements for data migration The contractor shall implement migration work of data held in the existing system (A) The following make up the outline of the migration data. The details will be presented by the Ministry after the conclusion of the contract. (The rest is omitted.) (B) Following the migration, data verification shall be performed to ensure the integrity of the migrated data and the results shall be reported as the “report on the results of migration data verification.” The implementation body of migration shall be clearly decided in advance. When the contractor provides migration support, the scope of its support shall be clarified as much as possible. - 437 8. Information provision to operation/maintenance contractors Item Outline of service operations Suggested input (Prepared by the procurer) Product (Prepared by the contractor) Matters to be described in specifications Example/explanation of a description in specifications Notes on characteristics of project/information system Notes on security Description To setup devices or software and provide information on procedures to a contractor which assumes operation and maintenance work. To provide information pertaining to device and software settings and operation procedures to a contractor in charge of operation and maintenance work. ・ Specifications for device management information exchange file ・ Device management information ・ Setting information ・ Manual To select information to be handed over from device installation contractor to operation/maintenance contractor and to specify the procedures for information transfer. [1. Basic requirements to be listed] ・ Information to be transferred ・ Transfer procedures ○Information to be handed over Information on device management and setting information necessary for operation, monitoring and configuration management of the relevant system shall be put in a written document, which is then presented to the operation/maintenance contractor. An operation manual shall also be developed. ○Transfer procedures Prior to the installation of deliverable devices in the procurement, an explanation of operation procedures shall be given to the operation/maintenance contractor. After the installation of devices, the transfer to the operation/maintenance contractor shall be implemented. Suggestions for sure and effective ways to complete transfer procedures and other necessary matters should be presented. All the information necessary for the operation/maintenance contractor should be handed over. - 438 9. Information provision and training to users Item Outline of service operations Description To implement system operation training for persons in charge of the system and other employees Suggested input (Prepared by the procurer) ・ Possible dates and locations of training ・ Number of expected trainees ・ Suggested training schedule (draft) Product (Prepared by the contractor) Matters to be described in specifications ・ Training schedule ・ procedure documents ・ Textbook(s) When the contractor provides persons in charge of the system and other employees with operation training, the trainees and method of training shall be specified. [1. Basic requirements to be listed] ・ Details of training ・ Method of implementation ・ Trainees ・ Textbook(s) Example of a description in specifications ○Support for training, etc. After the verification test, training shall be provided for key personnel in regards to operation procedures, etc. of devices necessary for the operation of the relevant system. When using the relevant system, training for __(number) employees in charge of ___ is scheduled. The contractor shall create a textbook, assuming the IT proficiency level of expected trainees to be __. The textbook shall be made understandable using diagrams and charts, and be made available upon obtaining the approval of the persons in charge. A training schedule shall be prepared, considering the period until the commencement of the operation of the relevant system. Make-up days for cancelled classes shall be included in the training schedule. The fact that users have differences in IT competency should be taken into account depending on the systems, whether it is for persons in charge of the system and other employees. Since users may express their dissatisfaction in the final phase (training scene), review by the users should be planned in each phase (when creating a screen image, when the system is nearly completed, etc.). Example/explanation of a description in specifications Notes on characteristics of project/information system Notes on security - 439 10. Acceptance Item Outline of service operations Description To prepare and deliver a necessary set of deliverables and handle the acceptance tests required by ministries. Suggested input (Prepared by the procurer) ・ List of deliverable products Product (Prepared by the contractor) Matters to be described in specifications ・ A set of documents designated as deliverable products Example/explanation of a description in specifications Notes on characteristics of project/information system Notes on security To state that deliverables shall be ready for acceptance upon meeting the requirements for deliverable data, deliverable products and acceptance tests set forth by ministries. [1. Basic requirements to be listed] ・ Submission and approval of deliverable products ・ Response to and approval of acceptance tests [2. Requirements to be added depending on type/characteristics of project] ・ Setup of the items of the acceptance test Example of a description in specifications ○Submission and approval of deliverable products The contractor shall prepare a set of documents necessary for acceptance and obtain approval. ○Meeting the requirements for, and approval of acceptance tests The contractor shall meet necessary requirements in accordance with the instructions of the relevant ministry with respect to acceptance test in preparation for the actual acceptance. Reviews should be set up on an appropriate timing to prevent rejections at the time of acceptance. - 440 6.7.3. Deliverable products and timing of submission The table below lists typical deliverable products and timing of delivery with respect to deliverable products. The official name of each product and its delivery deadline need to be listed in accordance with the actual situation. Service 1. Master plan formulation Deliverable product Implementation plan 2. Prior explanation /coordination with concerned parties Materials for preliminary coordination/information session and minutes (draft in the case of support) On-site investigation plan 3. On-site investigation/design Delivery deadline Prior to the commencement of introduction work Prior to each work on an as needed basis Prior to the commencement of on-site investigation Prior to the commencement of work at the introduction site 5. Device setup On-site investigation report Working diagram Layout diagram for device installation Rack installation diagram Wiring diagram Other design documents Change documents for working documents for hardware and a set of software, layout diagram for device installation, rack installation diagram, wiring diagram, and other design documents Environment definition 6. Operation verification/test Test specifications Prior to the commencement of operation verification/test Report on test results After the implementation of operation verification/test Prior to the implementation of migration After the implementation of migration Until the completion of the introduction work 4. Device installation work 7. Migration 8. Provision of information/training for operator/maintenance contractor 9. Information provision and training to users 10. Acceptance Migration design Report on the results of migration data validation Device management information Setting information Manual Training schedule A range of procedure documents Textbook(s) A set of designated deliverable products 441 Until the date designated in the specifications After the setup of devices - Date of acceptance 6.7.4. Suggested input The following table shows input and timing to be presented to the contractor (proposer) in advance. The official name of each deliverable and its delivery deadline need to be listed in accordance with the actual situation. Service 1. Master plan formulation Input Overall schedule Table of the division of roles 2. Prior explanation/coordination with concerned parties Contact list for each center and concerned companies List of locations to which devices are introduced List of devices to be introduced Security guidelines prescribed by each ministry Working diagram Layout diagram for device installation Rack installation diagram Wiring diagram Other design documents (The above applies to the existing system) Requirements for hardware, requirements for software, requirements for networks, requirements for operation/maintenance List of items to be verified Information necessary for the implementation of tests, such as coordination policies with other sets of devices Outline of type, volume and location of migration data Migration plan 3. On-site investigation/design 4. Device installation work 5. Device setup 6. Operation verification/test 7. Migration Timing for presenting input Included in procurement specifications or as an attachment at the time of tender publishing Included in procurement specifications or as an attachment at the time of tender publishing Disclosed on the website, or during tender period During tender period After the conclusion of a contract Included in procurement specifications or as an attachment at the time of tender publishing After the completion of a contract 8. Provision of information/training for operator/maintenance contractor 9. Information provision and training to users Specifications for device management information exchange file Included in procurement specifications or as an attachment at the time of tender publishing Possible dates/locations of training 10. Acceptance List of deliverable products Included in procurement specifications or as an attachment at the time of tender publishing Included in procurement specifications or as an attachment at the time of tender publishing 442 6.7.5. Division of roles In separated/breakout procurement, the division of roles among procured services, related procurement and the relevant procurement should be clarified in accordance with the scope of separated orders and the ministerial policies and presented at the time of tender publishing. When considering procurement, services to be realized in the entire procurement should be identified. A clear division of roles and services should be specified and a table of the division of roles should be compiled so that the concerned parties can agree that there are no omissions/errors in services/roles in the breakout procurement. Example of the table of division of roles Main task △ ◎ 443 △ Developer 1. Master plan formulation 2. Prior explanation/coordination with concerned parties 3. Onsite investigation/design 4. Device installation work 5. Device setup 6. Operation verification/test 7. Migration 8. Information provision to operator/maintenance contractors 9. Information provision and training to users 10. Acceptance Contractor △: Confirmation Operator ○: Responsibility for implementation Ministry ◎: Accountability ◎ ◎ ○ ○ ◎ ◎ ◎ ◎ ◎ ◎ ○ ○ ○ ○ ○ ○ ◎ ○ ○ △ 6.8. Tasks incidental to procurement of iDC equipment 6.8.1. Definition of procurement area “Tasks incidental to procurement of iDC equipment” refers to the installation of various devices prepared by the contractor in the facility to make them usable via the network environment, such as cables and lines, and to the implementation of system operation monitoring and incidental services. It corresponds to the one defined as operation technology in the procurement area and the main tasks are planning, operation and maintenance, etc. Please refer to “5.3 iDC/Equipment” for requirements/specifications for the functions/services of iDC equipment. This section excludes services to procure equipment necessary for the operation of information system devices (racks and cooling systems, etc.) since they are included in the procurement of devices. Planning phase Requirements definition 要件定義 phase Operation/maintenance 運用・保守フェーズ phase Development phase 開発フェーズ 6.2 6.2.3 Support for ( 等) procurement (Project management, etc.) 6.3 6.4 運用 6.4 Operation 6.5 Helpdesk 6.1 Support 6.1全体計画 for master 策定支援 plan formulation 6.2.2 Support for procurement 6.2 1 調達支援 (requirements ( 等) definition, etc.) 6.3 System integration (design/development) 6.3 ハードウェア更改 6.3 機能追加 6.6 Maintenance 6.7 Tasks incidental to procurement of devices Hardware maintenance Software maintenance Application maintenance System infrastructure maintenance 6.8 Tasks incidental to procurement of iDC equipment ・ 設備) 6.9 Network procurement 6.12 Security Figure 6.8-1 Items corresponding to the areas of procurement of services 444 6.8.2. Services to be listed in specifications 6.8.2.1 Typical service operations The following table shows services to be included in the specifications. The corresponding SLCP-2007 13 activities are also given. For actual procurement, correspondence to SLCP activities should be examined so as not to omit necessary information. Items corresponding to the Basic Guidelines on Procurement (BGP) 14 are also listed. To write specifications, a draft for procurement specifications should be prepared by selecting appropriate items while coordinating them with the corresponding Program Management Office (PMO). Service operations 1.Work plan Outline of service operations Creation of implementation plan Scope of procurement Work flow Schedule, etc. 2.Implementation of work Work at the Data Center Cable lines-related work (when necessary) 3.Preparation for initiation Creation of system operation of operation Monitoring procedures /maintenance Procedures for monitoring potential attacks Procedures for security diagnosis Formats of reports Formats of management registers Service requirements for SLA 4.Operatation/ Daily tasks (operations maintenance (daily) management, and maintenance management) Creation of daily report 5. Operation/ Weekly tasks (database maintenance (weekly) backup, etc.) Creation of weekly report 6. Operation/ Monthly tasks (security maintenance (monthly) diagnosis, etc.) Creation of monthly report 7. Operation/ The following services with maintenance (irregularly) respect to the work generated irregularly Details of work Creation of report Service items corresponding to Chapter/section Guidelines for corresponding to Activities of Information Disclosure Basic Guidelines SLCP-2007 concerning Data Center for Procurement Security and Reliability (and its title) (1st ed.) by MIC 2.3.1 62.-68.Access control Chapter II (4) / (5) Preparation for initiation of (requirements for Chapter IV quality assurance process building) Chapter V Chapter VI 3.2.2 Construction of environment 3.2.1 (Environmental improvement) Preparation for process initiation 1.7.4.1 System operation 1.7.4.2 Operation monitoring and collection of operation data, identification, recording and resolution of problems, improvement of operation environment 1.7.4.3 Identification and improvement of problems 1.7.4.4 Improvement of operation environment 1.7.7 Evaluation of system operation 1.8.2 Comprehension and correction/analysis of problems 1.8.3 Correction 13 - 99. SLA Chapter X, Chapter XI, Chapter XII Chapter V (5) 60. 24hours×7days/weekly monitoring 105.-109. Service notice/report 110.-112.Support service 69.-70.Media storage Software Life Cycle Processes-Japan Common Frame 2007 (SLCP-JCF 2007), Information-technology Promotion Agency, Japan (in Japanese) 14 The “Basic Guidelines for Government Procurement Related to Information Systems,” March 2007, Ministry of Internal Affairs and Communications (in Japanese) http://www.soumu.go.jp/menu_news/s-news/2007/pdf/070301_5_bs2.pdf 445 6.8.2.2. Explanations and examples of descriptions in specifications concerning services 1. Work plan Item Outline of service operations Description To create an implementation plan for introduction work (adjustment of the Data Center equipment, cabling/wiring, device installation, etc.) Suggested input (Prepared by the procurer) Establishment of the Data Center and a list of devices subject to operations management Requirements for the installation site System integration schedule Implementation plan Product (Prepared by the contractor) Matters to be described in specifications Example/explanation of a description in specifications To specify requirements for creating an implementation plan [1. Basic requirements to be listed] ・ Scope of procurement ・ Implementation framework ・ Work schedule, etc. Examples of descriptions in specifications ○ Scope of procurement The objective of the information systematization is to introduce professional services by installing server devices in the information system of the Ministry of ___, which includes power sources, ventilation system, anti-seismic measures and the prevention of physical intrusion, etc. for the safe operation of devices in the Ministry of ___. The scope of the procurement in this project shall be limited to the preparation for power equipment associated with device installation, anchoring devices for anti-seismic purposes, physical security measures for devices, and operations at the installation site, and shall exclude the following requirements. (i) Procurement of goods such as server devices used by the Ministry of ___ and the incidental setup work (ii) Monitoring of the information system on which the server devices used by the Ministry of ___ are operated. ○Implementation framework The following are the requirements in this section: (i) The contractor shall establish an implementation framework to carry out this project. (ii) Details of the implementation framework shall be clearly specified in terms of the roles of each team, division of work, and timing of team formation, etc. (iii) The personnel in charge of the relevant services shall have qualifications related to project management or have equivalent knowledge, such as a Project Management 446 Professional (PMP). Qualification/knowledge necessary for the position shall be pursuant to the Basic Guidelines for Government Procurement Related to Information Systems of MIC. (iv) The contractor shall formulate a schedule/organizational plan based on the necessary volume of work by selecting necessary items from work requirements stipulated in this specifications document, create the Work Breakdown Structure (WBS) and clarify the orders and dependency of work flows. The WBS is a table showing the entire project being divided into tasks. Notes on characteristics of project/information system ○Work schedule (Schedule of implementation for commissioned work) (i) Date M/D/Y: Completion of preparation for the Data Center (scheduled for installing devices) (ii) Date M/D/Y: Commencement of test operations (iii) Date M/D/Y: Commencement of production operations (iv) Date M/D/Y: Completion of the relevant contract (i) Since the scope of procurement is different in each system, there may be cases where internet connection and exclusive lines are not necessary. (ii) The column of “example/explanation of a description in specifications” does not include monitoring after the commencement of operations; however, there may be cases where only the work for the installation and commencement is procured. (iii) In cases where multiple services are procured, when listing the overall requirements (skills of staff, etc.), it is not desirable that the same description appears a number of times. Thus, the contractor shall consider how to describe them in the most effective way. With respect to the consignment schedule, the scheduled date of device installation should be included in the presented system integration schedule, in view of the facility preparation at the Data Center. - Notes on security 447 2. Implementation of work Item Outline of service operations Suggested input (Prepared by the procurer) Products (Prepared by the contractor) Matters to be described in specifications Example/explanation of a description in specifications Description To carry out work at the Data Center (preparation for equipment, installation of devices). To carry out wiring-related work, etc. when necessary. List of devices, network diagram (Details of device information to be installed, details of the types of cables/lines to be wired in the iDC and server/provider) Report on the completion of work To list requirements for the implementation of work [1. Basic requirements to be listed] ・ Preparation/coordination for the equipment in the Data Center ・ Support for device installation (cable connection, etc.) [2. Requirements to be added depending on type/characteristics of project] ・ Requirements for the implementation of wiring-related work Example of a description in specifications ○Preparation/coordination for the equipment in the Data Center (1) Function composition Among requirements listed in Chapter III, the procurement in this project applies to the “conditions for location, conditions for facility, conditions for machine rooms, conditions for power sources /ventilation, conditions for security, and conditions for operations” in the “iDC/equipment.” Other items shall be procured under a separate contract. (2) Scale requirements The following is the number of devices requested by the Ministry of ___. Information system devices, such as server, etc.: __ units Network devices, such as router and switch, etc.: __ units Racks: __ units An operation room for the operators[ ___ persons (or __m2)] shall also be procured (the operation room and network wiring with the server shall be included in the scope of procurement) Computer terminal desks: __ units Lockable cabinets: __ units (3) Procurement work (i) Installation layout design(including rack installation) A layout of the installation site for the information system devices to be installed in the Data Center shall be designed. When renting racks owned by the Data Center, a rack installation diagram shall be created based on the presented list of devices. (ii) Power source connection design 448 With respect to the power source connection, the contractor shall create a “power/line connection diagram,” indicating the allocation and breaker, etc. When redundancy of power sources is necessary, the contractor shall consider the redundancy including a distribution board by, for example, supplying the distribution board in a separate system. (iii) Equipment preparation The contractor shall prepare equipment based on the results of the “layout/power connection design,” such as anchoring devices for anti-seismic purposes/power source preparation work associated with rack installation. (4) Requirements for implementation of work (i) The contractor shall manage the project management using the WBS-based management method. (ii) The contractor shall propose a progress management method to the relevant official of the Ministry of ___, with due consideration to the details of the work. The contractor shall also promote and manage the work in accordance with the progress management method verified by the relevant official of the Ministry of ___. (iii) The contractor shall hold regular progress report sessions to give a briefing on the work status (plan, performance and the gap between them). (iv) Consultation with the relevant official of the Ministry of ___ shall be conducted in Japanese and information materials and deliverable documents shall be written in Japanese. (v) When changing the implementation framework, the contractor shall file a report to that effect to the relevant official of the Ministry of ___ and obtain confirmation. ○Support for device installation (cable connection, etc.) (i) On-site presence when carrying in devices To secure a carrying-in route leading to the device installation site in the server room (ii) Support for power source connection To give power connection instructions to and manage the installation contractor with respect to the connection of the distribution board to the power distribution unit (PDU) and the connection of the rack power distribution unit to the power cables of the devices. (iii) Support for installation and connection of cables To prepare protective ducts/trays associated with the installation of LAN cables, fiber cables, and lines for external connections, etc. ○Requirements for implementation of wiring-related work (basic requirements) (i) The contractor shall provide line-terminating devices. Routers and switches shall be brought in and installed by a hardware contractor which is separately procured. 449 Notes on characteristics of project/information system (ii) Piping and power source work with respect to wiring into the administrative building ___ shall fall under the scope of the procurement. (iii) The date of commencement of the use of the lines shall be on M/D/Y. (i) The installation work may change depending on whether the lines have already installed or not. With respect to the descriptions, in addition to specifying requirements for the work as described above, there is an option of having the contractor define the work items, instead of describing the elements, except for technical requirements. (ii) In the power connection design, devices requiring redundancy of power sources should be specified in the list of devices and instructions should be given to make sure that power will be supplied from a different distribution board. (iii) With respect to the installation of cables, there may be a risk of communications interruption due to mutual interference in an environment where a number of power cables and communication-related cables are run together. Thus, preparation for piping and trays to prevent interference should be requested. (iv) With respect to the piping and power source work in relation to wiring in the administrative building ____, the decision shall be made whether it is included in the scope of procurement depending on the condition of the installation site in the building (location under the contract, etc.). - Notes on security 450 3. Preparation for initiation of operation/maintenance Item Outline of service operations Suggested input (Prepared by the procurer) Product (Prepared by the contractor) Matters to be described in specifications Description To create a procedure manual for system operation monitoring to be carried out by the operation contractor List of system operation monitoring items Procedures for system operation monitoring Report formats Communication flow chart To connect a newly constructed/extended network with an existing network and to specify requirements for the implementation of migration or support work and items necessary for planning, etc. [1. Basic requirements to be listed] ・ Creation of a procedure manual for system operation monitoring ・ Creation of report items/formats ・ Creation of management registers ・ Services related to Service Level Agreement (SLA) Example/explanation of a description in specifications Example of a description in specifications ○Creation of an operation manual The contractor shall create an “operation manual” in cooperation with the system development/device delivery contractors and system operation support contractor. The following is the breakdown of the “operation manual.” (i) Procedures for operation of monitoring environment The contractor shall specify a method of operating the system operation monitoring environment and each monitoring procedure for the items listed in the list of monitoring items (node monitoring, process monitoring, etc.). The document shall cover the entire environment related to monitoring, such as monitoring screen and incidental devices (warning lights, etc.) A method of response shall also be specified, such as reporting at the time of a detection of abnormality and a method of changing settings, such as monitoring items. ○Creation of reporting items/formats The contractor shall decide on the details of reporting to the Ministry of ___ in cooperation with the Ministry of ___ with respect to the result of work, such as system operation monitoring/monitoring of attacks, and to create report formats. The contractor shall also create a request form for emergency work, in the same manner of cooperation. (i) Decision on reporting items The contractor shall decide on reporting items (date, name of server, 451 event, etc.), reporting timing (daily, monthly, etc.), method of reporting (printed matter, electric data, such as email, etc.) and the recipient of report, based on the system operation monitoring items. (ii) Creation of formats The contractor shall create a request form for emergency work and a form for reporting the items determined in (1). The report format to be created is roughly described as follows, which shall be further detailed depending on monitoring items: (a) Request for and report on emergency work, (b) System operation daily report, (c) System operation weekly report, (d) Attack status report (monthly), (e) Incident (abnormality)report, (f) System operation monthly report, and (g) Security diagnosis report (monthly). ○Creation of management register The contractor shall create management registers concerning the matters to be installed, operated and managed in the iDC, in cooperation with the Ministry of ___. (i) Management register (a) Hardware configuration management register (b) Network supply management register (c) Document management register (d) Backup media management register (e) Communication flow chart (f) Policies for measures against large-scale disaster/communication structure ○ Services related to SLA Notes on characteristics of project/information system The contractor shall evaluate the status of achievement of SLA items on a monthly basis, and to report three-month results at the “service level briefing session” held every three months. (i) When there is no existing network or ministerial system accommodated in the Data Center, cooperation with other contractors in charge of the existing network or system is deemed to be unnecessary for the creation of plans. However, the above examples are cited since there are existing systems in many procurement projects. (ii) The operation manual assumes the use of the equipment possessed by the iDC contractor for internet connection and firewall, etc. as a precondition. However, when the equipment is prepared separately by a related contractor, such as a network contractor, the items shall be defined in accordance with the consigned items. (iii) Response policies of the iDC contractor and a communication flow with the relevant official of the Ministry of ___ in the event of a large-scale 452 disaster shall be clarified. (iv) The frequency of Service Level Management (SLM) (evaluation items, reporting and review cycle, etc. regarding SLA) shall be determined with consideration to the level of importance of the system, although it is specified to be every three months in the “example/explanation of a description in specifications.” This is because the necessary costs for SLM may grow significantly if the number of items and frequencies is increased. Notes on security 453 4. Operation/maintenance (daily) Item Outline of service operations Suggested input (Prepared by the procurer) Product (Prepared by the contractor) Points to be described in specifications Example/explanation of a description in specifications Description Operations and maintenance tasks to be implemented and reported on a daily basis Operation manual Procedures for monitoring security status System operation daily report Incident (abnormality) report (only when an incident occurs) To specify the operation/maintenance implementation items and requirements, etc. [1. Basic requirements to be described] ・Daily tasks (Equipment maintenance management, monitoring of system operation status, maintenance management, matters related to reporting) ・Creation of a system operation daily report Example of a description in specifications ○Daily tasks (i) Equipment maintenance management The contractor shall monitor power source/ventilation equipment, disaster detection devices (smoke sensor, etc.), and surveillance cameras, etc. that have been provided as iDC equipment. The contractor shall conduct maintenance management of security devices for the access to the room and access control of visitors. (ii) Operation status management The contractor shall monitor the items stipulated in “3. Preparation for initiation of operation/maintenance” in accordance with the operation manual (Examples of monitoring items) Live monitoring of the system Process monitoring Event/message monitoring Capacity monitoring (The rest are omitted.) (iii) Maintenance management The contractor shall carry out visual confirmation of lamps [LED (status display lamp), indicator display and device status display, etc.] by regular patrolling and monitoring the status of devices. (iv) Matters related to reporting The contractor shall carry out reporting based on the prescribed communication/response method if defects are detected or 454 concerns outside the scope of the procedures are noticed during the daily operations. Notes on characteristics of project/information system Notes on security ○Creation of a system operation daily report To record the status of the above mentioned (i) and (ii) in the system operation daily report. (i) When the daily report is deemed unnecessary due to the importance of the system accommodated in the Data Center, etc., this section may not be required. However, reporting on monthly basis is regarded as mandatory. Security monitoring The contractor shall report the security monitoring status (careful investigation of the firewall logs, monitoring of unauthorized access, etc.) and the monitoring results shall be periodically reported to the relevant official of the ministries. 455 5. Operation/maintenance (weekly) Item Outline of service operations Suggested input (Prepared by the procurer) Product (Prepared by the contractor) Points to be described in specifications Example/explanation of a description in specifications Notes on characteristics of project/information system Notes on security Description Operations and maintenance tasks to be implemented and reported on a weekly basis Weekly tasks (database backup, etc.) Creation of weekly report Operation manual System operation weekly report To specify the operation/maintenance implementation items and requirements, etc. [1. Basic requirements to be listed] ・Weekly tasks ・Creation of a system operation weekly report Example of a description in specifications ○Weekly tasks The contractor shall confirm the success of all the database backup jobs implemented on a weekly basis, and implement tape cleaning and media exchange. The contractor shall carry out reporting based on the prescribed communication and response method if defects are detected or concerns outside the scope of the procedures are noticed during the weekly operations. ○Creation of system operation weekly report The contractor shall create a system operation weekly report with respect to the implementation status of the weekly tasks mentioned above. (i) When a weekly report is deemed unnecessary due to the importance of the system accommodated in the Data Center, etc., this section may not be required. However, reporting on monthly basis is regarded as mandatory. - 456 6. Operation/maintenance (monthly) Item Outline of service operations Suggested input (Prepared by the procurer) Product (Prepared by the contractor) Matters to be described in specifications Example/explanation of a description in specifications Notes on characteristics of project/information system Notes on security Description Operations and maintenance tasks to be implemented and reported on a monthly basis Monthly tasks (security diagnostics, etc.) Creation of a monthly report Operation manual Procedures for security diagnosis System operation monthly report Report on security diagnosis To specify the operation/maintenance implementation items and requirements, etc. [1. Basic requirements to be described] ・Monthly tasks ・Creation of a monthly report Examples of descriptions in specifications ○Monthly tasks (security diagnosis) The contractor shall perform security diagnosis once a month, based on the security diagnosis procedures created in “3. Preparation for initiation of operation/maintenance.” The contractor shall organize diagnosis results (explanations on vulnerability, impact and response procedures) and create and submit a “security diagnosis report.” ○Creation of a system operation monthly report The contractor shall create a security diagnosis report about the results of monthly operations mentioned above. The contractor shall organize the system operation/maintenance implementation status and indecent status of the relevant month and create a system operation monthly report. (i) It is assumed that the SLA items shall, in principle, be specified; however, the SLA performance need not be reported if SLA is not specified, depending on the importance of the system, etc. Security diagnosis and reporting The contractor shall carry out periodical diagnosis on vulnerability and report its result (situation, impact, response method) to the relevant official of the ministry. 457 7. Operation/ maintenance (irregularly) Item Outline of service operations Suggested input (Prepared by the procurer) Product (Prepared by the contractor) Matters to be described in specifications Example/explanation of a description in specifications Description Operations and maintenance tasks to be implemented and reported on an irregular basis Operation manual Request for and report on emergency work (section of request) Request for and report on emergency work (section of report) Other reports on work results (no fixed format, etc.) To specify the operation/maintenance implementation items and requirements, etc. [1. Basic requirements to be listed] ・Details of work ・Creation of a report Examples of descriptions in specifications ○Details of work (1) Maintenance management (i) Regular maintenance The contractor shall implement the reception and on-site presence of SE/CE for the regular maintenance of operations of installed devices, etc., necessary tasks prior to and after the work (server shutdown, restart), and confirmation of the completion of the maintenance work, etc. (ii) Response to defects The contractor shall implement reporting for lap status confirmation/monitoring status and log data collection, at the time of occurrence of a defect, etc. (2) Storage management The contractor shall implement the system change and system full backups after the maintenance / alteration work. (3) Expendables management (i) Hardware management The contractor shall perform acceptance operations/ renewal of management register in response to hardware addition/change (ii) Media management The contractor shall receive new media from the concerned contractor, change to the new media, and renew the management register when replacement becomes necessary due to damage/degradation of the media (4) Other (i) The contractor shall implement the reception of visitors to the Data Center (leading visitors into the server room), 458 Notes on characteristics of project/information system implement reception of other business operators, such as relevant officials of the ministry and the developer (guiding them to the place where racks are installed, etc.). (ii) Sending and receiving of goods (consumables, etc.) The contractor shall handle the reception of goods sent from the relevant administrative officials, related contractors, and the external business operators concerning the system, or the shipment of goods. (iii) Audit management The constructor shall implement audit acceptance/ response to inquiry slips when iDC becomes subject to various audits, including those of external organizations (iv) Removal of devices When removing installed devices and racks or moving the Data Center, the contractor shall implement removal work in cooperation with concerned contractors, such as device procurement vendors; such work includes the removal of devices, unfastening of the fixed racks, retracting of the power cables and transfer of operation procedures. (5) Response to references, etc. The contractor shall implement a lamp status confirmation, hardware installation status and response to inquiries/requests for information provision concerning iDC equipment/operation, such as inquiries about the Data Center equipment. (6) Creation of report The contractor shall create a “request for and report on irregular work” with respect to the work result in accordance with the document of “request for and report on irregular work.” When other tasks are implemented, a report (no fixed format) shall be created on the result of the work. (i) There may be cases where any kind of irregular tasks are to be carried out due to an unexpected event or extraordinary request from the ministry. Such tasks should be appropriately carried out in line with the operation/maintenance items, but may not be specified if it is deemed to be implementable within the scope of the regular work due to the characteristics of the system operation. (ii) When a regular audit is mandatory with respect to the audit management, the details and frequency of the audit shall be presented. - Notes on security 459 6.8.3. Deliverable products and timing of submission The table below lists typical deliverable products and timing of delivery with respect to hardware maintenance services. The official name of each product and its delivery deadline need to be entered in accordance with the actual situation. Service 1.Work plan Deliverable product Implementation plan 2.Implementation of work Report on completion of work 3.Preparation for initiation of operation/maintenance System operation monitoring procedures Communications-related documents Communication flow chart System operation daily report Incident (abnormality) report (only in the event of incident) System operation weekly report 4.Operation/maintenance (daily) 5.Operation/maintenance (weekly) 6.Operation/maintenance (monthly) 7.Operation/maintenance (irregularly) System operation monthly report Security diagnosis report Request for and report on irregular work (section of request) Delivery deadline By five days prior to the commencement of work after the conclusion of the contract Within five days after the completion of work At the time of formulating pre-operation documents (by the commencement of operation training) Every day after the commencement of operation Every week after the commencement of operation Every month after the commencement of operation Within five days after the completion of work 6.8.4. Suggested input The following table shows input and timing to be presented to the procurer (proposer) in advance. The official name of each product and its delivery deadline should be entered in accordance with the actual situation. Service 1.Work plan 2.Implementation of work 3.Preparation for initiation of operation/maintenance 4.Operation/maintenance (daily) 5.Operation/maintenance (weekly) 6.Operation/maintenance (monthly) 7.Operation/maintenance (irregularly) Input Establishment of Date Center and list of devices subject to operations management Requirements for the of installation site System integration schedule List of devices and network diagram List of monitoring items of system operation Timing for presenting input Included in procurement specifications or as an attachment at the time of tender publishing Included in procurement specifications or as an attachment at the time of tender publishing Included in procurement specifications or as an attachment at the time of tender publishing Included in procurement specifications or as an attachment at the time of tender publishing Included in procurement specifications or as an attachment at the time of tender publishing Operation manual Security status monitoring procedures Operation manual ― ― Operation manual Security diagnosis procedures Request for and report on irregular work (section of report) ― ― The following show the examples of suggested service level settings in iDC equipment. Items and values should be used as a reference and should be determined in accordance with the importance of individual projects and systems. The contractor should clearly prescribe the level of the quality of services to be provided by setting the SLA, which is the result of consensus between the procurer (the Ministry of ___) and the provider (iDC contractor), and carry out maintenance and management 460 of the service level in accordance with the SLM. The SLA has two approaches: guaranteed-goal oriented approach and effort-oriented approach, either of which should be applied to each item. Examples of service level settings for iCD equipment are listed below. Items and values should be used as a reference and should be determined in accordance with the importance of individual projects and systems. Item Classification number 1-1 Availability 1-2 Service level items Details of regulations Unit Time Example of service level settings Service hours Hours in which iDC equipment is provided Defining service hours (set by the type of service) Examples of the service type: ・Power supply ・Operation service ・Operation monitoring Examples of time setting ・24 hours×7 days/week (Excluding planned shutdown plan/ regular maintenance) ・9:00-17:00 Notice of a service shutdown (when a shutdown occurs during service hours, time of planned shutdown shall be set by the provider on an individual case basis, and a prior announcement of the planned shutdown shall be stipulated.) Service availability Availability (power supply) - weld Availability To manage continuity of power supply to installed devices. At least 99.8% time/service time availability, etc. However, if redundant power source is installed, a judgment basis for supply disruption should be defined. 1-3 Availability (installation environment) - provision time within management range/ service time Availability By setting server room management temperature and humidity (24ºC±4ºC), the temperature and humidity shall be controlled within the range. The operations shall be carried out within the management range. Example of the setting: To be controlled between an upper limit and a lower limit at a 99.5% level of confidence. 1-4 Availability (network) - network operating time/ scheduled network operating time (service time) Availability To define availability concerning the network procured as iDC equipment. At least 99.9% availability, etc. 1-5 Availability - monitoring service provision time/scheduled monitoring service provision time (service time) Availability To define system availability concerning various monitoring environments procured as iDC environment. At least 99.5% availability, etc. Number of operator staff Number of staff engaged in the relevant system Staff number To define the number of staff when constructing operation system exclusive for the system to be procured 2-1 Accuracy Error rate per operator (operation other than procedures) Error rate (%) To define the number of operation errors and typographical errors, etc. with respect to the details of the statement of operation procedures. Setting the parameter should be careful when defining the error rate, instead of defining the frequency. 2-3 Operator staff Number of training sessions for operator Number of To define the number of training training sessions for operators about sessions ISO-related matters and security policies: for example, 8 hours every 6 months. 2-1 Reliability 461 Item Classification Service level items number 2-4 2-5 Reliability Details of regulations Unit Example of service level settings Defect notification Setting a communication process at Presence or process/ the time of occurrence of a defect absence notification time (recipient of notification/method/path) and time Time spent on notification to prescribed recipients based on the communication process ・Method of notification - phone call, e-mail, website ・Example of recipient of notification - procurer receiving the provision of services -Owner of services (in cases where services are outsourced) ・To contact designated emergency contact persons by e-mail/phone call and post notification on the website ・To set notification time suitable for the recipient of notification ・Settings suitable for the service level within/outside of business hours To implement the SLA settings taking the three points above into account. The following are the possible cases: Case 1 Notification of defect within business hours to procurers who receive service provision or service owner by phone call or e-mail (e.g. within one minute in the case of automatic notification system. within five minutes in the case of person to person contact) Case 2 Notification of defect outside of business hours to procurers who receive service provision or service owner by phone call or e-mail (e.g. within one minute in the case of automatic notification system. within 10 minutes in the case of person to person contact) Case 3 Defect occurrence report on the website for the procurers who receive service provision and target posting time (posting the time of occurrence, and expected time of recovery on the website within 30 minutes after the defect occurrence) Defect monitoring Collection of defect interval incidents/interval of aggregation (Frequency of confirmation of operation status of devices) There are cases where settings are different between within and outside of business hours. Within one minute (core business) Fifteen minutes (other than the above) 462 Time 6.8.5. Division of roles This section introduces an example of the division of roles between the hardware maintenance contractor, ministries and procurement contractors of other operations. In separated/breakout procurement, the division of roles among procured services, related procurement and the relevant procurement should be clarified in accordance with the scope of separated orders and the ministerial policies and presented at the time of tender publishing. When considering procurement, services to be realized in the entire procurement should be identified. A clear division of roles and services should be specified and a table of the division of roles should be compiled so that the concerned parties can agree that there are no omissions/errors in services/roles in the breakout procurement. (Specification for “A set of Data Center Borrowings, etc.” Ministry of xx, April 2010) ○Division of roles with other contractors, etc. (1) Technical support and information provision, etc. A. Information provision for understanding of progress When being indicated or a request is made for information provision for understanding of progress, the contractor shall take appropriate response in line with consultation with the Ministry of ___. B. Advice on the appropriate use of deliverable products The contractor shall give answers and advice on inquires on appropriate and effective use of deliverable products in this procurement. C. Support for approaches to system audit When system audit on the deliverable products in this procurement is to be carried out, the contractor shall proactively offer technical support and information. (2) Coordination with concerned parties A. Coordination with concerned companies The contractor shall gain approval of the Ministry of ___ about requests to or coordination with the contractors of design, development and test, migration and operation commencement of this system (hereinafter referred to as “system integration companies), the contractor of operation monitoring management of this system (hereinafter referred to as “operation contractor”), and the contractors of other procurement projects associated with this system (___ subsystem server maintenance contractor) and any other hardware maintenance contractors, hereinafter referred to as “the concerned contractors”) prior to the implementation. B. Coordination with external concerned parties The contractor shall consult with the Ministry of ___ with respect to requests to or coordination with companies on other systems involved with this system (operators of the existing systems, etc., hereinafter referred to as “external concerned companies”). The 463 contractor shall also make necessary adjustments and coordination. (3) Division of roles The following are the examples of a division of roles in installation work (1. Work plan – 3. Preparation for initiation of operation /maintenance) and product operation (4. Operation/ maintenance (daily) – 6. Operation Maintenance (irregularly), removal work (7. Removal work). A. Installation work ○: Main operator in charge, Work item Development/presentation of input information Creation of WBS concerning iDC equipment Regular briefing session Creation of layout of server room installation Creation of rack installation diagram (*1) Creation of power connection diagram Anti-seismic rack anchoring work (standard rack preparation (*1)) Power source preparation work Device emplacement work Presence at the emplacement site (instruction of installation locations) Preparation for equipment related to cables (*2) Device installation Cable connection work Support for connection work (instruction on connection targets, FA under-floor work, etc.) Preparation for operation monitoring environment (*3) Creation of operation monitoring procedures (*3) Operation acceptance training Guidance on acceptance training Supervisory section Maintenance contractor Operator Network contractor ○ △ △ △ iDC contractor △: Support, advice System integration contractor Device procurement contractor △ ○ ○ △ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ △ ○ ○ ○ *1: Division of roles when using racks provided by the iDC contractor is described. In cases where a device procurement contractor is supposed to prepare racks, the procurement contractor must create and prepare the racks. *2: “Equipment related to cables” refers to preparation for rosette for metallic cables, protection duct for optical lines, and protection duct (or tray) for LAN cable, etc. *3: “Preparation for operation monitoring environment” refers to the division of work in the case of using an operation monitoring environment for the iDC. When the monitoring environment is to be constructed by the related contractor, such as system by a development vendor, etc., the division of work should be further detailed separately. 464 B. Operation work ○: Main operator in charge, Work item Development/presentation of input information Operations (daily, weekly, monthly, irregularly) *On-site work Operations Creation of a report Defect detection/ report Implementation of countermeasures against defect Handling of visitors, such as maintenance vendor Media management Maintenance management of equipment (power sources/ventilation, etc.) Server room monitoring *Surveillance cameras,, access control devices, etc. Reporting abnormality in the server room Inquiries from users Supervisory section Maintenance contractor ○ △ Operator Helpdesk contractor △ Network contractor △ △ ○ △ ○ △ △ ○ ○ △ △: Support, advice iDC contractor ○ △ ○ ○ ○ ○ ○ ○ ○ ○ △ ○ 465 Device procurement contractor △ 6.9. Network procurement 6.9.1. Definition of procurement area Services of network procurement refer to (1) services related to network construction for LAN and WAN, etc.(services associated with network construction) or (2) services related to the procurement of such services as a wide area network or internet connection, etc., including WAN (services associated with communication service procurement). In terms of procurement pattern from the viewpoint of the technical domain, both network construction and network service procurement correspond to the category defined as WAN design / construction and ministerial LAN design/construction, covering such services as planning, design, work, operation and maintenance, etc. On the other hand, in the actual procurement, network procurement is often carried out concomitantly with server and software procurement of groupware and file sharing applications; however, this section does not deal with procurement of applications. Planning phase Requirements definition 要件定義 phase Operation/maintenance 運用・保守フェーズ phase Development phase 開発フェーズ 6.2 6.2.3 Support for ( 等) procurement (Project management, etc.) 6.3 6.4 運用 6.4 Operation 6.5 Helpdesk 6.1 Support 6.1全体計画 for master 策定支援 plan formulation 6.2.2 Support for procurement 6.2 1 調達支援 (requirements ( 等) definition, etc.) 6.3 System integration (design/development) 6.3 ハードウェア更改 6.3 機能追加 6.6 Maintenance 6.7 Tasks incidental to procurement of devices Hardware maintenance Software maintenance Application maintenance System infrastructure maintenance 6.8 Tasks incidental to procurement of iDC equipment ・ 設備) 6.9 Network procurement 6.12 Security Figure 6.9-1 Items corresponding to the areas of procurement of services 466 6.9.2. Services associated with network construction 6.9.2.1. Services to be listed in specifications 6.9.2.1.1. Typical service operations The following table shows services to be included in the specifications. The corresponding SLCP-2007 15 activities are also given. For actual procurement, correspondence to SLCP activities should be examined so as not to omit necessary information. Items corresponding to the Basic Guidelines on Procurement (BGP) 16 are also listed. To write specifications, a draft for procurement specifications should be prepared by selecting appropriate items while coordinating them with the Program Management Office (PMO). (1) Services for conducting network procurement associated with construction (construction of ministerial LAN and WAN construction and connection, etc.) Service operations 1.Design/development plan 2.Design/development Outline of service operations Activities of SLCP-2007 To create a draft plan equivalent to the “Plan of design/development phase” in the Guidelines for Business/System Optimization” To create design/development implementation framework and roles, detailed work and schedule Network design, development, work, and unit test (excluding hardware procurement for network devices) 3.Migration plan Planning of work necessary for migration of the existing users to the newly constructed network 4.Suppor for test and migration judgment Implementation of tests before handing the system over to the user to verify that the new network will operate as designed 5.Migration Implementation of migration 6.Operation/maintenance plan Institutionalization for operation/ maintenance, operation design and organization of documents 1.6.1 Preparation for process initiation 1.6.1 Preparation for process initiation 1.6.3System architecture design 3.2.2Environment construction 1.7.3.2 Documentation and validation of migration plan 1.7.3.3 Notification of the migration plan to all the concerned parties 1.6.13 Software acceptance test 1.7.1.8 Formulation of an operation test plan 1.7.2 Operation test 1.7.3.5 Notification of migration to all the concerned parties 1.7.3.6 Review for migration assessment 1.7.1.3 Establishment of problem management procedures 1.7.1.4 Preliminary coordination for system operation and establishment of work procedures 15 Chapter and section of specifications corresponding to BGP Chapter II (4), (5) Chapter IV Chapter V Chapter VI Chapter VII Chapter VIII Chapter IX Chapter X Chapter XI Chapter XII Chapter XIII Chapter II (4), (5) Chapter IV Chapter V Chapter VI Chapter VII Chapter VIII Chapter IX Chapter X Chapter XI Chapter XII (2). (4) Chapter XIII Chapter II (4), (5) Chapter V (5) Chapter VI Chapter VII Chapter VIII Chapter IX Chapter X Chapter XI Software Life Cycle Process-Japan Common Frame 2007 (SLCP-JCF 2007), Information-technology Promotion Agency, Japan (in Japanese) 16 The “Basic Guidelines for Government Procurement Related to Information Systems,” March 2007, Ministry of Internal Affairs and Communications (in Japanese) http://www.soumu.go.jp/menu_news/s-news/2007/pdf/070301_5_bs2.pdf 467 Service operations 7.Operation/maintenance work Outline of service operations Implementation of operation/maintenance and reporting of operation status in response to the result of the operation/ maintenance plan Activities of SLCP-2007 1.7.1.8 Establishment of work procedures for business operation 1.8.1.2 Creation of a plan and procedures 1.7.4 System operation 1.7.4.1 System operation 1.7.4.2 Operation monitoring and collection of operation data, identification, recording and resolution of problems, improvement of operation environment 1.7.4.3 Identification and improvement of problems 1.7.4.4 Improvement of operation environment 1.7.7 Evaluation of system operation 1.8.2 Problem identification and modification analysis 468 Chapter and section of specifications corresponding to BGP Chapter XII (3). (4) Chapter XIII 6.9.2.1.2. Explanations and examples of descriptions in specifications concerning services 1. Design/development plan Item Outline of service operations Suggested input (Prepared by the procurer) Product (Prepared by the contractor) Matters to be described in specifications Example/explanation of a description in specifications Notes on characteristics of a project/information system Notes on security Description To support creation of a document equivalent to the “plan for design /development phase” in the Guidelines for Business/System Optimization ・ Development schedule ・ Views of ministries through interviews, etc. ・ Ministerial security policies ・ User organizations (centers) in which the systems are deployed. ・ Documents pertaining to support for the formulation of a design development plan To specify the items to be conducted by the contractor with respect to the support of creating a plan for the design/development phase [1.Requirements to be described] ○Support for creating a plan for the design/development phase [2. Requirements to be added depending on type/characteristics of project] Specifications of procurement requirements to be basically described ○Support for creating a plan for the design/development phase The contractor shall provide support for creating a plan for the design /development phase to be formulated by the Ministry of ___. ・Organizations using the introduced system User organizations that will introduce the system in this procurement shall be those designated in the “Band and Period of Use of the Organizations Using the Network Connections” ・Boundary of responsibility concerning this procurement The scope of responsibility in this procurement covers the network devices installed by the contractor in the user organizations and centers. The plan for the design/development phase designated as a deliverable product in this service is equivalent to the “plan for the design/development phase” in the optimization guideline. Although the optimization guideline does not require a creation of the relevant product at the time of expansion, the relevant product should still be created in the case of a large-scale expansion due to the necessity of reaching consensus among concerned parties. There may be cases where further detailing of definition requirements is outsourced at the design phase. Please see “6.2.2. Support for the definition of requirements phase” for the details. Information security measures in accordance with the importance and risks involved in the information assets shall be specifically defined pursuant to the information security policies of each ministry based on the Standards for Information Security Measures for the Central Government Computer Systems. 469 2. Design/development Item Outline of service operations Suggested input (Prepared by the procurer) Product(Prepared by the contractor) Matters to be described in specifications Description In charge of design, architecture, construction, unit tests of the network ・ Basic requirements for input data references, implementation framework and project management policies, communications with key personnel, boundary of responsibility with concerned parties, etc. that are necessary for design/development. ・ User organizations (centers) in which the system are deployed ・ Existing environment (network diagram, etc.) ・ Network information of superior organizations to be connected (if necessary) ・ Physical prerequisites of the locations where devices are to be installed ・ Technical requirements necessary for network design/development ・ Definition of service level items (if necessary) ・ Implementation plan for design/development ・ Basic design ・Physical design ・Logical design ・Reliability design ・Line design/external connection design ・Security design ・ Detailed design ・ Work diagram and device installation diagram ・ Connection specifications ・ Setting document To specify matters to be carried out by the contractor with respect to network design/construction [1.Basic requirements to be listed] ○Details of an implementation plan for design/development ○Requirements to be met by the design/development contractor (skills, etc.) (if necessary) ○Details of designs (basic design, detailed design, connection design) -To include items to be discussed (detailed setting items. LAN/WAN connection design items, items to be coordinated with individual systems, etc.) ○Details of development -To include notes and requirements for implementing development work -To include requirements for performing tests [2. Requirements to be added depending on type/characteristics of project] ○If there are matters to be coordinated with LAN/WAN connection design or individual systems, etc., the details of procurement of such work shall be specified. ○If removal/disposal of existing equipment and devices is necessary, requirements for such work shall be included. 470 Item Example/explanation of a description in specifications Description Example of descriptions of basic requirements to be specified ○Details of implementation plan for design/development (1) The contractor shall create an implementation plan for design/development which includes an implementation framework of design/development and roles, detailed definition of work and schedule, development environment, development method and development tools, etc., while seeking coordination with the Ministry of ___. (2) The contractor shall carry out design/development work in line with the implementation plan for design/development and shall report the results. ○Requirements to be met by design/construction contractor The manager of design/construction work in this procurement shall meet the following requirements. 《Note: The following describes the requirements for experience in services equivalent to the relevant service, a list of qualifications for an individual or person having a capacity equivalent to the qualifications, and the qualification requirements for an organization. If only persons with qualifications can work due to legal reasons, participation of a qualified person is mandatory whether or not such description is given. Specific details are omitted.》 ○Details of designing (1) Basic design The contractor shall describe the logical configuration and physical configuration, etc. in the basic design after determining specific network services and devices following the final confirmation of requirements for this procurement. Equipment in the center necessary for operation/ maintenance shall also be designed. When designing, the contents shall be consistent throughout the entire network to avoid inconsistency with the existing network which will continue to be used. The following are matters described in the basic design. (Details are omitted.) A. Equipment design (designation of target range) B. Design of IP address (domain design) C. Routing design D. Physical configuration design (designation of target range) E. Logical configuration design (network topology, etc.) F. Line configuration design (backbone line, interchange circuit, access line) G. Design based on the security policy (encryption, FW, IDS/IPS, quarantine) H. Encryption design (encryption specifications, encryption method, encryption algorithm) I. Bandwidth reservation design (bandwidth control specifications, bandwidth control method) 471 Item Description J. Quarantine system design (quarantine specifications, quarantine method) (2) Detailed design The details of setting and setting policies and reasons shall be described in the detailed design with respect to major setting items of devices operated in the relevant network based on the basic design. The following are matters implemented in the detailed design. Items related to server, etc. which is operated together with the network are also described here. (Please also refer to “6.7 Tasks incidental to procurement of devices.”) (Details are omitted.) A. Parameter design for network monitoring (network monitoring parameters, server monitoring parameters) B. Parameter design for network devices (setting values for routers, switches, etc.) C. Detailed design for server devices (configuration of server (redundancy configuration, etc.), storage configuration, software functions (OS, middleware, etc.) and parameter design D. Parameter design for security services (quarantine, etc.) (3) Connection design Physical configuration and setting conditions, etc. shall be clarified in the connection design for the connection with concerned departments, equipment and concerned systems. The following are items to be determined in the connection design. (Details are omitted.) i) Information center A. A method of acceptance for provided services of the existing network operated by the existing operation and maintenance contractor, which will continue to be used. B. Interface specifications C. IP address (domain, etc.) D. Routing design E. Security policy design (filtering conditions) F. Encryption design (encryption range): introduction of encryption with appropriate level of strength based on the government’s guidelines G. Equipment specifications concerning installation and operation ii) ___ System A. The method of the provision of services B. Interface specifications C. IP address (domain, etc.) D. Routing design (allocation of communication paths to the business-oriented network and the information-oriented network) E. Quarantine system design (presence or absence of the quarantine application, scope of quarantine, information on devices subject to quarantine) F. Firewall/IDS/IPS design G. Equipment specifications concerning the network connection of this 472 Item Description system ○Details of development The contractor shall carry out specific construction work based on the applicable design contents. The contractor shall also compile these contents into the products concerning design/construction. The following are matters implemented in the development work. (Details are omitted.) (1) Items of construction work A. Line installation B. Device emplacement/fitting C. Equipment adjustment (unit test) D. Device setting/construction (2) Line installation, device emplacement/fitting The contractor shall carry out line installation, device emplacement, installation and operation verification at the user organization’s location to which the network is connected. The contractor shall provide support for inquires about verification tests conducted by the user after the completion of migration. Examples of requirements to be added depending on type / characteristics of project ○ Examples of listing LAN/WAN connection design and adjustment with individual systems, etc. (1) Existing system user organizations There will be in principle no installation work in the existing system user organization since the speed of the existing line will be increased (instead of installing a new line). (2) Newly connected system user organizations 《Note: Prerequisites and conditions for design and construction shall be specified with respect to the following items, etc.》 ・Securing of site, securing of power source equipment ・Implementation of preparation, installation, securing of power source, and installation of cables running in conduits and devices, etc. ・Coordination with the managers of user organizations and management companies of the relevant LAN ・Prerequisites The following are the physical prerequisites for the installation of devices in each user organization. In the case of user organizations, etc. which cannot adopt the following conditions, the contractor shall carry out the installation upon coordination with the relevant personnel and user organization in accordance with the actual situation of the user organization, etc. (1) Power source conditions -omitted (2) Ventilation conditions -omitted 473 Item Description (3) Installation conditions -omitted ・Specifications of network requirements (Details are omitted.) The area shall be divided into the WAN environment and the center connection environment and detailed requirements for specifications shall be presented based on the network configuration described here (with configuration diagram). (1) WAN environment ・ Communications protocol and routing method ・ Bandwidth reservation ・ Security requirements The contractor shall take measures in line with the “information security policies of the Ministry of ___.” (2) Center connection environment (an environment that connects the new and existing centers via WAN cables, such as wide area Ethernet) ・ Communications protocol and routing system ・ Security requirements If there are matters to be cooperated specifically with the existing operation and maintenance contractor, etc. (method of sharing security information, test methods, emergency measures, etc.), such cooperation shall be described. ○Examples of requirements for removal and disposal of devices (1). Removal and displacement work (details are omitted.) Details of work shall be presented. ・ Removal of unnecessary devices ・ Removal of related cables and lines ・ Clarification of objects not to be removed ・ Concept of bearing expenditures necessary for removal, displacement and disposal (including protective materials, equipment and vehicles, etc.) ・ Creation of a work schedule concerning the dates and frequency of removal/displacement ・ Implementation of necessary protective work (2). Data deletion A. The contractor shall carry out coordination, etc. concerning data deletion upon gaining approval of the relevant official. B. Data shall be completely deleted so as not to be restored by a third party by using data restoration software, etc., once unnecessary devices have been removed and displaced. C. The contractor shall, at its expense and responsibility, prepare places and devices necessary for the data deletion. The contractor shall take strict security measures to prevent information leakage from the unnecessary devices throughout the process, from the removal and displacement of the unnecessary devices to the deletion of data. However, this does not apply if the work is carried out within the 474 Item Notes on characteristics of a project/information system Notes on security Description Ministry. D. Following the completion of data deletion, the contractor shall submit certification of data deletion to the relevant official. (3). Disposal (Details are omitted.) The contractor shall present the details of work and methods. A. The contractor shall observe disposal-related laws and regulations. The work may be re-entrusted (only with notification and approval of the relevant ministry in advance). B. The contractor shall submit the certificate of the completion of disposal after the completion of disposal. C. In the case data deletion work, except for cases of destroying unnecessary devices, if the device is re-commissioned, an approval of the relevant official shall be obtained in advance. D. The Ministry is entitled to carry out inspections of the work. E. The devices may be re-used as used devices. However, an approval shall be obtained in advance. ・ Requirements for a connection with an existing system under given operating conditions shall be appropriately detailed.If there is an existing system to be connected, requirements shall be appropriately specified because it will be in given environmental conditions. ・ If there is an existing network operator, the details of cooperation and conditions shall be appropriately stipulated. ・ The examples of descriptions assume a off-site implementation of data deletion work. However, on-site data deletion should be considered since taking data out of the premise is highly risky under current circumstances. ・ If it is necessary for the proposer to understand the detailed requirements, such as technical requirements and constraints, such statements shall also be included. -User organizations (centers) in which the systems are deployed, or the existing environment -Boundary of responsibility for the procurement -Physical prerequisites in the location where devices, etc. are to be installed. In light of the importance of security, the following requirements / conditions (if any) shall be specified. Information security requirements (measures) The contractor shall take comprehensive security measures, observe security policies and security guidelines issued by the Ministry in order to carry out comprehensive measures recognized as security measures by the market. For operations, the contractor shall maintain the security level. With respect to the security measures to be taken by the entire network, cooperation and coordination shall be taken with the existing operator/maintenance controctor Disposal of devices Except for when destroying unnecessary devices, data shall be 475 Item Description completely deleted so as not to be restored by a third party by using data restoration software, etc., once disposal devices have been removed and displaced. Security design The contractor shall either carry out design work, such as security policy design (encryption, FW, IDS/IPS, quarantine) and encription design (encryption specifications, encription method, encription algorithm), etc. or follow the regulations presented together with the specificaitons. Security inpsection A vulnerability of network devices to be introduced may be identified and disclosed by a third organization, etc. Problems (if any) shall be appropriately addressed. 476 3. Migration plan Item Outline of service operations Description To formulate a plan of work necessary for the migration to a newly constructed network. Suggested input (Prepared by the procurer) Product (Prepared by the contractor) ・ Migration conditions (constraints, etc.) ・ Expected migration work flow Matters to be described in specifications Example /explanation of a description in specifications (1) Migration implementation plan ・Migration schedule ・Communication method during migration ・Migration criteria, etc. (2) Migration procedures The contractor shall specify requirements for the implementation of or support for migration work through the connection of a newly constructed or extended network to the existing network, as well as items necessary for planning, etc. [1. Basic requirements to be listed] ○Policies and requirements for migration ○Details of the formulation of a migration plan [2. Requirements to be added depending on type/characteristics of project] Examples of basic items ○Policies/requirement for migration (Details are omitted.) A. Flexible plan B. Ensuring stable operation and business continuity F. Prompt support for an application connection test, etc. conducted by the user. The procurer shall make requests for the support from the existing operation/maintenance contractor, if necessary. B. Formulation of migration procedures for the manager of the individual system and migration procedures for the manager of the user organization C. Scope of approval from the relevant official and confirmation from the existing operation/maintenance contractor, upon consultation with concerned parties ○Details of the formulation of a migration plan The contractor shall formulate a migration plan with respect to the following items in order to solidly implement migration in a planned manner. A. Migration implementation framework and roles of migration-related companies and contractor B. Detailed work and schedule for migration C. Migration environment D. Migration method 477 Item Notes on characteristics of a project/information system Notes on security Description In cases of a large-scale separate procurement project, the responsibility demarcation may become unclear. Thus, the responsibilities should be clarified in advance by, for example, creating a table of the division of roles. In cases of a large-scale network covering a multiple number of center’s equipment, the installation and connection of termination units may be conducted simultaneously with the migration following the unit and system tests for the equipment of each center. In that case, it may become closer to reality if the items of “line installation, device emplacement/fitting work” in the previous section in the design/construction are included as part of the migration services in this section and the next section. - 478 4. Support for test and migration judgment Item Outline of service operations Description To implement a set of tests before submitting the system to the user in order to confirm that the new network will operate as designed. Suggested input (Prepared by the procurer) Product (Prepared by the contractor) ・Implementation requirements for tests ・Outline of acceptance test (performed by the procurer) ・Migration criteria (or criteria for the acceptance test) ・Test procedures ・Test plan ・Report on test results Provision of services covering from planning to implementation of tests is requested. For details of the test, major test items (draft) to be implemented shall be specified. [1.Basic requirements to be listed] ○Creation of a test plan ○Implementation of test (stating the details of implementation) ○Implementation of progress/issue management ○Report on results ○Support for acceptance test [2. Requirements to be added depending on type/characteristics of project] ○Support for the judgment on switching to a new system and discussion on the possibility of full-fledged operation Examples of basic requirements to be described ○Creation of a test plan The contractor shall create a test implementation plan describing the test framework, detailed tasks and schedule, test environment, test tools and acceptance criteria, etc. ○Implementation of test (description of the implementation details) The contractor shall carry out tests on the new system with respect to the following contents and verify that the system will operate as designed. (Details of tests are omitted.) ・Inter-center test ・Connection test with the business system ・Information security verification test ・Comprehensive test ・Support for operation test (acceptance test, user test) ○Implementation of progress/issue management The contractor shall present management/reporting rules with respect to the progress of tests based on the test plan and operation tasks before the commencement of the tests and gain approval of the Ministry of ___. Consequently, the contractor shall conduct management/reporting in compliance with these rules. ○Report on results The contractor shall compile the test results into a “report on test results” and gain approval from the Ministry of___. Matters to be described in specifications Example/explanation of a description in specifications 479 Item Description ○Support for acceptance test After the completion of the comprehensive test, etc. conducted by the contractor, etc., the Ministry of ___ shall carry out an acceptance test in order to verify that the new system conforms to requirements. The contractor shall provide support for creating an implementation plan for the acceptance test and acceptance test specifications formulated by the Ministry of ___, as well as support for implementing the acceptance test. ・Other (1) If the use of the data, etc. of the existing system is deemed necessary for the tests, the contractor shall make a request to that effect to the Ministry of ___. The Ministry of ___ provides the data, etc. only when it is concluded that there is good reason to do so. The contractor shall handle the provided data, etc. with care. (2) The contractor shall prepare necessary devices and communication lines, etc. for the tests. Notes on characteristics of a project/ information system Notes on security Cases where support for migration judgment is defined as service requirement ○Support for migration judgment Migration judgment is a final decision made by the new network side and related individual system’s side as to whether or not to make a conversion to the new network. To that end, the contractor shall implement the following work based on the instructions of the relevant official, in cooperation with the existing operation/maintenance contractor. A. The contractor shall provide support for the creation of migration criteria that include work status, matters of concern, and verification items for the xx system, etc. B. Based on the migration criteria, the contractor shall hold a “migration judgment conference” attended by the relevant official, the existing operation and maintenance contractor, the relevant contractor, the PMO, and personnel in charge of the management of individual systems, with an aim to reach a consensus on the finalization of the “migration criteria” and on a conversion to a new network of the xx system. 3. Refer to design / development The contractor shall thoroughly implement tests for information security. A vulnerability of the network devices to be installed may be identified and disclosed by a third organization, etc. Problems (if any) shall be appropriately addressed. 480 5. Migration Item Outline of service operations Suggested input (Prepared by the procurer) Product (Prepared by the contractor) Matters to be described in specifications Example / explanation of a description in specifications Notes on characteristics of a project/information system Description To carry out migration ・Division of roles between the procurer and the contractor ・Report on migration results Migration policies, requirements and implementing items shall be described. [1. Basic requirements to be listed] ○Policies for migration implementation ○Details of migration work [2. Requirements to be added depending on type/characteristics of project] Examples of specifications of migration work associated with inter-organization network connections, such as centers and introducing organizations ○Policies on migration implementation A. If the work is suspended due to a failure, etc. during the migration, an initial report shall be made to the concerned parties that may be influenced. The procedures shall be in line with the reporting procedures formulated in the plan. B. When a problem in the existing system occurs through the connection to the network, the concerned parties shall cooperate in the investigation of the cause. If dispatch of staff to the user organization, etc., is deemed necessary, the arrangement and coordination shall be made with the user organization. C. In the cases where it is expected that migration/installation may have an impact on the individual systems under operation, etc., the relevant official and manager of the individual systems shall be informed in advance. D. After the completion of migration/installation, the contractor shall inform the key personnel of the user organization about the completion of work, as well as inform the relevant official and the existing operation/maintenance contractor. E. Expected main business flow is as described in the reference document. If change in the business flow is deemed necessary for the purpose of efficiency, etc., approval of the relevant official shall be obtained. ○Details of migration work ・ In cases of extension of the existing line, the contractor shall consider including such tasks as reporting to the existing operation/maintenance contractor, etc. since use in combination with the existing system is important. ・ The details of the description shall be arranged in accordance with the actual situation, such as the scale of the procured network and the presence or absence of the existing system. 481 Item Notes on security Description - 6. Operation / maintenance plan Item Outline of service operations Suggested input (Prepared by the procurer) Product (Prepared by the contractor) Matters to be described in specifications Description To carry out establishment of the framework, operation design and documents for operation/maintenance. (The network-related maintenance does not generally require specific knowledge and experience; rather, it is deemed more effective to integrate the network maintenance into the operation.) ・Period of introduction/ operation, etc., loan period and payment period ・Configuration management items ・ Configuration management document format ・Security policies concerning network operation ・Operation/ maintenance security manual ・Outline of operation / maintenance ・Operation design ・Operation manual ・Manual for key personnel of the user organization and the manager of individual systems ・Configuration management system or manual ・ Service Level Agreement (SLA) ・ Service level management plan To list items and service requirements for the preparation of initiation of operation/maintenance [1. Basic requirements to be listed] ○ Requirements to be met by the operation/maintenance contractor ○ Basic requirements for operation/maintenance ○Implementation of operation/maintenance design -Operation design -Creation of configuration management (host name, IP address, etc.) and a manual for personnel in charge of maintenance -Formulation of a service level management plan ○Framework and division of roles in operation/maintenance [2. Requirements to be added depending on type/characteristics of project] ○Transfer from the existing operator 482 Item Example / explanation of a description in specifications Description Examples of descriptions of basic items ○Requirements to be met by the operation/maintenance contractor The following requirements shall be met by the manager of operation/maintenance work in this procurement. (5). Security manager Personnel in charge of security management in this procurement shall meet the following requirements. A. A person with experience in planning and implementing measures to maintain information security and evaluating the results. ○Basic requirements for operation/maintenance (1) Establishment of a stable and efficient system operation/ maintenance infrastructure A. Since the operation/maintenance of the overall network is implemented by the existing operation/maintenance contractor, the contractor shall follow the instructions given by the relevant official or the procurement office and act in accordance with the advice of the existing operation/maintenance contractor which assumes the role of an administrator of operation / maintenance. (Details are omitted.) (2) Provision of high quality user support A. The offices providing user support for the relevant procurement will be consolidated into one contact point which is managed by the existing operation/maintenance contractor to facilitate the convenience of the users. The contractor shall act accordingly. (The rest is omitted.) (3) Monitoring and continuous improvement of the quality of services A. Upon coordination with the existing operation / maintenance company, the contractor shall monitor the values of service level items, evaluate the results and report to the relevant official. (The rest is omitted.) (4)Implementation of security management in operation/maintenance work A. The contractor shall observe the security policy of the Ministry of ___ and institute a framework to enable the verification of the compliance with the policy B. The contractor shall implement training/operation based on the security operation manual. C. The contractor shall institute a framework to enable reporting to the relevant official and take the necessary measures in cooperation with the existing operation/maintenance contractor in the case of an occurrence of a security event. 483 Item Description ○Implementation of operation/ maintenance design The contractor shall create the following documents (by implementing operation/maintenance design). (1). Operation/maintenance outline A document equivalent to the “operation/maintenance outline” in the optimization guidelines (2). Basic design for operation A product stipulating the operation framework for the network and operation procedures (3). Operation manual A product stipulating work procedures for key personnel in charge of network operations at the time of using devices and defect occurrence. (5). A manual for the responsible personnel of the user organization and manager of individual systems A product describing settings necessary for the use of the network, operation method and application method for the responsible personnel of the user organization and manager of individual systems (6). Configuration management A product concerning network devices and settings that comprise the network. (9). SLA and service level management plan A document equivalent to the “Service Level Agreement (SLA)” in the optimization guidelines and the service level management plan ○Framework and division of roles in operation/maintenance To specify the expected framework and division of major roles in the operation/ maintenance work Notes on characteristics of a project/information system Notes on security Requirements to be added depending on type/characteristics of the project ○Transfer from the existing operator SLA should be concluded for critical systems. ― 484 7. Operation / maintenance Item Outline of service operations Suggested input (Prepared by the procurer) Product (Prepared by the contractor) Matters to be described in specifications Example/explanation of a description in specifications Description To carry out operations in response to the results of the preparation for initiation of operation/ maintenance (Documents pertaining to operation/ maintenance created in the preparation for initiation of operation / maintenance) Report on the network operation ・ Operation status ・ Incident status ・ Operating performance ・ Expendables status ・ Operation/ maintenance status ・ SLA conformity status, etc. The contractor shall describe services concerning network operations and the implementation requirements, etc. [1.Basic requirements to be listed] ○Configuration management/change management ○Maintenance ○Monitoring ○Defect handling [2. Requirements to be added depending on type/ characteristics of project] ○Requirements in cases where there is an operation / maintenance contractor for the related network system The following examples are based on this assumption. Examples of basic items of operation/maintenance and examples of descriptions in cases where there is an existing operation/ maintenance contractor ○Configuration management/change management Configuration management/change management refers to a series of tasks for maintaining and managing the configuration information to the latest version through changes and relocations of connection settings of the user organizations to which the network is connected. If the implementation tasks need to be entrusted to the existing operation/maintenance contractor, the contractor shall file the application with details of the work to the procurer. (1). Target The target of “configuration management/change management” in this procurement shall be the devices of user organizations (including those modified along with the line speed up) to which the new network is connected and that of new centers, as well as devices newly installed by the contractor. The existing operation/maintenance contractor shall continue the work for the user organization that has simply undergone the line speed up. (2). Job description (Details are omitted) A. Review of configuration management/change management 485 Item Description procedures B. Application for change in network connection (processing of ministerial administrative procedures) C. Coordination for the schedule of change, work details and requested items and creation of an implementation plan D. Preparation for changes according to the type of lines and device changes, when the changes are deemed necessary E. On-site study through coordination with the applicant if necessary F. Network connectivity test G. Handing over the network environment H. When a problem occurs after the transfer of the environment, an investigation of the cause shall be carried out cooperatively I. The period between the update of configuration management information and the maintenance management of the latest configuration shall be less than seven days. ○Maintenance The maintenance work refers to a series of maintenance / inspection work performed when necessary, in order to maintain the network configuration devices. (1). Target The target of “configuration management/ change management” in this procurement shall be the devices of user organizations (including those modified along with the line speed up) to which the new network is connected and to those of new centers, as well as devices installed newly by the contractor. The existing operation/maintenance contractor shall continue the work for the user organization that has simply undergone the line speed up. (2) Job description (Details are omitted.) A. Review of a service implementation plan B. Necessary coordination for the work schedule, work details and requests, C. Network connectivity test D. Handover of the network environment E. Recording/management of maintenance/inspection F. Notification of operation shutdown for maintenance ○Monitoring Since the monitoring needs to be carried out covering the entire network, including the portion in this procurement, from the security viewpoint, the existing operation/maintenance contractor shall monitor the network in a comprehensive manner; such monitoring tasks include the centers constructed in this procurement and user organizations which carry out line speed up or to which a new line is connected. However, the contractor shall carry out monitoring of 486 Item Notes on characteristics of a project / information system Notes on security Description backbone lines provided by the contractor under this procurement. A. The contractor shall establish a communication flow so as to be able to promptly receive defect information on lines from the line provider and take appropriate measures based on this procurement. B. When coordination for settings and thresholds is required, an approval shall be obtained from the relevant official and the concerned parties. The contractor shall also respond to the request for change in settings from the user and carry out such setting adjustment. ○Handling of defect Handling of defects is a series of work related to the recovery of line and devices, etc., which comprise the network. The contractor shall implement the following operations. (1). Target The target of “configuration management / change management” in this procurement shall be the devices of user organizations (including those modified along with the line speed up) to which the new network is connected and to those of new centers, as well as devices installed newly by the contractor. The existing operation/maintenance contractor shall continue the work for the user organization that has simply undergone the line speed up. (2). Job description (Details are omitted.) A. Cooperation with the existing operation/maintenance contractor B. Tasks implemented by the contractor The contractor shall present the requirements for the configuration management, including the management of the existing assets. When commissioning the helpdesk operations in a comprehensive manner to the existing operation/maintenance contractor, the contractor shall be required to provide cooperation so that the existing operation/maintenance contractor can carry out the helpdesk operations smoothly. Handling of incidents To establish a communication flow to enable rapid reception of defect information and security incident information concerning the network. Security diagnosis and reporting Continuous all-time monitoring of the traffic status of lines. In cases of abnormal traffic, etc., the contractor shall conduct an investigation of the cause immediately and report to the relevant official via the existing operation/maintenance contractor. Security inspection The contractor shall take appropriate measures promptly when a vulnerability improvement for the introduced network devices is pointed out. 487 6.9.2.2. Deliverable products and timing of submission The table below lists typical deliverable products and timing of delivery with respect to hardware maintenance services. The official name of each product and its delivery deadline need to be entered in accordance with the actual situation. Service 1. Design/development plan 2. Design/development Deliverable product Delivery deadline Documents concerning the support for By the commencement of formulating design/development plan design/development Design/development implementation plan At the time of formulating Basic design design documents Detailed design Work diagram and device installation diagram Connection specifications Settings 3. Migration plan 4.Support for test and migration judgment Migration implementation plan At the time of formulating Migration procedures the migration plan Testing procedures At the time of formulating Test plan the test plan Report on the test results After the completion of connection test 5.Migration Report on the migration results After the completion of migration 6. Operation/ maintenance plan Outline of operation/maintenance At the time of formulating documents for the Operation design operation/maintenance Operation manual plan Manual for key personnel of user organizations and managers of individual systems Configuration management system or manual SLA, Service level management plan 7.Operation/maintenance Report on network operations Monthly after the commencement of operation 488 6.9.2.3. Suggested input The following table shows input and timing to be presented to the procurer (proposer) in advance. The official name of each product and its delivery deadline should be entered in accordance with the actual situation. Service 1.Design/development plan 2. Design/development Input Timing for presenting input Development schedule At the time of tender publishing Views of ministries Basic requirements At the time of tender publishing User organizations (centers) Existing environment (network Outlined in the specifications, Details diagram, etc.) after the conclusion of the contract Physical prerequisites for device At the time of tender publishing. After installation the conclusion of the contract for some contents Technical requirements for network At the time of tender publishing design/development Definition of service level items (when necessary) 3. Migration plan Migration conditions At the time of tender publishing Expected migration flow 4. Support for test and migration judgment Requirements for testing At the time of tender publishing Outline of acceptance test Migration criteria 5.Migration Division of roles between the At the time of tender publishing procurer and the contractor 6. Operation/ Period of introduction/operation, etc., maintenance plan loan period, payment period At the time of tender publishing Configuration management items Configuration management After the conclusion of the contract document format 7. (Documents concerning operation/ Operation/maintenance maintenance created in the preparation for the initiation of operation/maintenance) 489 At the time of tender publishing Examples of the definition of the service level items: All the items and setting values presented here are just examples and nothing more, and the actual procurement should be based on sufficient discussions and consent. 1) Service level items (excerpt) Network devices are regarded as a service level item since they have a wide area of influence at the time of an occurrence of a defect and are highly important. The following shows that the target and the evaluation unit (separately stipulated) is set by a service. A. Network devices that are components of the internet connection B. Network devices that are components of the internal connection Service level item Availability Description Setting value The proportion of actual operating time More than 99.9% (operating hours) to expected operating time Mean Time to The average monthly time spent on recovery of Repair (MTTR) devices from the time of an occurrence of a Within one hour defect during the service operation hours Mean Time The average time elapsed from one failure of a More than 2920 hours between Failures device to the next. (four months) (MTBF) Service level items concerning initial response to defect/inquiry Service level item Description Setting value Lead time from the Time spent from the occurrence of occurrence of a the defect /inquiry during the defect/inquiry to the initial helpdesk operation hours to reporting response on understanding of the status and With 15 minutes initial response, etc. to the relevant official and the concerned users. (2) Provisions concerning SLA compliance The objective of Service Level Management (SLA) is to achieve, maintain and improve the service level that is required for the operations in cooperation between the relevant official and the contractor. Thus, in the cases where the target value set in the SLA has not been achieved, the contractor should attain the service level by making further efforts for improvements in cooperation with the relevant official. In the case of a service that provides infrastructures having a great impact on the information system whose users are the general public, is the people on the social infrastructure, and on the entire system, a fine shall be imposed if the service level target has not been achieved, considering its significance. (Penalty and incentive based on the 490 SLM settings and the SLM implementation). (3) Concept of penalties and incentives A. Ninety percent of the bid price will be considered as a basic fee award and the rest 10 percent as a contingency bonus in accordance with the status of the SLA compliance. The evaluation shall be conducted based on the monthly report on the SLA achievement, and the monthly award shall be paid by adding the amount in accordance with the “degree of attainment” to the basic fee award. B. With respect to the service level items, the status of achievement of service level setting values for each service and device shall be evaluated every month. According to the number of unattained items of the service level setting value, the “degree of attainment” of a given month shall be evaluated on a 4-point rating scale. (4) SLA evaluation period The compliance to the SLA shall be measured from the date of commencement of operations. However, the fluctuation of the amount of pay shall commence on the third month after the start of the service. (5) Measures for the cases where the service level target value continues to be unattained A. Damage claim If the cause of extremely low SLA compliance rate without expectation of improvements is attributable to the contractor, a damage clam may be separately filed, which shall not exceed the ceiling price set forth in the contract. The following are the criteria for the period and frequency of the extremely low SLA compliance. a. The status of “Grade D” continues for “more than three consecutive months,” “more than four times a year” or “total of 12 times during the operation.” b. The status of “Grade C” continues for “more than five consecutive months,” “more than six times a year” or “total of 18 times during the operation.” c. In cases where damage occurs exceeding the amount of the contingency bonus, which is 10% of the bid price, due to discontinuity of business caused by defect, etc. B. Deprivation of eligibility for bidding In cases falling under the situation A above, the contractor shall be considered as having no capacity to provide the quality of service level required by the Ministry, and may potentially be subject to deprivation of eligibility for bidding for a certain period of time, rescission of the contract, imposition of a penalty, including suspension of eligibility for bidding at the time of the next contract renewal. 491 6.9.2.4. Division of roles The following are the examples of the division of roles between the user and the network operator in the operation and maintenance in cases where the procurement is carried out in combination with the existing network. System Individual system manager User Person in charge of the user organization Contractor Consolidated network operating body Existing operation/ maintenance contractor Relevant official (including the process Major roles ・ The responsible personnel of each system serving as a liaison for the coordination with the operating body ・ Responsible for attendance at work and support in the separation of a defect and investigation of the cause ・ The responsible personnel of the user organization serving as a liaison for the coordination with the operating body ・ Responsible for the environment development for the user organization, attendance at work, support for defects, etc. ・ To cooperate in creating an operation/maintenance plan (developing implementation procedures manual, etc.) ・ To carry out configuration management/change management, maintenance, defect response and regular reporting in line with the operation / maintenance plan ・ To carry out monitoring, evaluation, analysis and improvement of monitoring items for the quality of services ・ To provide information to the existing operation/maintenance contractor in order to report the implementation status to the operating body (the relevant official) ・ To control and manage operation/ maintenance ・ To formulate an operation/ management plan (implementation procedures, manual development, scheduling, etc.) ・ To carry out configuration management/change management, maintenance, monitoring, defect response, helpdesk operations, and regular reporting, in line with the operation/maintenance plan. ・ To carry out monitoring, evaluation, analysis and improvement of monitoring items for the quality of services ・ To report the implementation status to the operating body (relevant official) ・To make decisions and give final approval in operation/ maintenance as the operating body Remarks Allocated to each system Allocated to each user organization Assignment regarding the scope of the contract About two persons (excluding the process management support management support contractor) contractor) 492 Examples of the division of roles between the existing network operation contractor and the contractor in the operation and maintenance in cases where the procurement is carried out in combination with the existing network No. 1 2 Item Operation control Description overall operations for operation/ existing operation/ contractor maintenance (section of the scope of contractor the order received) ○ × ○ ○ ○ ○ maintenance Response to applications management/ concerning network and management Services of the Control and management of the Configuration change Services of the configuration/change management Maintenance for devices that 3 Maintenance constitute the network when necessary Monitoring the operation status of 4 Monitoring lines and devices that constitute ○ the network 5 6 Helpdesk operations Defect response Reporting on operation/mana 7 gement implementation status 8 Security management △ (Monitoring of backbone lines only) Response to inquiries and provision of information about the ○ × ○ ○ ○ ○ network Repair and recovery of defects in lines and devices that constitute the network Regular reporting to the network operating body of the overall status, SLA achievement status, and quality monitoring in operation/monitoring work Security maintenance of the ○ network 493 △ (Response to security incident) 6.9.3. Services concerning procurement of communications services 6.9.3.1. Services to be listed in specifications 6.9.3.1.1. Typical service operations Chapter and section Service of specifications Outline of service operations Activities of SLCP-2007 operations corresponding to BGP 1.Preparation for Creation of schedule 3.2.1 Chapter II (4), (5) installation Coordination with ministries on Preparation for initiation of process Chapter IV the implementation procedures (environment development) Chapter V 2.Installation Preparation for preliminary study, Chapter VI etc. Chapter X Work necessary for service 2.2 Construction of environment provision, etc. 2.3.1 Chapter XI Preparation of initiation of quality assurance process 3.Operations Operation/maintenance for 1.7.7 Chapter V (5) management/ sustainable service provision Evaluation of system operation Chapter X 1.8.2 Chapter XI Problem identification and Chapter XII maintenance modification analysis 1.8.3 Implementation of modification 4.Reporting Regular reporting associated 1.7.4.1System operation with network service operation 1.7.4.2 Operation monitoring and collection of operation data Detecting, recording and solving problems, Improvement of operation environment 1.7.4.3 Identification and improvement of problems 1.7.4.4 Improvement of operation environment 1.7.7 Evaluation of system operation 494 6.9.3.1.2. Explanations and examples of descriptions in specifications concerning services 1. Preparation for installation Item Outline of service operations Suggested input (Prepared by the procurer) Product (Prepared by the contractor) Matters to be described in specifications Example/explanation of a description in specifications Description To carry out preparation work, such as creation of schedule, coordination with ministries on the implementation procedures and preliminary study, etc. ・Outline of schedule ・Function specifications ・List of centers to which the system is introduced ・ Plan views indicating scheduled locations of device installation (ODU, distribution board, etc.) and scheduled locations of piping and wiring routes of power source lines/communications cables. ・Detailed installation schedule ・Report on on-site studies in the building To specify items of preparation for communication service introduction to be carried out by the contractor [1. Basic requirements to be listed] ○The contractor shall determine the installation schedule and implement coordination with ministries. -Basic requirements and notes for the installation shall also be specified. ○Implementation of a preliminary study ○Period and location of provision [2. Requirements to be added depending on type/ characteristics of project] ○Function specifications for the network service to be procured shall be specified. Examples of procurement specifications in cases of service procurement ○The contractor shall determine the installation schedule and implement coordination with ministries. ・ The outline of the schedule shall follow the “draft of installation schedule,” and the detailed installation schedule shall be fixed within 10 days after the successful bid upon consultation with the relevant official. However, dates are subject to change upon consultation between the Ministry and the contractor in the case of unavoidable circumstances. The contractor shall make necessary coordination with the ___ system vendor. ○Implementation of a preliminary study ・ The contractor shall carry out on-site studies (specifically, confirmation of following matters: installation method and routes of the cables in the building, presence or absence of documents to be submitted, presence of absence of the specific building management contractor, and necessity of work on the building, such as piping work) in the building of each center of the Ministry and submit a report on the studies in writing with elevation views and plan views of the studied locations to the relevant official. 495 Item Description The contractor shall make a request to the relevant official at this point of time for the submission of documents, if there are any documents to be submitted by the Ministry. ・ Estimates shall be separately submitted if the study finds it necessary to carry out incidental work on the installation, such as piping work in the building, etc. Examples of function specifications of network services to be procured ○Function specifications (1) Internet connection service (Details are omitted.) The contractor shall provide the internet connection that meets the following specifications as an internet service provider (hereinafter referred to as “ISP”) (i) Bandwidth (ii) Interface at the time of transfer to the Ministry (iii) Requirements as ISP (v) Proxy application for domains (viii) Allocation for IP addresses (xi) Secondary DNS service, etc. (xii) Conditions for an access line between the interchange point of the contractor and the Ministry, etc. (xv) Conditions for fees, such as a communication fee in cases of changes in service bandwidth and line types of the internet connection service. (2) WAN cable (wide area Ethernet service) All of the following requirements shall be met for the provision of a network of the wide area Ethernet service covering all centers of the head office and local branch offices of the Ministry of ___. Please refer to the “list of locations and bandwidth of each center” for the location and connection bandwidths of centers. (Details of requirements are omitted.) (3) Connection to ___ system (Details are omitted.) Notes on characteristics of a project/information system Notes on security ○Period and location of provision (1) Period of provision Date: From M/D/Y to M/D/Y (2) Location of provision Internet connection service: Within the computer center of the Ministry of ___ Wide area Ethernet service: Refer to the “list of locations and bandwidth of each center” In cases where there are existing LAN and WAN services, or where other related systems are procured at the same time, the contractor shall specify matters to be specially coordinated in the implementation of installation work. - 496 2. Installation Item Outline of service operations Suggested input (Prepared by the procurer) Product (Prepared by the contractor) Matters to be described in specifications Example/explanation of a description in specifications Description To carry out the work necessary for the provision of services - ・ Report on the results of installation ・ Work diagram [diagrams indicating the locations of devices (ODU, distribution boards, etc.) and locations of the cable routes] The contractor shall specify matters to be carried out by the contractor with respect to the installation of the communication services [1. Basic requirements to be listed] ○Details of installation and notes ○Items requiring coordination, etc. [2. Requirements to be added depending on type/ characteristics of project] Examples of procurement specifications in cases of procurement of internet connection services and wide area Ethernet services ○Details of introduction work and notes ・ In cases where defects occur in ___ system, internet connection services or WAN of the Ministry of ___ and such defects are attributable to the contractor in relation to the relevant work, the contractor, at its expense, shall provide alternative functions. ・ The contractor shall create a table of the operation flow and a defect response manual by the day of commencement of the communication services and gain the approval of the relevant official. If there is light work that can be carried out by the relevant official for a prompt recovery from the defect, the details of such work shall be described in the manual. ・ The contractor shall establish a framework to enable the relevant official to check on the performance of the contract at all times ・ In cases where the provision of internet connection services and wide area Ethernet services is not ready by the scheduled date of commencement, which is attributable to the contractor, the contractor shall either continue using the existing WAN cable or internet connection under the current contract with the Ministry or present an alternative plan, and take measures upon gaining approval of the relevant official. All the costs necessary for the measures shall be borne by the contractor. ○Items requiring coordination, etc. ・ The contractor, when starting work at the centers of the 497 Item Notes on characteristics of a project/information system Notes on security Description Ministry, shall take statutory procedures (if necessary) to the government offices and inform the relevant official about the completion of the procedures. ・ Compensation for damages to the third party during work, such as damages to buildings and roads, land devastation, etc. shall all be borne by the contractor. ・ When entering the centers of the Ministry to carry out work, the contractor shall submit written documents indicating the details and scope of the work, the number of workmen, work schedule, and vehicles to be used for work to the relevant official two weeks in advance of the start of the work and obtain approval. In cases where there are existing LAN and WAN services, or where other related systems are procured at the same time, the contractor shall specify matters to be specially coordinated in the implementation of installation. - 498 3. Operation management/maintenance Item Outline of service operations Suggested input (Prepared by the procurer) Product (Prepared by the contractor) Description To carry out operation management/maintenance for sustainable service provision Service level items (when the conclusion of an SLA is required) Operation requirements Matters to be described in specifications The contractor shall describe matters to be carried out by the contractor associated with operation management/maintenance of communications services [1.Basic requirements to be listed] ○Details of operations management/maintenance ○Notes in operation [2. Requirements to be added depending on type/ characteristics of project] Examples of procurement specifications in cases of service procurement ○Details of operations management/maintenance ・ The contractor shall establish a framework of network monitoring and defect response on a 24-hour, seven-days-a-week basis. In view of early detection and rapid recovery from defects, monitoring and defect response services for the internet connection and wide area Ethernet shall be consolidated into one contact point. ・ In cases where the system suspension continues for more than five minutes, in principle, after the detection of a defect, the contractor shall notify the relevant official immediately. The contractor shall also report the status to the relevant official every 30 minutes, in principle, until the system is recovered, except if instructed otherwise by the relevant official. ・ In preparation for the occurrence of a defect, the contractor shall establish a framework enabling defect repair and recovery on a 24-hour, seven-days-a week basis. When a defect is detected, the contractor shall exert efforts for rapid recovery to comply with the SLA. ・ When a defect occurs, the contractor shall, at its expense, take appropriate measures to prevent recurrence. Example/explanation of a description in specifications - ○Notes on operation work ・ When conducting scheduled work and regular maintenance, the contractor shall make efforts to avoid network shutdown as much as possible. If the shutdown is deemed necessary during scheduled work and regular maintenance, the contractor shall notify and gain approval of relevant official at least two weeks prior to the shutdown. 499 Item Notes on characteristics of a project/information system Notes on security Description ・ If it is obvious that a continuation of system operation will result in a defect, and thus an emergency shutdown is required, the contractor shall decide on the response upon consultation with the relevant official. The contractor shall consider making a particular request for consolidation of monitoring and defect response services, depending on the status of the system. - 500 4. Reporting Item Outline of service operations Suggested input (Prepared by the procurer) Product (Prepared by the contractor) Description To carry out regular reporting associated with the network service operations Matters be described in specifications The contractor shall describe matters to be carried out by the contractor with respect to the report on communications service operations [1. Basic requirements to be listed] ○Details of report [2. Requirements to be added depending on type/ characteristics of project] Examples of procurement specifications in cases of service procurement ○Details of report ・ The contractor shall provide the internet connection services in Web forms or CSV forms, which allows mail attachment so as to enable only the relevant officer to confirm the traffic information of the previous month at the beginning of each month. With respect to wide area Ethernet services, the contractor shall prepare a framework which enables only the relevant official to confirm the traffic information of each line in a graphic form on a daily, weekly, and monthly basis on a website. ・ The contractor shall hold a briefing session every month, in principle, in which the personnel with a thorough knowledge of internet connection services and wide area Ethernet services of the Ministry informs the relevant officer about the achievement status of the service level items and defect responses for the previous month. When some SLA items are unachieved, the cause shall be analyzed and reported to the relevant official, and measures to improve services shall be discussed on an as needed basis. Example/explanation of a description in specifications Notes on characteristics of a project/information system Notes on security - ・Operation report ・Report on SLA achievement status If reporting on the reliability of the connection with related systems is deemed necessary, such matters shall be entered in the specifications - 501 6.9.3.2. Deliverable products and timing of submission The table below lists typical deliverable products and timing of delivery with respect to hardware maintenance services. The official name of each product and its delivery deadline need to be entered in accordance with the actual situation. Service Deliverable product Delivery deadline 1. Preparation for Detailed introduction schedule Within 10 days after successful bid installation Report on on-site study of the building After the implementation of the on-site study on preparation for introduction 2.Installation Report on the results of introduction At the time of completion of introduction ― 3.Operation ― management/maintenance 4.Report Operation report On a monthly or as needed basis after the Report on SLA achievement status commencement of operations 6.9.3.3.Suggested input The following table shows input and timing to be presented to the procurer (proposer) in advance. The official name of each product and its delivery deadline should be entered in accordance with the actual situation. Service 1.Preparation for Input Outline of schedule Timing for presenting input Included in procurement specifications or as an attachment at the time of tender publishing installation Function specifications Included in procurement specifications or as an attachment at the time of tender publishing List of introduction centers Included in procurement specifications or as an attachment at the time of tender publishing 2.Installation 3. Operation ― Service level item management/ ― Included in procurement specifications or as an attachment at the time of tender publishing maintenance 4.Report ― ― 502 Examples of descriptions of service level items: 5. SLA (1) The network covering from the Ministry to the Internet eXchange (IX) and the network comprising the WAN of the Ministry of ___ shall have high reliability and the availability of the backbone and the monthly availability of every access line provided shall be over 99.9%, respectively. (2) The definition of the availability is shown below. In the internet connection service, “availability” refers to the network availability which covers from the Ministry to ___. In the wide area Ethernet service, “availability” refers to the network availability of the backbone of the wide area Ethernet service and the availability of the access line network in each center to which the WAN of the Ministry of ___ is connected. The defined availability is the percentage of time of actual operation to the agreed service time in a month and is calculated in the following way. The scheduled operating time is, in principle, the time obtained by multiplying the days of a given month by 24 (hours) and the total down time refers to the accumulated time per month of experiencing performance problems in receiving or sending data. Availability (%) = (Scheduled operating time – total downtime) ÷ scheduled operating time × 100 (3) The time of occurrence of a defect refers to either the time when the contractor has detected the defect or the time when the relevant official of the Ministry (hereinafter referred to “the relevant official”) has informed the contractor about the defect, whichever happens first. (4) The period of a system shutdown which is not attributed to the contractor or due to scheduled work or regular maintenance shall not be considered as downtime in the availability calculations. (5) If it is obvious that a continuation of a system operation will result in a defect and thus an emergency shutdown is required, the period of time of emergency shutdown shall be considered as downtime in availability calculations. (6) Other items related to the SLA shall, in principle, be in compliance with the SLA stipulated in the service agreement of the contractor. The contractor shall submit the SLA stipulated in the service agreement at the time of making proposals. (7) If the business continuity is ensured by line redundancy, etc. even when the lines are down, such a period shall not be considered as downtime in availability calculations. 503 6.10. Cloud service Please refer to “4.8 Standpoints of Cloud Users” for this section 504 6.11. Cloud construction Please refer to “4.9 Standpoints of Cloud Integration” for this section 505 6.12. Security 6.12.1.Definition of procurement area Unlike other sections in this Chapter, the security section refers to the indispensable security features (security notes) in the procurement of each service. The security notes provide the essentials to be implemented in the procurement of information systems, as well as security matters in each service of the procurement area. This section also includes the use of “the security by design (SBD) as a measure to ensure information security of e-Government from the stages of planning and design” and “system design for the risk factor reference model (RM) analysis,” which are specific security approaches to be used in information system integration. Planning phase Requirements definition 要件定義 phase Operation/maintenance 運用・保守フェーズ phase Development phase 開発フェーズ 6.2 6.2.3 Support for ( 等) procurement (Project management, etc.) 6.3 6.4 運用 6.4 Operation 6.5 Helpdesk 6.1 Support 6.1全体計画 for master 策定支援 plan formulation 6.2.2 Support for procurement 6.2 1 調達支援 (requirements ( 等) definition, etc.) 6.3 System integration (design/development) 6.3 ハードウェア更改 6.3 機能追加 6.6 Maintenance 6.7 Tasks incidental to procurement of devices Hardware maintenance Software maintenance Application maintenance System infrastructure maintenance 6.8 Tasks incidental to procurement of iDC equipment ・ 設備) 6.9 Network procurement 6.12 Security Figure 6.12-1 Items corresponding to the areas of procurement of services 506 6.12.2. Notes on security to be commonly listed in specifications 6.12.2.1. Notes on security commonly applied to the procurement of information systems Basically, security notes to be followed uniformly by each service domain means the compliance with laws and regulations and the conformity to standards, policies and guidelines, etc. The contractor should give careful consideration to the contents listed in 1-5 when performing each work task. All the constraints as requirements for bidding should be listed comprehensively. Standards, policies and guidelines, etc. to be conformed to should be disclosed to the bidders during the tender. Notes Outline of notes Points of description 1. Conformity to the The contractor shall conform to the The contractor shall indicate the conformity to “Standards for “Standards for Information Security the standards mentioned in the left column in Information Security Measures for the Central the section of the “security requirements,” in Measures for the Government Computer Systems” cases where specifications are created in Central Government (Decision by the Information Security pursuant to the Basic Guidelines for Computer Systems” Policy Council) Government Procurement Related to Information Systems 2. Conformity to The contractor shall conform to the The contractor shall indicate the conformity to security policies information security policies issued the standards mentioned in the left column in issued by each by each ministry in pursuant to the the section of the “security requirements,” in ministry above-mentioned “Standards for cases where specifications are created in Information Security Measures for pursuant to the Basic Guidelines for the Government Procurement Related to Central Government Computer Information Systems. Systems” (Decision by the If the policies mentioned in the left column Information Security Policy Council) are disclosed after the conclusion of confidentiality agreement, such matters shall also be mentioned. 3. Compliance with The contractor shall comply with The contractor shall list laws and regulations laws and regulations, laws and regulations concerning the concerning the relevant information systems etc. relevant procurement projects, and operations and indicate the conformity to including the Act concerning such laws and regulations. Protection of Personal Information, the Penal Code, the Copyright Act, and the Unauthorized Computer Access Law, etc. 4. Conformity to If there are any guidelines to be The contractor shall identify the guidelines to other guidelines followed and handled by the be conformed to, besides the items from 1 to contractor, besides the items from 1 3, in accordance with the details of the to 3, the contractor shall conform to information system. The specifications shall the relevant guidelines. state the conformity to the guidelines and proposals to realize the guidelines are required. 5. Application of If a part of the service is reconsigned If there is an option of reconsigning a part of security policies to upon gaining approval from the the service, a statement shall be included to reconsigned party relevant ministry, the reconsigned the effect that the reconsigned party shall party shall conform to the regulations observe the regulations in the same manner in the same manner as the as the contractor. contractor. 507 6.12.2.2. Standards/guidelines used as a reference “Standards for Information Security Measures for the Central Government Computer Systems” (4th ed.) (Revision FY 2009) (May 11, 2010 - Decision by the Information Security Policy Council) http://www.nisc.go.jp/active/general/pdf/K303-091.pdf 6.12.3. Use of the security by design (SBD) as a measure to ensure information security of e-Government from the stages of planning and design The National Information Security Center, in response to the request from the Information Security Policy Council, has established and hosted the “committee for the security by design (SBD) as a measure to ensure information security of e-Government from the stages of planning and design (hereinafter referred to as the “SBD committee”)” comprising experts and vendors with experience and knowledge. The SBD committee formulated the “Manual for the Formulation of Requirements for Information Systems in Government” (hereinafter referred to as “the Manual”) with an aim to reduce inconvenience to both procurers and suppliers of information systems due to vague procurement specifications, allowing the integrated implementation of appropriate security measures. The Manual covers the entire procurement of information systems to be newly constructed or revised by government organizations and expects that the government’s administrative officials in charge of procurement of information systems in particular, will be able to formulate security requirements using the Manual at their responsibility and enter relevant requirements in the procurement specifications. It is also expected that information system suppliers will have access to information (information on formulation process, etc.) in the Manual which will help them understand the security requirements described in the procurement specifications. At the time of the induction of requirements, it is expected to ensure appropriate security measures meeting needs by describing significant and effective requirements in the procurement specifications in a prioritized and emphasized manner, based on the measures for information protection in information systems and the measures against security breaches. 6.12.3.1. Preparation for the induction of security requirements (creation of system schematic diagram and detailing of requirements) Firstly, the Manual provides explanation on the induction procedures of operation requirements and system requirements necessary for security requirements. In these procedures, the personnel in charge of procurement examines operations related to the information system to be procured, endorses an operating entity, information and environment for each operation, and creates a system schematic diagram. Then, the personnel in charge select operation and system requirements, upon ensuring a certain level of quality or higher, through answering standardized questions based on the created system schematic diagram. 508 Procedure Outline 1. Examining the objectives and The relevant personnel shall coordinate objectives and operations (operation operations flow, related documents, etc.) of the information system to be procured through internal discussions. 2. Examining entities related to The relevant personnel shall examine the entities (personnel, organizations operations and information systems, etc.) of each operation 3. Examining information to be The relevant personnel shall examine the entities and information to be handled handled by each operation and its flow. 4. Deciding the target of information The relevant personnel shall clarify the target range of the systematization systematization and examine the relationship if a given system operates in combination with other systems. 5. Deciding the environment used in The relevant personnel shall decide on the environment (terminals and lines, operations of information etc.) in which the operating entity uses the relevant system. systematization 6. Creation of a system schematic The relevant personnel shall create a system schematic diagram based on diagram the results of the above and in line with certain rules for description. 7. Detailing requirements by The relevant personnel shall detail the requirements for the target system standardized questions from three perspectives: namely, “entity,” “information,” and “user environment/method” by answering standardized questions, based on the system schematic diagram. Individuals [User environment] - Network computer/ cellular phone [Information registration on the website] - Public information 1 - Business information 1 [User registration] - Personal information 1 - Personal information 2 [Browsing opinions and comments] - Public information 1 - Personal information 3 Open website system of the Ministry [Website browsing] - Personal information 1 - Personal information 3 Internet Persons on business trip/subscribers [User environment] - Cellular phone, mobile PC [Legend] [Name of the behavior] - Information - Information Name of the entity Name of the entity [Storage] - Personal information 1 - Personal information 2 - Business information 1 - Business information 2 [Information registration on the website] - Business information 1 - Business information 2 Government information network [Information registration on the website] - Public information 2 - Business information 2 Employees of the branch offices, etc. [Website browsing] - Public information 2 [Website browsing] - Business information 1 - Personal information 3 [Input] - Public information 3 - Personal information 3 - Business information 3 Employees of the Ministry(Agency) headquarters [Output] - Business information 1 - Business information 2 Cooperation system with external sources [Input on the website] - Configuration information Exclusive network [Notification via email] - Warning information [Downloading on the website] - System data System administrator [Name of the behavior] User - Information environment- Information /method Figure 6.12.2 System schematic diagram 6.12.3.2. Decision on requirements for measures Next, this section provides explanation on the examination of the direction of measures (policy of measures) based on the decision criteria (criteria for making decisions on the requirements for desirable measures to be implemented with priority) as procedures for the induction of security requirements using the operation results described above (information examined), as well as being based on the method of deciding the requirements for specific measures conforming to the relevant policy of measures. 509 Procedure Outline 1. Examination of policy of The relevant personnel shall examine the direction of measures (policy of measures measures to be implemented with priority) by applying decision criteria to the requirements selected through the system schematic diagram and standardized questions. 2. Decision on the requirements The relevant personnel shall make a decision on specific requirements for for measures measures that comply with the predetermined policy of measures, while giving consideration to costs, etc. 3. Feedback on the procurement The relevant personnel shall provide feedback for the above results on the specifications procurement specifications 6.12.3.3. Other The “Manual for the Formulation of Requirements for Information System in Government” (the Manual) lists the requirements obtained through the above-mentioned process. Although it is not directly applied to the actual requirements for measures, it includes the task of describing, in the specifications, the information (e.g. scale of the entity, etc.) deemed useful for the bidding company’s proposal (discussion). The Appendix of the Manual includes explanation on the requirements for measures (method of entering the requirements for measures, assumed threats and examples of implementation, etc.), correspondence between the compliance items of the Government’s Standards and requirements for measures in the Manual, and reference documents for the implementation of tasks. As described above, the use of the Manual is important for assisting the personnel in charge of procurement (person engaged in administrative affairs) to make a decision on appropriate security measures for the information system to be procured. It is also expected that the supplier of the information system will have access to this information (information on the formulation process, etc.) that helps them to understand the security requirements listed in the procurement specifications. 510 6.12.4. Use of the risk factor reference model (RM) analysis for system design, etc. 6.12.4.1. The relations between “existing standards” and “RM design requirements” and the basics of usage Each item in the “requirements for measures for RM design to avoid ultimate impact on organizational operations” analyzed with the RM can be considered as specific requirements for design measures corresponding to the security management measures in the existing standards, etc. Thus, application to the function requirements/test requirements at the time of contracting will secure the compliance under the contract with the existing standards, etc. Since the “requirements for measures for RM design to avoid ultimate impact on organizational operations” are the design measures derived from the definition of a “cyber attack threat model (attack scenario),” it is expected to be used as a test scenario at the time of contract. This allows focus on the confirmation of quality and vulnerability of the functions necessary for the avoidance of an ultimate impact on organizational operations, leading to improvements in cost performance. Def inition of cyber attack threat model (attack scenario) Existing standards, Corresponding etc. items Requirements f or measures f or RM design to avoid ultimate impact on organizational operations Contract compliance Figure 6.12.-3 Function requirements/test requirements (specif ications) at the time of placing an order Relations between the existing standards and requirements for measures for RM design A serious issue in the requirement definition and creation of security measures for information systems is that discussions with concerned parties, such as the customers and contractors, etc., must take place at a level of high expertise in the realm of security, which is a non-functional requirement. Thus, RM provides a framework where both customer and contractor are able to discuss security measures for information systems with common standards, with an aim of reaching consensus on the necessity of implementation of specific measures and the confirmation of design functions based on the shared awareness of the issues among concerned parties in each stage, which is then intended 511 to improve the precision of the cost estimates and requirements. Objectives of the risk factor reference model The risk factor reference model was developed to enable the customer and the contractor for the information system to examine and consider security measures to be incorporated in the system based on actual threats. This model aims to design security measures necessary for the information system under the shared understanding of customers and contractors of the public and private information system integration. The following table shows the process in each stage of the system procurement as a premise for the discussion on RM. Process Details of implementation Basics of using RM ○At the time of placing an order 1.Presentation of system f unction requirements and other requirements (customer) Establishment of operation requirements f or the entire system 2. Realistic and specif ic system conf iguration (contractor candidate) Establishment of f unction configuration requirements f or the entire system 3. Identif ication of threats and inf ormation sharing (customer & contractor candidate) Def inition of cyber attack threat model (attack scenario) 4. Comprehension of impact on operations and understanding of ef f ects of design measures (customer & contractor candidate) Understanding of the impact of cyber attack threat model (attack scenario) on system f unctions 5. Discussion on items of measures f or system (customer & contractor candidate) Discussions on the possibility of preventing the impact of cyber attack threat model (attack scenario) on system f unctions 6. Identif ication of f unction requirements/test requirements (specif ications) at the time of placing an order List of f unction requirements/test requirements determined in the above Use of RM cyber attack threat model (attack scenario) Requesting the contractor candidate f or explanation Use of the f ollowing: - Cyber attack threat model (attack scenario) - Requirements f or measures f or RM design to prevent ultimate impact on organizational operations ○At the time of the system production 7. Expansion to system design/test Expansion to basic system design, production, test, etc., based on the results analyzed during the order placement process The contractor shall implement the following: - Design based on the requirements for measures for RM design - Correction and test on related vulnerabilities based on the attack scenario Standard operation procedures as a premise for the discussion on RM are as follows. The following image shows a standard communication flow between the customer who demands 512 a system using the risk factor reference model and the system vendor who proposes a specific system and receives an order. Such a communication flow can be incorporated into a part of a bigger flow implemented, usually at the time of designing a relatively large-scale system, regardless of whether it is public or private. Figure 6.12-4 Standard operation procedures of RM In addition, the following show cases of the use of this model for the response to incidents as an application of RM. The risk factor reference model has prepared patterns of target threat and patterns of system topology to produce a threat catalogue. This allows an understanding of how each target threat behaves in the system and where problematic phenomena occur. Therefore, when an existing system is attacked, this can be used for identifying where in the system the problem has occurred and provide considerations for taking temporary measures for the system, such as bypass measures for the attacked site, etc. ○Assessment of impact on the system at the time of obtaining attack information It is used for consideration of impact on the system, the presence or absence of bypass design, impact on the organizational activities, establishment of temporary measures and planning of measures in case of cyber attack. 513 RM users Identification of reference parts from the basic system configuration At the time of occurrence of cyber attack Topology basic diagram Basic diagram (internet connection type) Catalog of serious threats Impact on own organization and what is the phenomenon on the system (what happens)? Refer to the “attack specifications and effective design measures” and identify the relevant system applicable to the attack on the server. Consider the impact on organizational activities. If the part “as long as this line of communication is blocked, the system at least is protected” is covered, the system will not fall under the status of “attainment of objective of the attack (the worst case scenario).” Schematic diagram for patterns Behavior diagram Attack specifications Result of trace analysis Effective design measures Cases Basic reference model Consideration for the provisional measures, etc. Organizational issues Other, use of usable confirmation tool, etc. ■ MyJNY version checker ■ MyJYN security settings checker RM Various arrangements/discussions and decisions on provisional measures (including the number of processes) Figure 6.12-5 Example of the use of obtained attach information for impact assessment 6.12.4.2. Concept of inducing requirements for RM design measures The risk factor reference model is considered to be a major security measure. Behind this lies the fact that the effectiveness of the design method to allocate security products within the information system has significantly declined due to the emergence of new methods of cyber attacks, such as a targeted attack. In order to resolve this situation, RM has been developed as a method for evaluating the impact on operations and clarifying necessary measures and costs, based on the reality of the current cyber threats. 514 Threat Risk Problem ? Management measurers Ground for countermeasures? System design/management measurers (Full-fledged approach to the specifically described awareness of the issue) Guideline (policy level) Necessary costs (Can the full-fledged implementation of management measurers cover present threats?) Possible feedback to management measures (particularly to CND section) RM Ground for countermeasures? Threat Risk Problem Implementation reference Clarification of the issues and measures System design/management measurers Necessary costs (Priority response to necessary parts in accordance with the awareness of the issue – increased effectiveness) Ground for countermeas ures Implementation with variation (increased cost performance) CND: Computer Network Defense Figure 6.12-6 Cost performance of RM The following shows each analysis component (1-4) of the risk factor reference model (RM). The RM analyzes cyber threats to the information system in organizations. When requiring the implementation of RM in specifications, the mission impact of cyber attacks and investment effects should be fully considered. (1) To define attack patterns as a threat model which specifically analyzes and interprets the reality of current cyber threats and develop specific attack scenarios (2) To design an information system design model as a model in accordance with each characteristic of the system (3) To analyze the impact and the effects of design measures by tracing attack pattern scenarios on the information system design model (attack simulation) (4) To compile the results of attack tracing (attack simulation) as “system design measures” Analysis process (1): To define attack patterns as a threat model which specifically analyzes and interprets the reality of current cyber threats and develop specific attack scenarios Since threats of today have become diversified, advanced and complex, it is difficult to analyze 515 the impacts and plan measures if handled individually, and it is impossible to determine the measures at the contract stage or design stage. Thus, the risk factor reference model has classified the threats into six patterns by analyzing behavior of actually observed threats, which has then been compiled into a “Catalogue of Critical Threats,” and the results of the analysis of the catalogue are organized as attack patterns. Clarif icaiton of the reality of threats and specif ication of measures Pattern 1: Malware inf ection through browsing of f icial website Individual incidents havinng great organizational impact are grouped in any of the patterns and incidents that can be covered with the same measures are grouped in the same category. Variation 1: “Browsing websites inf ected with a gumblar virus " Case of browsing gumblar infected sites from the intranet Variation 2: " Browsing websites inf ected with a **.ru:8080 virus" Automatic falsification cases caused by an infected web administrator terminal on the relevant intranet Variation 3: " Browsing websites inf ected with SQL injection " Variation 4: " Redirected f rom the search engines " Pattern 2: Targeted email attack (inf ormation thef t) Model called operation the “Aurora” attack Variation 1: File attached email ab Variation 2: Spam mail directing to unauthorized URL Pattern 3: Redirection by f alsif ied official websites Variation 1: “gumblar.x virus" Cases where the intrasites are infected with a Gumblar virus Variation 2: “SQL injection" Solution to the spread of infection from the use of FTP infrastructure Pattern 4: 「Malware inf ection through media (inf ormation thef t) Variation 1: " Conf icker (worms) spreading via USB " Reflecting “the characteristics of the infrastructure used for Distributed Denial of Service (DDoS) attacks against smart meters” found in DDoS cases in South Korea Pattern 5: Multiple DDoS attack (attack inf rastructure) Pattern 6: Regular DDoS attack Creation of attack bots using exising services, such as iDC, etc. Variation 1: " DDoS attacks on SSL connection " DDoS attacks on SSL connection by Botnet Impact on the internet business settlement Ref erence: Existing threats (attacks still observed today) Figure 6.12-7 Attack patterns covered by RM 516 The outline of each attack pattern is described below. “Pattern 1: Malware infection through browsing official websites (information theft)” This attack redirects the website to malware distribution sites to steal authentication information, etc. and setup a backdoor when users browse falsified official websites. Infrastructure used for the attacks expands through the use of the stolen authentication information. This corresponds to the cases where the system gets infected when the system user browses the falsified official site. Figure 6.12-8 Pattern 1: Malware infection through browsing official websites (information theft) 517 Pattern 2: Targeted email attack (information theft) Instead of indiscreetly targeting a large number of users, this type of attack targets individuals in specific organizations or firms by using a false title, text or sender name, and sends emails with attached malware. Once an email is opened, the malware is activated and the system is infected with bot and organizational information is stolen. Since emails are sent to specific organizations, it is called a “targeted attack.” Figure 6.12-9 Pattern 2: Targeted email attack (information theft) 518 Pattern 3: Redirection by falsified official websites This attack falsifies official websites with a purpose to redirect the site browser to a malware distribution site. This corresponds to the cases where website in the system is falsified (link insertion) and redirected to the malware distribution site for the external browsers. Figure 6.12-10 Pattern 3: Redirection by falsified official websites 519 Pattern 4 Malware infection through media (information theft) A virus slipped into the media port, such as a USB port, etc., during the production development process, etc. enters into the system through the media port. Once entered, the virus updates the malware onto the infrastructure used for attacks. At the same time, the infection expands through network infection of the core system and media ports. Since the attack causes both network failure and server failure, an effective prevention is the cooperation between the management organizations of both network and server and the security department in addition to the preparation for separation procedures, etc. The malware entered into the system sets up a backdoor in the system to scan system information. Figure 6.12-11 Pattern 4: Malware infection through media (information theft) 520 Pattern 5: Multiple DDoS attacks (attack infrastructure) A PC infected with malware carries out DDoS attacks on the web server and downloads instructions and other malware from the malicious server, then sends out mass spam mails and destroys files in the malware-infected PC. The multiple-type DDoS is a new type of attack with respect to the infrastructure used for attacks; for example, the existing VPN network, which has been traditionally constructed as a package of safety assurance, is used and malware with dispersed functions exercise the attack functions in conjunction with each other. Since it is difficult to analyze protection information, it will become a threat that will be hard to address in the future if it is used in various types of attacks. Figure 6.12-12 Pattern 5: Multiple DDoS attacks (attack infrastructure) 521 Pattern 6 Regular DDoS attack DDoS attacks on net-business disable sales settlement. With regard to the response to this impact on business, a comprehensive assessment should be made for countermeasures, while taking into account the business impact and cost for measures. In the case of the DDoS that causes a line overload (line bandwidth DoS), protective measures from the website side, and thus, response coordination with the line side is necessary, and should be included in the contents of the contract. In this case, cost performance should also be taken into account. In the case of a processing load DoS attack, the system will be protected by setting up DoS mitigation functions on the website side. Attack analysis information is required for the setup. Thus, an organizational line needs to be secured. In the case of a DoS attack against SSL servers, access to SSL connections will be lost. Figure 6.12-13 Pattern 6: Regular DDoS attack The following “basic model of strategic attacks” and “basis for the definition of cyber attack threat model (information theft attack scenario)” are the compilation of selected cases commonly found in the behavior patterns from 1 to 4 in relation to the ultimate impact on organizational operations. First stage: Initial intrusion into the system First stage: Initial intrusion into the system Launch of initial malware into the system occurs through various methods. There are many types of malware. Malware without a vulnerability patch (zero-day vulnerability) and malware to which anti-virus pattern files are not applied are also used often. Since these malware are launched through official connections (HTTP&SMTP), the conventional measures in the first stage (such as FW, 522 anti-virus pattern, and vulnerability patch, etc.) are not infallible. Second stage: Connection to a malware download server and launch of malware attacks Malware update themselves through the connection with an external malware download server and receive attack instructions, etc. Since the connections in this case are normal communications using HTTP, SSL, etc., detection and blocking by FW, IDS, etc. do not work. The attacks in the second stage are often undetected because they are difficult to find. Third stage: Continuous information theft and attack instructions In the third stage, “information theft,” the ultimate objective of the attack, is carried out based on the remote attack instructions and the information is transmitted to an external source. Since the attacks are carried out through normal communications using HTTP, SSL, etc., detection and blocking by FW, IDS, etc. do not work. The attacks in the third stage are often undetected because they are difficult to find. The ultimate threat (challenge) to organizations lies in this third of stage attacks. Goal-matching concept It is necessary to re-define threats and re-analyze design concepts and organizational operation concepts in order to avoid mission impact Basic patterns of strategic attacks Pursuit evasion by the attack infrastructure (who and where?) Preparation ・Presence of objective/intent/infrastructure used for attacks stage (1) Planning of attacks through multiple schemes ★ Prevention of organizational impact by blocking the second and third stages Formulation of operation plan First stage As long as the intrusion of the main attack force and its attacks (objective theft) are blocked, the ultimate impact on the organization (system) can be avoided, even if the attack strategies cannot be covered by a vulnerability patch or measures for AV patterns. ・Initial intrusion into the system (various methods) (1) Initial malware attached to email for targeted attack (2) DL server redirection by website falsification (3) Initial malware through media (4) Slipping away by abusing a digital certificate (5) Embedding of a redirector exploiting website vulnerabilities Limitations of the zero vulnerability campaign, etc. Second stage Measures f or system design management Exploiting vulnerabilities Blocking communications in the DL server in the 2 nd and 3rd stages ★ Annihilation of threats upon obstructing the attack objective Launch of preemptive f orces It is recommended first to stop attacks in the 2nd and 3rd stages and avoid the ultimate impact, followed by extermination of viruses and measures against vulnerabilities. ・ Connection to DL server and launch of offensive malware (1) Downloading of malware (2) Sending attack instructions, etc. Shifting the axis to measures for impact prevention Invasion of main attack f orces Use of attack infrastructure Analysis and tracking of strategic attack patterns Third stage ・Continuation of information theft and attack instructions (1) Uploading stolen information ★ Grasping the entire picture of strategic attack patterns and pattern monitoring In pursuit of achieving the ultimate goal of attack (thef t) This is the ultimate threat (challenge) to an organization. Figure 6.12-14 In RM, the target is set to organizations Selection of characteristics for design measures by tracking down the attack patterns (behavior) and monitoring pattern changes Common basic model of cyber attacks Analysis process (2): “To design an information system design model as a system model in accordance with each characteristic of the system” 523 In order to analyze the behavior of threats (viruses, etc.) when the information system is attacked, typical configuration cases of information system are grouped into four “system topology models” Each system topology model is not necessarily used individually; instead, it is assumed to be used in combination of several models: for example, a combination of “intranet model” and “iDC model.” A. Intranet model B. Closed model C. iDC model D. SaaS model The following is an example of the intranet model No 1 Model name Intranet model Outline and characteristics of the system topology model ・ Information system configuration most commonly used in public and private information systems ・ Operations are carried out by separating the DMZ (DeMilitarized Zone) in which external web server is installed to the intranet from the in-house system area which does not allow direct access from external sources. ・ The intranet model includes a system topology that operates by only installing the DMZ area (such as external public server, etc.) in the iDC. ・ In many small offices (such as a local office, branch office and sub-branch office) the internet is accessed directly through the in-house system of each premise without going through a DMZ. Such configuration is included in the intranet model. 2 Closed model ・ A configuration found relatively often in the medical information system and the FA system of the manufacturing industry. The information system is complete within the premise, which is not connected to the external internet. Since there is no internet connection, no cyber attacks are made via network; however, the damage is likely to spread if virus-contaminated USB memories or CDs are taken in because patterns are not updated or updating of anti-virus software is delayed. 3 iDC model ・ Use of iDC exhibits a variety of forms. The iDC model in this section assumes the cases where operations covering the operation systems are conducted on the iDC. ・ Only the cases where the entire DMZ (such as web server for external sources) is installed in the iDC can be handled by the intranet model. The cases where a part of business is conducted by the iDC and the rest of the business is conducted on the in-house internet can be handled in 524 No Model name Outline and characteristics of the system topology model combination between internet model and iDC model. ・ This model is different from the intranet model in a sense that there is an impact of sharing switches and servers with iDC users and an impact of administration terminal access from the iDC to the systems of several iDC users. 4 SaaS model ・ In SaaS, only subscribed users can use services via the internet, and no system resource management is carried out, such as in a server or DB, etc. ・ A security measure for SaaS that can be carried out by the user is the access control alone, and the rest of the security measures are entrusted to a SaaS provider. This is the difference from the system operations that use the iDC. Analysis process (3): “To analyze the impact and effects of design measures by tracing attack pattern scenarios on the information system design model (attack simulation)” Technical methods have been studied as to the best practices to inhibit threats. These methods include evaluating the effectiveness of security measures installed on the topology by performing a “threat trace” (attack simulation), which allows the analysis of influential behavior on each “system topology” of the “behavior patterns (attack sequence and attack specifications)” that have been created using the “behavior model.” The “threat trace” has been conducted in accordance with the actual attacks that have occurred. Analysis process (4): “To compile the results of an attack trace” (attack simulation) into the “system design measures” Design measures found to be highly effective by the “threat trace” (attack simulation) were compiled into the “system design measures” according to each behavior pattern. From the analyses above, the current attack models have common attack specifications with respect to the ultimate impact on organizational operations, with some exceptions. It is then clear that they do not depend on system topology forms and attack behavior patterns. This is thought to be because attack targets have been gradually immerging into one pattern. Thus, “common attack scenarios and design measures” have been generalized and organized as below. ○Definition of cyber attack threat model (attack scenario) ○Requirements for RM design measures (collection of requirements for specifications) for the aversion of the ultimate impact on organizational operations 525 6.12.4.3. Definition of cyber attack threat model (attack scenario) The conventional design measures have been based on the attack story focusing on the first stage but are now facing limitations in terms of the number of measures and effectiveness. Meanwhile, the main objective of the common cyber attack threat model (attack scenario) in recent cyber attacks is information theft through a process from the first to third stage, and the second and third stages, which involves external access, have a particularly large impact on the organization (business). Thus, besides the conventional measures, the attack threats corresponding to the ultimate impact on organizations are identified as being the second and third stage attack patterns, which are directly connected to attack objectives, and are based on the various cyber attack cases of today. Then, the following two cases have been set as attack models commonly found in various attack patterns. ○ “Information theft attack (including falsification of redirection link embedment on the site)” ○ “Service interruption/ suspension attack” Attack objectives | +---01_Information theft | +---Pattern 1: Malware infection through browsing official website | | +---Variation 1: Browsing websites infected with a gumblar virus | | +---Variation 2: Browsing websites infected with a **.ru:8080 virus | | +---Variation 3: Browsing websites infected with SQL injection | | +---Variation 4: Redirected from the search engines | +---Pattern 2: Targeted email attack (information theft) | | +---Variation 1: File attached email ab | | +---Variation 2: Spam mail directing to unauthorized URL | +---Pattern 3: Redirection by falsified official websites | | +---Variation 1: gumblar.x virus | | +---Variation 2: SQL injection | +---Pattern 4: Malware infection through media (information theft) | +---Variation 1: Conficker (worms) spreading via USB | +---02_ Disruption/suspension of services | +---Pattern 5: Multiple DDoS attack (attack infrastructure) | +---Pattern 6: Regular DDoS attack | +---Variation 1: DDoS attacks on SSL connection | +---Existing threats (attacks still observed today) Considering the above, the cyber attack threat model (attack scenario) is defined below. It is assumed that this scenario will also be used as “test requirements.” 526 Attack scenario of an “information theft attack (including redirection link embedment and falsification of the site) Method 1 Method 2 First stage process Method 3 “Initial intrusion into system” Method 4 (1) When the user browses the falsified official website, authentication information in the general PC is redirected to a malware distribution site by exploiting the vulnerability of software in the general PC. (1) An attacker attaches malicious spoofed emails to the general PC within the intranet. (2) Malware gets activated when the user opens a file attached to the spoofed mail on the general PC. Consequently, the second stage of the process will follow. (1) The website is falsified from an external source through a separately acquired ftp ID/PW. (2) Redirection embedment (falsification) is conducted on the website to redirect the user to a malware distribution server. (1) Malware filtered into digital memory media, such as USB memory, enters into general PCs through the media port. (2) Malware infection spreads from the initially infected PC to other general PCs through the network infection, exploiting memory media, file sharing programs and vulnerabilities. (3) Malware filtered into the general PC gets activated by exploiting vulnerabilities. Consequently, the second stage of the process will follow. Note: In the case of file migration operation between open and closed systems through USB, etc., the same attack scenario as the open system is applied to the closed system. Attack scenario of an “information theft attack (including redirection link embedment and falsification of the site) Second stage process Method 1 “Connection to malware download server and launch of offensive malware” Method 2 (1) Function update of the malware and other malware will be downloaded by communicating with an external server (command & malware distribution server) Note: An official site (on the attack infrastructure) that has been taken over is used as an external server. Note: External server is constantly changing. Thus, blocking a specific address is ineffective. Note: FW detection/blocking cannot be implemented since an official service method, such as HTTP and SSL, etc., is used for the communication with external server. (1) When the user browses the falsified official website, authentication information in the general PC is redirected to the malware distribution site by exploiting vulnerability in the software on the general PC, then malware will be downloaded. Attack scenario of an “information theft attack (including redirection link embedment and falsification of the site) Method 1 Third stage process “Continuation of information theft and attack instructions” Method 2 (1) Attack instructions, etc., are sent from the external server (command & malware distribution server) to malware. Note: Attack instructions, etc., have many specific instructions and it is difficult to clarity or explain the behavior. Note: An official site (on the attack infrastructure) that has been taken over is used as an external server. Note: The external server is constantly changing therefore blocking a specific address is ineffective. Note: FW detection/blocking cannot be implemented since an official service method, such as HTTP and SSL, etc., is used for the communication with the external server. (1) Downloaded malware steals authentication information, etc., which is then sent to the external server. Note: An official site (on the attack infrastructure) that has been taken over is used as an external server. Note: The external server is consistently changing and blocking a specific address is ineffective Note: FW detection/blocking cannot be implemented since an official service method, such as HTTP and SSL, etc., is used for the communication with external server. 527 Attack scenario of “service disruption/suspension” Method 1 Attack process Method 2 Note: The assumption is that the analysis of attack sources, etc. is difficult because of the flexibility in changing DDoS attack specifications from the official PC, etc., using multiple attack infrastructures. (1) Transmission of a large number of spam mails and destruction of files in the infected PC, in addition to DDoS attacks (the same as an information theft attack scenario, except for DDoS attack) (2) DDoS attacks by using DDoS tools. Details of attacks are as follows: ・ Searching for simple FTP PW settings (FTP brute force attack) and falsification of agitation sites. ・ Searching for SQL injection vulnerable sites and falsification of agitation sites. ・ DDoS attacks by using overseas proxy sites (unable to use country-specific IP filter). ・ DDoS attacks by using a number of false IPs (unable to use IP filter). ・ Combination of bandwidth-DDoS and load-DDoS attacks. 6.12.4.4. Requirements for RM design measures to avoid ultimate impact on organizational operations Conventionally, the system has been designed based on the concept of “perimeter defense” against attack methods in the first stage; however, the effectiveness of these measures has become increasingly limited that attacks on the first stage are often successful. Thus, examinations were conducted on the “requirements for design measures (including non-functional requirements) to avoid the ultimate impact on organizational operations” with emphasis on the measures for second and third stages having large impact on organizational operations, besides design measures against attack methods in the first stage in the common cyber attack threat model (attack scenario). In the information theft attacks, requirements for design measures against common attacks can be devised since the attack methods in the second and third stages are common. There emerged threats in the closed system believed to be equivalent to the closed-system threats via media, such as USB. Since this type of attack technology may be used frequently in the future, requirements are defined as common design measures regardless of system topology. Also, the background and objectives of DDoS attacks vary and there are various attack methods accordingly; however, the type of attack communications is the same from the viewpoint of the defending system. Considering the above, the following show the definitions of “requirements for design measures to avoid the ultimate impact (including non-functional requirements, such as operations management, etc.)” and “operation conditions as prerequisites for system design” in accordance with the two types of attack scenarios. 528 1 2 3 4 Function requirements item Introduction of authentication of dual- element authentication/one-ti me password Settings for “LAN for management” Access control of the web server administration terminal Checking proxy authentication information Details of function requirements Use of dual-element authentication by combining ftp ID/PW for updating websites and one time password (OTP), etc. Server management settings for the in-house network, which is not available to external sources (backside LAN) Setting for prohibiting the access to other than designated sites, such as software update for the web server administration terminal Design of authentication access by authentication proxy at the time of accessing external websites using a general PC Reasons and background for requirements Enhancement of authentication in the case of leakage of ftp ID/PW for website management Example of setting - One-time password OTP) - Response to Gumblar attacks, etc. If the client’s PC infected with malware is used as the terminal for server management, the ftp ID/PW of the site administrator may fall into the hands of the attacker. Embedment of Java Script on the web page can be prevented by limiting the web server for update to a LAN for management (backside LAN) - Response to Gumblar attacks, etc. Since the client’s PC may be infected with malware through access to official websites, the infection rate will decline if the access to the administration terminal is controlled, thus reducing the possibility of the theft of critical data, such as the FTP account of the administrator. It has been confirmed that authentication information is not often used when a malware transmits information stolen by a unique method of communication to malicious sites. - Network topology design - Settings for administration terminal - System proxy settings - Authentication proxy - There is no way of protection if the offensive malware has already been authenticated. 5 6 7 Communication control via system proxy Design of external access via general PC system proxy settings when accessing external websites. Use of firewall, etc. to block external communications that do not go through the proxy using specific port communications (global IP). When a malware transmits stolen information to malicious sites (theft), it has been confirmed that it often uses an independent communications method using the 80443 port. Many of these communications do not use a system proxy. The malware that uses a global IP for connection trials to an external host can be blocked by FW reel Detection/blocking of the contents of HTTP,SSL headers, etc. (GET, POST command) - Ineffective for the malware that uses system proxy settings Many of the following cases uses 80/tcp and 443/tcp: When a malware sends stolen information to the external malicious sites, When downloading new attack code, and When receiving command from C&C server. Header check of HTTP,SSL connections Use of an Intrusion Detection System (IDS) function (detection of malware download) Detection of the download of malware and update from external malicious server by using IDS, IPS (In/Out) It has also been confirmed that headers for HTTP connections (method) are deviated from the standard RFC protocol, which is normally used. IDS (IPS) cannot detect unauthorized communications with unregistered signatures. In order to increase the effectiveness of IDS, timely update of independent signatures for the detection of connections which are different from the usual patters in cooperation with the SOC (Security Operation Center). - However, it depends on the operation capacity of the SOC because it is not an authenticated signature. 529 - System proxy settings - Setting FW rules - IDS, IPS (including SOC operations) Detection of behavior when a malware is exploiting vulnerabilities, including zero day vulnerability 8 Introduction of unknown-virus detection software 9 Routing settings, such as router, etc. 10 Detection of infection activity by monitoring network volume overload VLAN and routing settings limiting to the necessary scope of access by router and SW Detection of network infection behavior by volume monitoring, such as file SV, load on SW and log, etc. Settings for abnormal load detection functions on the network and system monitor management functions Fight against the unknown virus and unknown vulnerability by detecting an act of attacks from the behavior of vulnerability to a virus on the PC. Products that can detect and protect damage caused by “zero day attacks” have been produced by several companies. - There is a possibility of design/usage consideration as a supplement to existing anti-virus software, upon sufficient evaluation on protective functions and the number of management processes, etc. In order to minimize the impact on the system, the scope of the attack impact is separated in the network topology design. - Cases of conficker and stuxnet worms, etc. Spread of malware network infections within the system can be detected by the network traffic malfunction. Thus, it is effective to monitor the data volume for detection at each site and temporarily blocking connections to routers, etc., in cooperation with the network control department. - Detection of vulnerability - Network topology design - Router, VLAN settings for SW Network monitoring function, operation Requirements for design measures against “service disruption/suspension attacks” (including non-functional requirements for operations management, etc.) Function Details of function Reasons and background for requirements Setting example requirements item requirements Response to DDoS attacks FW and balancer have DDoS mitigation - Setting DDoS which increase the functions to reduce the impact of DDoS mitigation functions processing load by setting attacks, which increase the processing load, by of FW and balancer DDoS mitigation functions, resetting the device functions in accordance - DDoS mitigation such as FW, balancer, etc. with the DDoS attack instructions. device To examine the introduction In order to further increase the effect of the of DDoS mitigation devices measures, consideration should be given to the introduction of the exclusive DDoS device that DDoS mitigation gives alert to anti-DDoS devices and carries 1 function out bandwidth control and access control when detecting communications that have been deviated from the known regular communication traffic patterns. 2 Use of anti-DDoS services of an ISP Consideration for concluding contracts with ISPs to respond to DDoS attacks that increase load on bandwidth - Cooperation with analyzing organizations for DDoS attack methods, communication details, etc. Even if a DDoS attack has been detected, an individual protection is difficult against a large-scale attack. An ISP provides anti-DDoS measures using a strong backbone. The use of such products should also be considered, when necessary. - Use of anti-DDoS services Operation conditions as prerequisites of system design 1 Framework for response to damage as a prerequisite for design 2 “Preparation for initial response operation procedures” such as blocking infectious communication ports, etc. It has become clear from the analysis of attack behavior and attack patterns of recent cyber threats that cyber attacks have advanced. Thus, it is becoming difficult for an individual system department of the user organization to analyze the details of attacks and to take proper recovery measures. A prerequisite for attack response is to clarify the response and division of roles by incorporating the communication and cooperation framework with security vendor or system integrator SIer at the time of designing operation framework. “Preparation for initial response operation procedures” to suppress the spread of infections within the system through a containment by blocking or temporary separation of infected communication ports at router sites. *A difference in response speed occurs depending on the preparation of procedures and operations management. *Closing procedures for infected ports of the router and SW *Comprehensive understanding of network failure and server failure and preliminary study on the section to be separated. *Detection procedures by volume monitoring, such as file-SV and load on SW and log, etc. 530 6.12.5. Descriptions concerning security in service in each procurement area Requirements for security services to be described by each procurement area are included in the services of the TRM of each procurement area. Security notes and the outline of services described in each procurement area are shown below. For actual procurement, a check should be carried out to see whether consideration has been given to the notes listed below. ●6.2. Support for procurement Notes Outline of notes Corresponding items in TRM Definition of The customer and the compiler of 6.2. Support for procurement information security specifications shall define the information 2. Support for definition of requirements security requirements in pursuant to the requirements “Standards for Information Security Measures for the Central Government Computer Systems” and information security policies of each ministry. Since the following requirements are particularly required for entry in the Basic Guidelines for Government Procurement Related to Information Systems, they shall be clearly and specifically defined. (1) Definition of authority management (2) Definition of security measures The term “authority management” refers to the management of information pertaining to entity authentication (including identification code and entity authentication information) and approval information pertaining to access control 531 ●6.3. System integration (design/development) *Applied commonly to 6.3-1~6.3-4 Service item Outline of service Items corresponding to TRM Security measures The contractor shall take sufficient Preparation for development for development information security measures for the environment environment environment for development (device, workplace, etc.) when such an environment is prepared by the contractor. Information security The contractor shall carry out information Basic plan design security design in pursuant to the Detailed plan “Standards for Information Security Measures for the Central Government Computer Systems” and information security policies of each ministry. Security measures The contractor shall take sufficient Unit test, system test, for test environment security measures for the test comprehensive test environment (devices, workplace, test data, etc.) when such an environment is prepared by the contractor. User training The contractor shall provide information User training security training for system users. Information security The contractor shall prevent an management occurrence of a security-related incident or fault, etc. during each work process. The contractor shall also report to the customer immediately after the occurrence of an incident and minimize the damage as much as possible. 532 Project management ●6.4.Operation Notes Outline of notes Items corresponding to TRM Handling of If a document contains personal Formulation of operation operation framework information, such as an organizational plan chart, etc., the document shall be handled in accordance with the importance stipulated in the regulations. 533 ●6.5. Helpdesk Service item Outline of service Items corresponding to TRM Creating of an An outline for implementing information Formulation of operation outline of security measures shall be created in the plan implementing helpdesk operation plan, which shall be information security finalized upon consultation with measures ministries. Training for helpdesk The contractor shall provide helpdesk Development of work staff staff with training on information security environment measures to be implemented in helpdesk services. ●6.6.1. Hardware maintenance Service item Outline of service Items corresponding to TRM Revision of firmware, The contractor shall obtain the most Support for version upgrade configuration recent information on firmware related to change, etc. the stability of security and hardware, such as BIOS, and require the hardware maintenance company to implement updates whenever necessary. ●6.6.2. Software maintenance Service item Outline of service Items corresponding to TRM Provision of The contractor should provide application Provision of modification information on maintenance company or system (patch) files, version security patches infrastructure maintenance company with upgrade programs information on software bugs, patches and version upgrades, etc. as soon as such information becomes available and should also instruct the application maintenance company or system infrastructure maintenance company to conduct preliminary patch applications. In order to determine the propriety of the immediate patch application, there is a way to add the application maintenance company and the system infrastructure company to the list of recipients of information provided by the software maintenance company, such as information on software version upgrades, etc. 534 ●6.6.4. System infrastructure maintenance Service item Information provision and application of security patches Outline of service The contractor shall immediately report to the ministries on information pertaining to technical issues of information systems, security vulnerability (security holes), software bugs, patches and version upgrades, etc. In response to the request from the ministries, the contractor shall carry out patch application possibility verification work, patch application work and technical advice for software. Items corresponding to TRM Updating system infrastructure software ●6.7. Tasks incidental to device procurement Notes Security design Security settings/adjustments Updating virus definition file Outline The contractor shall create a security design in pursuant to the “Standards for Information Security Measures for the Central Government Computer Systems” and information security policies of each ministry and implement information security measures accordingly. The contractor shall carry out environmental settings and various adjustment work necessary for this system, using the procedures concerning the existing system, introduction method, and the created security design. The contractor shall update the virus software and virus definition files to keep them in the most recent status at all times. Items corresponding to TRM On-site study/design Device setup Device setup ●6.8. Tasks incidental to procurement of iDC equipment Notes Security monitoring Security diagnosis and reporting Outline The contractor shall make regular reports to the relevant official of the ministry about the status of security monitoring (scrutinizing of firewall logs and monitoring of unauthorized accesses, etc.), as well as the monitoring results. The contractor shall carry out a regular diagnosis on vulnerability (status, impact and response methods) and report the results to the relevant official of the ministry. 535 Items corresponding to TRM Operation/maintenance (daily) Operation/maintenance (monthly) ●6.9. Network procurement Notes Definition of information security Requirements for information security (measures) Disposal of devices Security design Security inspection Outline of notes The contractor shall specifically define the information security measures in accordance with the importance and risks of information assets in pursuant to the information security policies of the ministries based on the “Standards for Information Security Measures for the Central Government Computer Systems.” The contractor shall follow the security policies and security guidelines of the ministry in order to carry out an overall security measure program that has been acknowledged in the market. The contractor shall maintain the security level for operations. The contractor shall cooperate and coordinate with the existing operation and maintenance company for the security measures to be taken on the entire network. The contractor shall delete data completely after the removal and displacement of unnecessary devices to prevent a third party from recovering the data using date recovery software, etc., except for the cases of destroying the devices. The contractor shall either implement the security policy design (encryption, FW, IDS/IPS, quarantine) and encryption design (specifications for encryption, encryption method, encryption algorithm) or follow the rules presented as equivalent to the specifications. Vulnerability of network devices to be introduced may be verified at times and disclosed by third organizations, etc. If there is a problem, the contractor shall take appropriate measures. 536 Items corresponding to TRM Design/development plan Design/development Design/development Design/development Design/development Security test Handling of incidents Security diagnosis and reporting Security inspection The contractor shall surely implement tests on information security. Vulnerability of network devices to be introduced may be verified at times and disclosed by third organizations, etc. If there is a problem, the contractor shall take appropriate measures. The contractor shall establish a communication framework to promptly receive information on network faults and security incidents. The contractor shall constantly monitor the traffic status of lines. If there is abnormal traffic, etc., the contractor shall carry out a causal investigation and report to the relevant official via the existing operation and maintenance company. The contractor shall take measures promptly when a necessity for improving an introduced network device’s vulnerability has been pointed out. 6.12.6. Procurement of services specialized on security (To be created) 537 Support for test and migration judgment Operation/maintenance Operation/maintenance Operation/maintenance 6.13. Other (To be created) 538 7. Recommended Technology Standard This chapter describes the examples of technology standards that should be given priority in information system procurement by the government, as well as in the guidelines for selecting them. The following two documents are the main source of reference information in drawing up the guidelines for selecting recommended technology standards. • Framework for Interoperability Relating to Information Systems (Jun. 2007) http://www.meti.go.jp/press/20070629014/siryou.pdf • The first issue of TRM: Report on the results of validity examination (Feb. 2004) http://www.ipa.go.jp/software/optimize/pdf/technicalveri.pdf The technology standards have been selected from the viewpoint of implementing separated procurement as indicated in the procurement guidelines, and the scope of the technology standards is not intended to be all-inclusive for the technologies to be procured. 7.1. Requirements for technology standards in conformity with the “Framework for Interoperability Relating to Information Systems” The following is an excerpt from the “Framework for Interoperability Relating to Information Systems”: In view toward procuring higher quality information systems - which involves the need for expanded options for information system construction in governmental/public organizations, and a fair and transparent procurement environment with proper price settings – promotion of the following measures are needed to be set forward in the new development and refurbishment of information systems: withdrawing from dependency on the vendor’s proprietary technologies, and further pursuit toward openness in the government information systems. In the “Basic Guidelines for government procurement related to information systems,” the government indicates that, regarding the design and development processes, separated procurement should be the basic procurement policy for the basic infrastructure system and in each of the functional systems. These individual functional systems, realized by means of separated procurement in conformity with the basic guidelines, are integrated through the intermediary of the common infrastructure. The individual functional systems, as a functional unit, as well as an integrated whole of functional units, must realize all the functions required 539 in the business processes, where information exchange with other individual functional systems, as well as with the common infrastructure, should be necessary. This translates into the requirement of interoperability among individual functional systems, and between each of them and the common infrastructure. As separated procurement should become the basic policy in the future, as describes above, it entails the need to select technology standards with priority placed on “interoperability” while promoting the move toward “separated procurement” and “open architecture.” In addition, selection of an “open standard” should be the overriding challenge because fair and equitable procurement is the major premise in government procurement. 7.1.1. Definition of “Opening” and “Open Standard” In the “Basic Guidelines for government procurement related to information systems,” the term “Opening” is defined as follows. Lowering of dependency on specific vendor’s proprietary technologies - in terms of procurement, maintenance and operation - through the breakdown of the information systems into individual procurements and exchangeable/standardized components, thus enabling an expansion of the range of business entities eligible to participate in procurement, maintenance, and operation services. The “open standard” here represents the technology standards that meet, in principle, all the following items. • The technological specifications have to be agreed upon through an open participatory process, and provide disclosure specifically to the level that allows concrete implementation. • Adoptable by any party. • Many examples of the technology standard have been launched onto the market. 7.1.2. Requirement to ensure validity as a standard technology In the “Framework for Interoperability Relating to Information Systems,” the following requirements are placed on the technologies referenced in the TRM, with a view toward standardizing specifications – an essential element to secure validity as a standard technology. • The technology is one with standard specifications defined under the initiative for standardizing organizations and other parties, or one in the process of standardizing. • Management of intellectual property rights (IRP) has to be defined clearly in the standard in a way that allows any party to implement the specifications freely without the possibility of being 540 charged unduly. From the viewpoint of technological requirements, the following items are to be examined for the selection of technological standards. • Track record of successful connections of standards-compliant implementations, or perspective of achieving such connections (verification of connectivity) – a requirement to ensure interoperability among information systems. • Track record of successful porting of an application from one standard-compliant implementation to another implementation compliant to the same specifications, or a perspective of achieving such a porting (verification of portability) – a requirement to ensure portability of information systems. • Provision of functions and features that enables continuous expansion and maintenance, including upgrade feasibility and independence from a specific platform (verification of continuity into the future) – a requirement to ensure usability in the future. • Applicability of the technology to such business processes as front-office, middle-office, and back-office tasks performed in the ministries, as the TRM assumes these tasks as its objectives (verification of affinity for the current system). 7.1.3. Guidelines required to establish technology standards In the “Framework for Interoperability Relating to Information Systems,” the guidelines to be followed by the information system designers and the persons in charge of procurement are provided. Basically, these guidelines should also be applied to the selection procedures of technology standards. The guidelines are listed below. • To expand the range of bidders in the tendering process of separated procurement, restrictions on physical computers and platforms on which the separated functional units operate should be reduced to a minimum. • To ensure interoperability among technology components as well as component-by-component exchangeability among them, the technology components deployed in the upper layer must consist of standardized components – in terms of functions and interfaces provided by the lower layer technology components - that employ solely the functions and interfaces compatible with the requirements of an open standard. • In cases where a functional component based separated procurement and expanded range of options are desired, restrictions on the platform on which the functional components operate should be reduced to a minimum. Therefore - within the bounds of what the non-functional requirements permit in terms of performance, security and stability – the service infrastructure used to invoke external functions should be selected based on the criteria that it can maintain platform-independence. • As the data format for data capable of long-term accumulation and exchanged/repeated 541 utilization among a plurality of users, an open and standardized data format should be adopted. In case more than one open standard is eligible, XML-based standards with a lower dependence on platforms and specific technologies should be preferentially adopted. In case more than one XML-based open standard exists, the priority should be given to those with a plurality of products and vendors that support the standard, especially with future expectations, from the view of marketability, of wider support from an expanding range of products and vendors. • In cases where a functional component based separated procurement and expanded range of options are desired, restrictions on the platform on which the functional components operate should be reduced to a minimum. In line with this, the format used to exchange messages among the functional components should also be platform-independent within the bounds of what the service infrastructure selected for external function invocation permits. • XML should be used as the message format for exchange among the functional components, as it has lower dependence on platforms and allows description of the message’s logical structure as a schema. The XML schema must adopt an open standard on a priority basis, and should be extended as needed. The adopted schema must be made open if interoperability with external systems is required. • In conformity with the provisions stipulated in the “Agreement on Government Procurement (GPA)” (Chapter 6-2), international standards and Japanese Industrial Standards should have priority as the standards to be referenced to by the procurement specifications. In case no relevant international standards nor Japanese Industrial Standards exist, the next option to make of reference should be one of some other open standards. 7.2. Items for technology standard evaluation cited in “TRM 1st issue: The Report on the Results of Validity Examination” In the selection process of important technologies in the 1st issue of the TRM (2004), the following items were put forward as evaluation criteria. • The following fact must be included as one of the evaluation items: the technology to be evaluated has been standardized (or is in the process of being standardized) by a standardizing organization as a set of standard specifications. • Importance must be placed on the fact that the set of standardized specifications has a wide implementation base, and meets the conditions for widespread use, i.e. the management of intellectual property rights is clearly defined in the standardization processes in a way that allows any party to implement it freely without the possibility of being charged unduly. Therefore, the management status of the intellectual property rights must also be taken into consideration for the selection of a standard. • To ensure interoperability among information systems, a track record of successful 542 connections among the standards-compliant implementations, or the perspective of achieving such connections, must be an item of technological evaluation. • To ensure portability of the information system, a track record of successful porting of an application from one standards-compliant implementation to another, compliant to the same specifications, or the perspective of achieving such a porting, must be an item of technological evaluation. • One of the technical evaluation items must be the provision of functions and features that enables continuous expansion and maintenance to ensure usability in the future, including for example, expansion feasibility (scalability) and independence from a specific platform. • One of the technical evaluation items must be the applicability of the technology to such business processes as the front-office, middle-office, and back-office tasks performed in the ministries, as the TRM assumes these tasks as its objectives. • One of the technical evaluation item must