Commuter rail operating agreement



Download 2.72 Mb.
Page39/45
Date19.10.2016
Size2.72 Mb.
#4744
1   ...   35   36   37   38   39   40   41   42   ...   45



        1. Commuter Rail IT Environment and Risk Management Policy

This policy articulates requirements for performing periodic reviews and audits of the Commuter Rail IT Environment, determining appropriate data classifications and controls, and assessing and reacting to risks in order to safeguard those assets. The Operator shall institute periodic reviews and risk assessments based on changes in the Commuter Rail IT Environment including new threats, vulnerabilities and consequences to ensure the continued effectiveness of the implemented controls. The purpose of employing such a process is to institute remediation where warranted to reasonably ensure that planned and deployed controls meet the security goals of the agency and the Commonwealth enterprise.

        1. Commuter Rail IT Environment Physical & Environmental Security Policy

This document articulates requirements that management must address in defining a policy to implement adequate physical and environmental security controls at the Operator to secure and protect the Commuter Rail IT Environment and all MBTA Data. All Federal and Applicable Laws shall be adhered to.

        1. Enterprise Security Incident Handling and Response Procedures and Policies.

This policy articulates how the Operator shall identify, report and resolve security incidents in a manner that mitigates current and future risk to themselves and other potentially affected entities.

        1. Information Technology Security Policy

This policy describes requirements for the Operator and its staff for addressing data security considerations. It also addresses appropriate information security awareness and training to reduce the risk of theft, fraud, or misuse of the Commuter Rail IT Environment and MBTA Data.

      1. SECURITY; INFORMATION ASSURANCE.

        1. Information Assurance.

          1. The Operator shall protect and safeguard sensitive MBTA Data from inadvertent disclosure, access, acquisition, misuse, display, theft or other unauthorized actions (each, an “Unauthorized Disclosure”).

          2. The Operator shall implement and maintain throughout the Term safeguards to protect the confidentiality, security and integrity of MBTA Data and the Commuter Rail IT Environment in a manner fully consistent with the protection requirements set out in this Agreement, Applicable Law and best practices (the “Information Protection Safeguards”). The Operator shall maintain such Information Protection Safeguards until such time that the MBTA deems that the applicable MBTA Data is no longer sensitive and provides corresponding written notification to the Operator.

          3. Notwithstanding anything to the contrary, the Operator shall ensure that the Information Protection Safeguards comply with then-current applicable MBTA security and information assurance policies, regulations, standards, guidelines and Applicable Laws.

          4. The MBTA’s Enterprise Access Control effort is a comprehensive effort to consolidate and reorganize many of the MBTA's enterprise security access policies and standards and align them with the structure of Section 11 “Access Control” of the ISO/IEC 27002:2005, “Information technology - Security techniques - Code of practice for information security management”. The Enterprise Access Control Policy and supporting standard, Enterprise Access Control Security Standards have been drafted together as a suite with sections that are aligned with each other as well as with ISO 27k. The Policy is generally higher level and relies on the associated Standards to elaborate into the detail required for further technical use. The Operator is required to comply with this policy and the supporting standards in addition to any agency or third party that connects to the MBTA's wide or local area networks.

          5. The Operator shall provide and ensure that it, its personnel and MBTA employees with access to the Commuter Rail IT Environment or the MBTA Internal IT Environment shall complete initial information assurance awareness and annual refresher training in MBTA policies governing security, information assurance and workforce management, and such trainees shall certify to said training.

          6. The Operator shall perform actions in support of MBTA Security by following National Institute of Standards and Technology (“NIST”) Special Publications SP800-18 Guide for Developing Security Plans for Federal Information Systems, NIST SP800-100 Information Security Handbook: A Guide for Managers, NIST SP800-44 Guidelines on Securing Public Web Servers, NIST SP800-45 Guidelines on Electronic Mail Security, NIST SP800-81 Secure Domain Name System (DNS) Deployment Guide, NIST SP800-48 Wireless Network Security (802.11, Bluetooth, and Handheld Devices), NIST SP800-92 Guide to Computer Security Log Management for Certification and Accreditation Process of MBTA Systems; NIST SP800-14 – Generally Accepted Principals and Practices for Security Information Technology Systems; and NIST SP800-18 – Guide for Developing Security Plans for Information Technology Systems.

          7. The Operator shall update the Information Protection Safeguards as necessary or desirable, with updates included as necessitated by IT security notifications, the information assurance vulnerability management program, as required by officially appointed information assurance personnel or Applicable Law.

          8. The Operator shall comply with the appropriate security notifications within the Commuter Rail IT Environment. The Operator shall promptly acknowledge receipt of all security notifications and test and install security patches per component of the Commuter Rail IT Environment within ninety (90) days.

        2. Operator Training and Certification.

          1. The Operator shall ensure that personnel accessing the Commuter Rail IT Environment have the proper and current information assurance certification in its performance of information assurance functions in accordance with the MBTA security policies and industry standards. Such information assurance certification requirements shall include (i) MBTA-approved information assurance workforce certifications appropriate for each category and level as listed in the current version of NIST Special Publications SP800-100 chapter 4 Security Awareness, and (ii) appropriate operating system certification for information assurance technical positions as required by NIST SP800-18 and NIST SP800-37.

          2. The Operator shall provide documentation supporting the information assurance certification status of personnel performing information assurance functions.

          3. The Operator shall ensure that its personnel who do not have proper and current certifications are denied access to the Commuter Rail IT Environment.

        3. Security Assurances for the Commuter Rail IT Environment.

          1. The Operator shall prepare and provide by the Agreement Services Commencement Date, documentation on security policies and procedures in support of the Commuter Rail IT Environment and provision of the Commuter Rail Services including server hardening, patches, updates, operations and maintenance within the existing Commuter Rail IT Environment.

          2. The Operator shall develop Information Assurance Certification and Accreditation Process structure using NIST Special Publications NIST SP800-12, 18, 37, 53, and 100 preliminary “as is” artifacts submission and other industry standard information assurance policies and procedures for the Commuter Rail IT Environment on or before the Agreement Services Commencement Date.

          3. The Operator shall conduct an initial and annual security risk assessment through the Term of the Agreement. The Operator shall ensure that total system security services effectively and efficiently incorporate IA/security provisions and implementation in accordance with the security risk assessment, the security and contingency plan, related documentation developed in previous test phases and all Applicable Laws and industry best practices. The product/service/system must adhere to all Program System Security Authorization Agreement (SSAA) and Security Technical Information Guide (STIG) requirements while keeping integrity intact.

Appendix 1 to Schedule 3.17:
Disaster Recovery (DR) and Business Continuity (BC) Support Services


      1. Disaster Recovery (DR) and Business Continuity (BC) Support Services.

        1. Overview of DR/BC.

Based on the current capabilities of the MBTA, the overall complexity of the MBTA’s computing applications and services portfolio, and existing agency provisions for DR/BC, the Operator’s responsibilities shall in general: (i) apply to in-scope environments located in the MBTA NOC; (ii) the MBTA NOC itself in consideration of existing capabilities and, following implementation, Operator improvements to the facility; (iii) existing implemented methods to support MBTA specified DR/BC for MBTA applications and systems; (iv) not apply to the MBTA Internal IT Environment.

        1. Operator Responsibilities Regarding DR/BC Services.

The Operator's responsibilities with respect to the DR/BC services shall include the following:

          1. The Operator will retain sole responsibility for overall business continuity plans, application and network recovery, and recovery process management activities with MBTA oversight.

          2. The Operator must support business continuity plans as they relate to in-scope environment elements (i.e., in-scope infrastructure and facility elements only) as specified by the MBTA and participate in and support the regular testing and improvement of the business continuity plans. Unless otherwise agreed to by the MBTA, such testing shall take place on a quarterly basis.

          3. To the extent agreed appropriate, support MBTA IT standards and upon request participate in planning sessions, testing review sessions and other meeting activities between MBTA IT and participating MBTA staff for in-scope environment elements.

          4. Support implementation of business continuity plans as agreed in statements of Work between Operator and MBTA for in-scope environments as they pertain to the support of the implementation, testing and remediation of agency DR/BC plans for in-scope environment elements;

          5. Support MBTA activities, processes and procedures for in-scope work and environments to support MBTA disaster recovery capabilities.

          6. Timely update applicable business continuity plans and testing procedures in light of any Commuter Rail IT Environment changes, modifications, or adds.

          7. Support the MBTA’s potential future specification, design and implementation of infrastructure disaster recovery plans for in-scope environments and environment elements, but exclusive of middleware, application or presentation software as agreed based upon the following principles:

            1. Leverage a State provided offsite and geographically diverse alternate disaster recovery site that has sufficient computing and network capabilities which are adequate to process the MBTA’s transactions and to provide systems access to end-user personnel during an outage period

            2. Document requirements and support design reviews to facilitate transfer of operations to disaster site for in-scope environment elements to occur within 48 hours of failure of MBTA primary site

            3. Document procedures to restore primary operations for in-scope environment site operations (once available) within 24 hours

            4. Identification of redundant processing environment requirements to ensure 24x7 operations for MBTA critical infrastructure components

            5. Specification of redundant power requirements to ensure 24x7 operations for MBTA critical infrastructure components

            6. Specification of redundant networking requirements (network devices and telecommunications access) to ensure 24X7 operations for MBTA critical infrastructure components

            7. Specification of fire detection and suppression requirements to comport with service levels contained elsewhere in this document with regard to systems availability, failover and service levels as agreed for in-scope environment elements.

        1. Operator Responsibilities Regarding Testing.

          1. Support MBTA IT in establishing joint test objectives with an agency designed to verify that the in-scope environment elements will be available within the agreed upon timeframes contained in an agency business continuity plan as they pertain to in-scope environment elements.

          2. Support MBTA IT in scheduling and testing in scope environment elements of the disaster recovery and business continuity plans relating to in-scope environment elements at least annually in support of the agency, its designees, any testing and recovery providers, and relevant MBTA third party Operators/Contractors.

          3. Continuing to operate and manage the in-scope environment elements during periodic disaster recovery tests

        2. Operator Responsibilities Regarding Communications.

          1. Notifying impacted MBTA personnel as soon as practicable upon becoming aware of a disaster or outage affecting the contracted Services.

          2. Supporting with the MBTA to support an agency disaster recovery and business continuity plan. In such regard, the Operator will:

            1. Perform necessary migrations of the software code and data as defined in the MBTA disaster recovery plan to reinstate the in-scope environment elements so that they are functional at a backup location designated by an agency in accordance with the established procedures.

            2. Coordinate with the MBTA personnel to support the reinstatement of the in-scope Environment(s) at such backup location for in-scope environments.

            3. Maintain provision and ongoing operation of the Services for unaffected areas.

            4. Following any disaster, at the MBTA’s request, the Operator will support MBTA IT and staff in the reinstallation of any in-scope environment elements affected by such disaster in accordance with the process for such re-installation set forth in an MBTA disaster recovery plan and business continuity plan.

            5. Following any disaster, conducting a post-disaster meeting with the MBTA for the purpose of developing or enhancing plans to mitigate the adverse impact of future occurrences as they relate to in-scope environment elements.

            6. To the extent applicable to the in scope environment elements, maintain compliance with MBTA documented disaster recovery policies, standards, and procedures contained in a provided disaster recovery and business continuity plan.

            7. Support an annual test, documented results and feedback procedures contained the MBTA provided disaster recovery and business continuity plan for in-scope Infrastructure environment elements.

          3. The Operator shall not be responsible for, or quote or specify services associated with:

            1. Providing alternate data processing facilities or capabilities to the MBTA inclusive of data centers, networking, redundant or failover equipment and associated software; and

            2. Develop detailed disaster recovery or business continuity plans for MBTA applications; these plans shall remain the sole responsibility of the MBTA agency that owns the applications.




    1. SERVICE LEVEL AGREEMENT AND SERVICE CREDITS


      1. GENERAL OVERVIEW.

Service Level Agreements (SLAs) play an important role in defining and managing the expectations of Commuter Rail IT Environment performance. A successfully implemented service level management discipline ensures that information systems function smoothly while fulfilling the business needs of the MBTA and their stakeholders. The following Service Level Agreements set out in this Schedule 3.18 (Service Level Agreement and Service Credits) provide the requirements for performance. All components of the Commuter Rail IT Environment shall be sufficiently scalable to comply with the applicable Service Levels throughout the Term of the Agreement.

This Schedule 3.18 (Service Level Agreement and Service Credits) sets forth certain quantitative Service Levels and key measurements against which the Operator’s performance of the Commuter Rail Services shall be measured, as well as procedures relating to Service Credits and related provisions. Capitalized terms not otherwise defined in this Schedule 3.18 (Service Level Agreement and Service Credits) or Appendix 1 (Definitions) to Schedule 3.15 (Intellectual Property; Ownership) shall have the meaning ascribed to them in Schedule 1 (Definitions). The Operator shall perform the Commuter Rail Services and provide the Commuter Rail IT Environment at or above the performance levels described in this Schedule 3.18 (Service Level Agreement and Service Credits).



      1. FREQUENCY AND TYPE OF MONITORING; REPORTING.

Unless otherwise specified in this Schedule 3.18 (Service Level Agreement and Service Credits), each Service Level shall be measured, recorded and reported by the Operator, as directed by the MBTA, either (i) on a daily basis beginning on the date specified in the Service Levels for any particular Service (“Continuous Monitoring”); (ii) on a sampling basis, with the frequency, target, and duration of the monitoring and measurement set by the MBTA (with such sampling to include “surprise inspection” monitoring and review) (“By-Sample Monitoring”); or (iii) through a mix of Continuous Monitoring and By-Sample Monitoring. The MBTA shall be entitled to conduct independent monitoring and measurement of the Operator's compliance with Service Levels, at the frequency and levels set out in the preceding sentence, or through such other auditing and monitoring structure as permitted in the Agreement (collectively, “MBTA Monitoring”). The results of such monitoring and measurement of Service Levels (whether conducted by the MBTA or by the Operator) shall be in the form of a report (each a “Service Level Report”).

By the fifteenth (15th) day of each month, the Operator shall provide to the MBTA, as part of the Operator's monthly performance reports, a set of hard and soft copy of its Service Level Reports concerning its Continuous Monitoring to verify the Operator’s performance and compliance with the Service Levels during the preceding month. The Operator shall provide a Service Level Report concerning an instance of By-Sample Monitoring conducted by the Operator promptly after completion of such By-Sample Monitoring,

The MBTA shall timely provide the Operator with Service Level Reports resulting from MBTA Monitoring, subject to the Operator’s right to contest such results in accordance with the dispute resolution procedures of the Agreement.

Upon request, the Operator shall provide supporting information (including applicable raw data) for a Service Level Report in machine-readable form suitable for use on a personal computer, and as may otherwise be reasonably requested by the MBTA. The raw data and supporting information shall be the MBTA’s property and the MBTA’s Confidential Information, and the Operator shall provide the MBTA with access to such information online and ad-hoc during the Term and any transition period.



      1. REPORTING FORM.

The Operator shall provide reports that demonstrate its compliance with SLAs. Such reports shall be provided in a consistent and complete form and manner. The Operator shall, based on the SLAs and other information it is obligated to collect and disseminate, generate a standard set of templates and forms that allow it to efficiently and uniformly report and communicate the required information to the MBTA. These templates shall be of a standard digital type and uploaded to the Document Repository by the Operator upon delivery. The MBTA may require stylistic or format changes to the templates and forms in order to allow for greater integration and understanding. As with all other documents on the repository, the reports shall be searchable digitally and organized. Under no circumstances will the Operator modify a report once submitted. In the event of an error the Operator will justify the occurrence to the MBTA and the MBTA shall make the approved changes if they agree. The MBTA may require the Operator to disclose its method or means of monitoring and measurement at any time. The MBTA may conduct an audit anytime on any aspect of a report, measurement systems, monitoring system, or other aspect of the SLA.

      1. ROOT CAUSE ANALYSES; RESOLUTION OF FAILURES.

The Operator shall identify root causes for, correct problems leading to, and minimize recurrences of, all missed Service Levels, in accordance with the severity of the Service Level failure (as identified in Section 7 (Severity Levels). The Operator shall promptly investigate and correct failures to meet the Service Levels, all in accordance with the provisions of this Schedule 3.18 (Service Level Agreement and Service Credits), and keyed to the severity of the Service Level, by:

  • Promptly initiating problem investigations, including root cause analysis ;

  • Reporting any problems to the MBTA in accordance with the escalation process set forth in this Schedule 3.18 (Service Level Agreement and Service Credits);

  • Correcting any problems and beginning to restore Service Levels;

  • Advising the MBTA of the root cause of problems and the status of remedial efforts being undertaken with respect to such problems;

  • Providing documentary evidence to the MBTA (i) that the causes of such problems have been or will be corrected, and (ii) of steps for prevention of future related problems (where applicable); and

  • Making written recommendations to the MBTA for improvement and preventive measures (where applicable) in procedures related to Service Levels and correcting Service Level problems.

      1. SERVICE LEVEL MEASUREMENT PERIOD.

The Operator shall begin to provide the Services at the Service Levels specified herein as of the Agreement Services Commencement Date unless another date is specified in the row titled “Time to Meet Service Level” in the tables set forth below in the section entitled “Service Level Designations” and Metrics for Commuter Rail IT Environment, in which case the applicable Service Level shall be measured and become effective as specified in such row.

      1. AUTHORIZED SERVICE INTERRUPTIONS.

Throughout standard operation it will become advisable for the Operator to take systems down and out of service for routine and standard maintenance, for upgrades, and for other reasons (each, an “Authorized Service Interruption”). In the interest of promoting the greatest operational ability and operation of its system, the MBTA shall authorize, on a per event basis, an Authorized Service Interruption to facilitate what it considers necessary actions. Legitimate force majeure events, caused by circumstances outside the control of the Operator (“IT Force Majeure Events”), shall also constitute Authorized Service Interruptions.

The MBTA shall not be entitled to Service Credits from the Operator for a system's or application's lack of availability during the Authorized Service Interruption.



      1. REQUESTING AN AUTHORIZED SERVICE INTERRUPTION.

The Operator shall request an Authorized Service Interruption via the IPR no less than one month prior to the required interruption, though the MBTA may expedite this timeline in the event of critical security patches or other emergency work. The request will include at a minimum the following:

  • The purpose and reason for the action;

  • Authorization from the IT Change Control Board and MBTA representative;

  • The systems and users to be affected;

  • Actions to be undertaken;

  • A roll back and recovery plan in the event of a failure;

  • A schedule demarcating the outage window; and

  • An after-action report (to be submitted upon completion).

The Operator shall submit the above to the IPR and add it as an agenda item for that month's discussion in order to enable communication of the event and coordination of dependent services and organizations. Upon approval of the outage by the MBTA and the monthly IPR, the Operator shall inform affected users and system operators prior to the outage and shall then execute the approved outage in the timeframe approved by the MBTA.

      1. AVAILABILITY SERVICE LEVEL AGREEMENTS EXCEPTIONS.

Authorized Service Interruptions that have been approved by the MBTA and the monthly IPR and that follow all communication requirements for user awareness shall not count negatively against the required Service Level. This exception shall only apply to planned and approved Authorized Service Interruptions and to IT Force Majeure Events. For example, if a Service Level permitted 1 hour of downtime per month for a particular service, and the Authorized Service Interruption permitted an outage for 2 hours to upgrade the system over the course of that month, then the Service Level would not be considered unfulfilled for that month.

      1. SEVERITY LEVELS.

Service Levels are categorized by severity. The more critical the Service Level, the higher the severity the MBTA has assigned to that Service Level, and the higher the Service Credit due for non-compliance with that Service Level. The following provides the criteria employed by the MBTA in setting Severity Levels, and such criteria shall be used in modifying, adding, or removing Service Credits and/or Service Levels, as provided in Section 13 (Revisions to Service Levels and Service Credits):

Severity Level

Description

Severity Level 1

A Severity Level 1 (Sev 1) event reflects a failure of Commuter Rail IT Services or the Commuter Rail IT Environment that (i) results in a critical impact on the functionality, use, availability, or performance of the Commuter Rail, or (ii) threatens bodily harm or a security breach. The Operator shall immediately brief the MBTA on any Severity Level 1 event, and shall perform a root cause analysis and create a mitigation plan.

Severity Level 2

A Severity Level 2 (Sev 2) event reflects a significant and critical outage of the Commuter Rail IT Environment or loss of Commuter Rail IT Services, where a workaround or mitigation is or should be available to promptly mitigate or remove the outage or loss of service. The Operator shall immediately brief an MBTA official on any Severity Level 2 event, and shall perform a root cause analysis and create a mitigation plan.

Severity Level 3

A Severity Level 3 (Sev 3) event reflects a medium adverse effect or inconvenience. The Operator need not immediately alert an MBTA official, but shall report the event in a daily summary to the presiding MBTA official. If the event was due to a failure of a system or technical aspect of standard operation, then the Operator shall perform a root cause analysis and create a mitigation plan.

Severity Level 4

A Severity Level 4 event, incident or ticket reflects a minor adverse effect or inconvenience. The Operator need not immediately alert an MBTA official, but shall report the event in a weekly summary to the MBTA. These events are understood to represent the standard difficulties that are encountered in the provision of Commuter Rail IT Services or operation of the Commuter Rail IT Environment and that require a low level of effort to alleviate. The MBTA may direct the Operator to perform a root cause analysis and create a mitigation plan for Severity Level 4 events, for example in cases of unusual, odd, or repeating Severity Level 4 events, but these actions are not automatically required.

Severity Level 5

A Severity Level 5 (Sev 5) event reflects a minor adverse effect or inconvenience. The Operator need not immediately alert an MBTA official, but shall report the event in a weekly summary to the MBTA. These events are understood to represent the standard minor difficulties that are encountered in the provision of Commuter Rail IT Services or operation of the Commuter Rail IT Environment that require a minimal level of effort to alleviate.


Download 2.72 Mb.

Share with your friends:
1   ...   35   36   37   38   39   40   41   42   ...   45




The database is protected by copyright ©ininet.org 2024
send message

    Main page