Amendment_1_Attachment_2_-_MCRISS_PDSS_PWS.docx

Marine Corps Recruiting Information Support System (MCRISS) Indefinite Delivery/ Indefinite Quantity (IDIQ)

Total Force Information Technology Systems (TFITS) February 2016

Table of Contents

List of Figures

List of Tables

List of Appendices

Marine Corps Recruiting Information Support System Performance Work Statement iii Introduction Purpose and Scope The Total Force Information Technology Systems (TFITS) product office provides acquisition oversight for the portfolio of United States Marine Corps (USMC) systems. Marine Corps Recruiting Information Support System (MCRISS) is a project within the TFITS Manpower Tier.

The purpose of this Performance Work Statement (PWS) is to obtain Systems Integrator (SI) services for the MCRISS. The contractor shall provide Post Deployment Software Support (PDSS), system maintenance and performance upgrade services, and logistics support for MCRISS as defined in this PWS. For the purpose of this PWS, the SI is the Contractor and Contractor employees responsible for performing under this PWS.

The scope of this PWS covers the full range of PDSS and system maintenance and performance upgrade services. Services include program management; engineering and analysis; software development; configuration management; quality assurance; risk management; Help Desk; system and database administration; Information Assurance (IA); testing and evaluation; and logistics support.

This Indefinite Delivery/Indefinite Quantity (IDIQ) contract shall include a 36-month ordering period. The Government intends to execute task orders within the scope of this PWS as required. At a minimum, the Government intends to leverage this IDIQ contract for Post Deployment Software Services (PDSS).

Background The Marine Corps Recruiting Command (MCRC) is responsible to the Commandant of the Marine Corps for the procurement of qualified individuals in sufficient numbers to meet the established personnel strength levels, officer and enlisted, of the Marine Corps and Marine Corps Reserve. MCRC Headquarters is located at the James Wesley Marsh Center aboard Marine Corps Base (MCB) Quantico, Virginia.

MCRC Recruiting Force has successfully employed a highly effective concept known as systematic recruiting, a synergistic set of recruiting processes that have been in force since the late 1970s. The goal of systematic recruiting is to organize the efforts of recruiters and to ensure that the required contacts, appointments, interviews, and contracts are achieved.

MCRC is comprised of approximately 6,000 members. The following are locations at which MCRC personnel are located:

· MCRC Headquarters on MCB Quantico

· Region Headquarters (Parris Island, SC and San Diego, CA)

· 6 District Headquarters (Garden City, NY; Harrisburg, PA; Parris Island, SC; Ft. Worth, TX; Naval Station Great Lakes, IL; San Diego, CA)

· 1 Recruiter School (San Diego, CA)

· 48 Recruiting Stations (RS)

· 6 Prior Service Recruiting Stations (PSRS)

· 620 Recruiting Substations (RSS)

· 19 Prior Service Recruiting Substations (PSRSS)

· 74 Officer Selection Stations (OSS)

· 67 Military Entrance Processing Stations (MEPS)

· 840 Permanent Contact Stations (PCS)

· 24 Transient Recruiting Facilities (TRF) MCRISS is the enterprise system that supports recruiting efforts at the Headquarters, Regional, District, RS/PSRS, RSS/PSRSS, and OSS locations. It provides a centrally-managed and secure repository of information and services to support the management of applicant processing from prospecting to accession and commission into the Marine Corps and Marine Corps Reserve to meet the established manning levels. MCRISS integrates with other USMC and Department of Defense (DoD) systems.

MCRISS is Mission Assurance Category (MAC) III with a Confidentiality Level as described in Department of Defense Instruction (DoDI) 8500.2 as Sensitive but Unclassified (SBU). MCRISS is identified as Defense Automated Document Management System (DADMS) Number 4665 and The DoD Information Technology Portfolio Repository- Department of the Navy (DITPR-DON) Number is 11339.

An overview of the system including interfaces is provided in Figure 1.

Figure 1: Operational View MCRISS is the authoritative source for the recruiting process and records all prospecting results through accessions. MCRISS is currently a centralized, web-based, enterprise application and database Automated Information System. Updates to this system have been implemented to extend the user base to the RSS, OSS and PSRSS levels.

MCRISS is comprised of eight main modules and two supporting software applications. They are:

· Recruiting Station Module

· Officer Programs Module

· Recruiting Sub-Station Module

· Officer Selection Station Module

· Prior Service Recruiting Module

· Automated Enlistment Package Module

· Automated Commissioning Package Module

· Background Investigation Questionnaire Module

· Web Query Tool (Application)

· SQL Server Reporting Services (Application) MCRISS includes custom developed software, leveraging classic ASP and .Net V3.5 and V4.0 (written in C++) technologies, and configuration tailored Commercial-Off-The-Shelf (COTS) products. The system is comprised of multiple web, application, and database servers which operate in a Microsoft Windows Domain environment. MCRISS is resident on hardware hosted and located on MCB Quantico, VA. The current platform supporting MCRISS consists of the following components:

· VMWare VMWare ESX 5x (Virtual Infrastructure),

· Microsoft Windows Server 2012R2 DataCenter Edition (Operating System),

· Microsoft SQL Server 2012 (Relational Database Management System),

· Windows Active Directory (LDAP),

· F5 BIG IP (Network Loadbalancing, SSL Offloading, Web Application Firewall, Common Access Card (CAC) Authentication/Kerberose Ticketing Services).

· Imperva Database Application Firewall (DAF) appliance The MS SQL environment is comprised of an Online Transactional Processing (OLTP) Database, and an Online Analytical Processing (OLAP) Database, along with other database instances and nodes that run in a clustered environment.

TFITS Management Plan Table 1 identifies the TFITS Management Plans that provide overarching guidance for TFITS managed projects. These documents form the foundation for the baseline for TFITS common best business practices.

Table 1: TFITS Management Plans

Contractor Performance The contract shall be performed in accordance with this PWS and the Government’s Quality Assurance Surveillance Plan (QASP). Additionally the contractor shall perform in accordance with the processes and standards in the Contractor’s PDSS Plan, Software Development Plan (SDP), Project Management Plan, and Quality Assurance Program Plan (QAPP).

During the performance of the MCRISS activities, the SI will be required to work cooperatively with Government personnel and contracted support.

Objectives

· The PDSS and system maintenance and performance upgrades shall be performed, managed, and monitored consistent with the Government’s price, schedule, and performance objectives, through an integrated and defined set of project processes tailored from Capability Maturity Model Integration (CMMI) Level III equivalent or higher set of standard processes.

· Perform and implement system modifications and enhancements through Engineering Change Proposals (ECPs).

· The MCRISS system shall be available and operationally suitable on a 24-hour basis, 7 days a week (to the maximum extent practicable).

· Accurate and complete system documentation (configuration baselines, technical documentation, information assurance documentation, user documentation, web-based training (WBT), etc.) updates and any required certifications/accreditations shall precede the deployment of any capabilities.

Transition Throughout the phase-in/phase-out transition periods, the SI shall minimize interruptions or delays to work in progress. The SI shall provide a Transition Plan, provide transition update notifications, and submit an After Action Report. The Transition After Action Report shall be included in the Monthly Status Report (MSR) until the phase-in transition is complete. To minimize any decrease in system operational availability and to prevent possible negative impacts on PDSS services, the Government will require a transition-out period when the incumbent and new SI shall transition knowledge and understanding of MCRISS PDSS efforts and processes. The transition-out period will occur at end of the POP. The incumbent SI shall turnover all system documentation. The SI shall follow the Transition Plan submitted as part of proposal and fully inform the Government of the transition status throughout the transition period.

System Knowledge Transfer The SI shall have a complete and comprehensive understanding of the system.

At a minimum, the SI shall demonstrate an understanding of the following at the Transition Readiness Review:

Existing engineering and technical documentation The SI shall acquire the required level of system knowledge through the assimilation of information available in existing engineering and technical documentation. In addition, the SI shall identify and mitigate any engineering and technical knowledge gaps.

Existing user documentation The SI shall acquire the required level of system functional expertise through the assimilation of information available in existing user documentation. In addition, the SI shall identify and mitigate any user documentation knowledge gaps.

SI System Instantiation The SI shall have the capability to conduct defect management which includes the ability to replicate system failures, test software patches prior to production release, and test system development efforts. At a minimum, SI System Instantiation includes:

Production System Software A current copy of the production system software, including source code and stored procedures, will be provided as part of the transition process to support PDSS activities and instantiation of a production representative system in the SI’s environment.

Preproduction Environment A current copy of the preproduction system software, including source code and stored procedures, will be provided as part of the transition process to support PDSS activities and instantiation of a production representative system in the SI’s environment.

Development and SI Test Hosting Environment The SI shall provide the development and SI test hosting environment for the production representative system instantiation. The SI’s hosting environment shall be representative of the constraints and limitations of the production environment. The SI shall have complete understanding (activities, notional timeline) of what is required to be tested and verified.

Marine Corps Enterprise Development & Test Environment (EDTE) Transition The United States Marine Corps intends to offer a Government owned and operated private cloud environment providing IT system and application hosting services to support developmental and test activities. This capability will mitigate the requirement for the Government to contract external agencies and vendors to provide a hosting environment to conduct development and test functions. In support of the transition to the USMC EDTE, the SI shall support the instantiation of a production representative system, to include migration planning meetings, software installation, and application configuration, in order to conduct future development and test activities in the EDTE cloud environment.

Training Environment A current copy of the training environment system software, including source code and stored procedures, will be provided as part of the transition process to support PDSS activities.

Critical PDSS Transition-Out Activities.

During the transition-out period, the SI shall provide a detailed and executable plan to transfer on-going service support and service delivery activities to the new SI.

At a minimum, this includes:

Database administration System administration / Configuration Cybersecurity System interfaces Help Desk / Application Support and Escalation WBT modules, training, and training materials Table 2 provides the transition related meetings that requires SI participation.

Table 2: PDSS Transition Meeting Requirements

Phase-In Transition Activity The SI shall engage in the following activities throughout a phase-in transition period:

Obtain administrative access to the system as well as system interfaces.

The Government shall provide points of contact (POCs) to include telephone numbers and email addresses for the system, Functional Advocates, programmatic and technical POCs for interfacing system, and POCs for current hardware and software maintenance agreements.

Schedule, plan, and provide an agenda, a list of meetings to attend, and participate in three, one-day long working group sessions and/or meetings to facilitate knowledge transfer on system functionality. Days can be, but are not required to be, consecutive. One day is equivalent to a minimum of eight hours, not including lunch.

Government will provide physical access to all required system hardware and software within the Authority to Operate (ATO) boundary and/or Government-owned equipment for inspection and audit.

Participate in Transition Readiness Review.

The SI shall provide the government with a physical copy of the system source code.

PDSS

Service Support The SI shall develop and maintain the System Maintenance and Administration Manuals Develop and maintain environments Development Environment The SI shall provide and maintain a development environment that shall include all hardware and software required to maintain a production like MCRISS environment. All data in the SI development environment(s) shall be obfuscated.

Post-instantion of a development and test environment in the USMC EDTE, the SI shall maintain the application source code and server configurations to ensure functionality reflects the production environment. Remote access to the EDTE to manage and sustain the system development and test instances will be provided by the Government. The SI shall be responsible for coordinating system patches and maintenance activities with the EDTE service provider when such activities impact SI developmental or test efforts.

Preproduction Environment The government will provide a hosting environment for the pre-production environment. The hosting environment provided includes support of the network infrastructure, server hardware, server operating systems, and relational database management system (RDBMS). The SI shall be responsible for monitoring the health of databases, web portals and off-line system application. The SI shall be responsible for maintaining all software and application configurations, data, and supporting the upgrade of software components on MCRISS servers as required in support of maintaining a pre-production environment that functionally reflects the production system.

Production Environment The government will provide a hosting environment for the production environment. The hosting environment provided includes support of the network infrastructure, storage infrastructure, server hardware, server operating systems, and RDBMS. The SI shall be responsible for monitoring the health of databases, web portals and off-line system application. The SI shall maintain all software, application and database instance configurations. The SI shall also support the upgrade of software components on MCRISS servers as required in support of maintaining a functioning production system that meets all approved requirements.

Training Environment The government will provide a hosting environment for the training environment. The hosting environment provided includes support of the network infrastructure, server hardware, server operating systems, and RDBMS. The SI shall be responsible for monitoring the health of databases, web portals and off-line system application. The SI shall be responsible for maintaining all software and application configurations and supporting the upgrade of software components on MCRISS servers as required in support of maintaining a training environment that functionally reflects the production system. The SI shall refresh the data in the training environment on a periodic basis.

Help Desk The Government furnished tool is BMC Remedy. The SI shall use BMC Remedy to provide Help Desk support.

The Help Desk is the single user point of focus for support and for the reporting of incidents. The Help Desk processes include tracking and escalation procedures. The SI shall provide Help Desk metrics weekly, monthly, and annually as required. In addition, the Help Desk is responsible for disseminating information regarding planned outages and/or implementation of changes impacting production services.

The SI’s Help Desk will provide technical support and application assistance to users. The Help Desk is located at the James Wesley Marsh Center aboard MCB Quantico. The SI shall observe industry “best practices,” such as Information Technology Infrastructure Library (ITIL) v3 with the objective to receive, track, communicate (status to the user), and resolve user calls.

Help Desk Standard Operating Procedures The SI shall develop and document standard operating procedures (SOPs) that align to the MCRC incident and problem management processes for resolution of MCRISS application issues. The SI will maintain the documented SOPs within a single “MCRISS Application Help Desk Standard Operating Procedures (SOPs)” document. The MCRISS Application Help Desk SOPs shall be updated as required to appropriately document process changes, and at a minimum shall be reviewed on an annual basis.

Help Desk Hours of Operation The MCRISS Help Desk will provide normal Help Desk coverage from 0800-2000 ET Monday through Friday and one Saturday per month, as needed. Coverage hours will be expanded whenever planned downtime occurs for such things as software releases, patches, and security updates. In the event of such downtime, there will be additional Help Desk support beginning at 0700 ET the business day following the downtime period. As required, up to once per month, the Help Desk will provide expanded coverage 0800-0259 ET for extended processing days. There are no planned Help Desk Saturday hours or extended processing days in FY16.

Help Desk Services The Government provides Help Desk services supporting MCRC which will provide initial “Tier 1” MCRISS support. This initial “Tier 1” support shall include capturing the point of contact information of the user submitting the ticket and an initial problem statement.

The SI is responsible for providing a MCRISS Help Desk which shall provide technical support and application assistance to users. The SI shall utilize the government-provided Help Desk system, currently BMC Remedy, to document and store a record of incident and problem management activities.

The SI shall observe industry “best practices,” such as Information Technology Infrastructure Library (ITIL) v3 with the objective to receive, track, communicate (status to the user) and resolve user calls. Support of the MCRISS shall include support of multiple ITIL-defined support areas that are detailed in another section of this PWS. In support of the Help Desk service requirement, the SI shall propose a multi-tier Help Desk structure supporting MCRISS which shall provide incident and problem management.

Incident Management.

The primary focus of Incident Management is the restoration of services following an incident. Incident Management is primarily a reactive process; its processes provide guidance on diagnostic and escalation procedures required to quickly restore services. Incident Management processes are closely integrated with Help Desk, problem management, and change management processes.

The Government seeks an Incident Management Model supporting MCRISS with predefined steps that will provide diagnostic and escalation procedures to ensure quick restoration of services.

At a minimum, the SI shall provide Incident Management in support of the MCRISS consisting of, or providing, the following:

Detect and record incident details Perform incident management including performance monitoring, incident identification, diagnosis/isolating, containment, eradication, recovery and lessons learned.

Track incidents reported from the system users, the host site, and external interfacing systems.

Identify and report functions and files affected.

Prioritize incidents according to the matrix below in table 3:

Table 3: Incident Priority Matrix

OSS/PSRSS

Individual

Ensure all incidents reported during normal Help Desk hours are responded to, in accordance with table 4 below. Priority is described as a scale of P1- P4 (with P1 being the highest priority).

Table 4: Incident Priority Codes Priority Code

Ensure all incidents reported during normal Help Desk hours are responded to within the business day that the user’s phone call, voicemail, automated Help Desk system ticket, or email was received. Note: a response is defined as an email with the appropriate solution, procedure for action, or estimated time for resolution and the action being taken.

Ensure all incidents reported outside of Help Desk coverage hours, such as problems recorded via voicemail or submitted via email, are responded to no later than the business day following the user’s voicemail or email. Note: a response is defined as an email with the appropriate solution, procedure for action, or estimated time for resolution and the action being taken.

Communicate the incident to stakeholders.

Identify and report functions and areas affected.

Resolve incidents to support system operational availability.

Resolve incidents including performing diagnostics, fault isolation, containment, eradication, recovery and lessons learned.

Escalate unresolved incidents after 4 hours and define the relationship between the escalation process and the MCRISS’s ECP development process.

Restore existing system and data.

Restore system to full operational capability.

Prioritize incidents in terms of impact and urgency with the objective to minimize user impact.

Assess type and severity (e.g., number of users effected) of incident.

Assess impact to data integrity.

Reduce unplanned downtime hours.

Identify incident impact to the Government.

Recommend ratings for the priority and the urgency of each incident.

Escalate incidents.

At a minimum, the SI shall:

Provide Incident Management capability that contains a tiered structure of increasing system knowledge and IT expertise.

Resolve system access issues and restore basic system functions; route tickets; determine a solution; provide resolution to the end user or recommend an ECP to the Program Office, if appropriate.

Prioritize incidents for resolution at a Tier II or higher level.

Provide that all incidents are tracked for historical purposes.

Provide the Government with all documentation concerning incidents in the MSR.

The MSR shall include a report of the number of Help Desk tickets resolved during the first contact.

Escalate those incidents that require Problem Management resolution.

Provide Help Desk verification that the incident is closed and the system user is satisfied with solution.

Problem Management.

The primary focus of Problem Management is to identify the causes of service issues and conduct corrective work to prevent recurrences. Problem Management processes are reactive in responding to incidents and proactive in identifying and preventing incident recurrence. The SI’s processes are closely integrated with Incident Management, Change Management and Availability Management. Although Availability Management performs the lead role in component failure and system outage analyses, Problem Management performs an important role in obtaining data and analyzing data in support of the analyses.

Tier II issues require complex and in-depth analysis and knowledge of the application software, database, and architecture. In the case where Tier I Help Desk personnel are unable to resolve an issue, the issue will be escalated to Tier II (no later than four hours after initial review by Tier I). The SI shall develop their procedures for resolution of the issue.

Record, manage, and escalate service problems as appropriate.

At a minimum, the SI shall:

Record the escalation, progress status and final resolution in the Government’s trouble ticketing system. A CAC and a .mil email will be required to use the ticketing system.

Resolve the service issue at the Tier II level.

Escalate the service problem to the Tier III level for resolution if it cannot be resolved at Tier II within eight hours.

Report a summary of service issues in the MSR. Summary information to include how the issue was initially identified, what system service(s) were affected, how long it took to restore service(s), and lessons learned.

Analyze historical data to support predictive analysis to eliminate potential incidents before they occur and to document identified work-arounds.

At a minimum, the SI shall:

Maintain historical data in a Government-approved format for all service problems reported to the TFITS Product Manager.

Use a trouble ticket log to develop an analysis of trends to identify potential problems.

Provide the Government the results of problem trends in the MSR.

Diagnose root cause and eliminate recurrences.

At a minimum, the SI shall:

Provide the Government the potential causes of problems in its historical data.

Maintain historical data.

Using historical data, provide the Government the SI’s approach for preventing problems from recurring.

Prioritize problems, in terms of impact and urgency, to minimize system user impact.

At a minimum, the SI shall:

Assess and provide type and severity (e.g., number of users affected) of problem.

Assess and provide impact to data integrity to include efficiency and effectiveness of the system.

Reduce unplanned downtime hours.

Identify and report problem impacts to the Government.

Recommend the priority and the urgency to be assigned to each problem.

Inform the Government of the restoration of services of which will include, information from the Help Desk ticket such as effects of the incident to the user community and resolution.

Develop and document work-arounds or other solutions to incidents.

At a minimum, the SI shall:

Identify potential problems from the analysis of historical data.

Develop and document work-arounds and solutions to problems.

Present work-arounds to the government for approval and/or consideration for implementing an ECP.

Identify, develop, and submit ECPs to Change Management to eliminate known problems.

Configuration Management The SI shall follow the TFITS CMP. System Configuration Control will be implemented and inspectable through documentation.

At a minimum, the SI shall:

Maintain the TFITS Configuration Item Technical Data Base (CITDB).

Use the approved TFITS CITDB format and maintain the current data base containing the details of each system component. A CAC will be required.

Use standard TFITS processes to control changes to the CITDB.

Identify new Configuration Items (CI) and enter them into the CITDB.

Provide identification, collection, tracking, and maintenance of each unique CI comprising the system and sub-systems.

Perform change control processes that enable definition of the functional and physical characteristics of CIs in sufficient detail that they may be categorized.

Enable and implement the identification of the system items, components, and related work products that will be placed under CM.

Track and maintain Government submitted CIs in the CITDB.

Propose CIs which the SI deems necessary or offer significant benefit to the Government.

Collect, record, and maintain accurate information about CIs.

Track and record the status of CIs.

Respond to Government questions about system change approaches, estimated costs and schedules, as well as technical questions related to the program.

Implement the TFITS approved configuration control and approval processes required to change a CI’s attributes and re-baseline the CIs.

1.1.1.1 Upon transition to the EDTE development and test environment, utilize the Government provided toolset to maintain configuration control of application source code via a standardized check-in and check-out process.

Change Management Change Management manages changes being introduced in to the system. Change Management assesses risks of individual changes, uses configuration information to identify dependencies and other impacted applications and systems, and after analyzing the information, authorizes or denies change requests. The goal of Change Management is to identify application code, functional and performance defects and intercept them before Users are impacted.

The production system infrastructure is hosted on MCB Quantico. Assessment of changes to the infrastructure requires coordination between the host site, the user community, Marine Corps Systems Command (MCSC), the SI, and other Stakeholders. The SI may propose changes but must receive approval from the Government to execute ECPs. The SI shall ensure and provide that its change management processes align with the TFITS management plans.

At a minimum, the SI shall:

Contribute and record decisions and updates to any relevant products in tailored System Engineering Technical Review (SETR) events, Functional Review Boards (FRBs), Engineering Review Boards (ERBs), and CCBs.

Pre-screen and categorize the need per the ECP definitions and the Government’s CMP.

Provide a preliminary impact assessment to support the CCB’s evaluation for each ECP presented to the CCB.

Maintain and update SI-specific data elements of the Government’s ECP Tracker System. A CAC will be required for access.

Provide a Level of Effort (LOE) to include the Lifecycle hours for ECPs at the ERB. Provide a Rough Order of Magnitude (ROM) detailed lifecycle estimate for those ECPs approved by the CCB.

At a minimum, the SI shall:

Identify, research, develop, and classify ECPs.

Provide a lifecycle LOE estimate for hours and effort required to complete ECPs.

Provide ROM-detailed lifecycle estimate ECPs approved by the CCB.

Identify application code defects as well as functional and performance defects, and submit ECPs as appropriate.

Identify and resolve the defect and ensure the system is working as designed.

Use quality assurance processes to reduce software defects.

Use software development processes to reduce software defects.

Use human factors engineering processes to reduce software defects.

Release Management Release Management is closely integrated with Change Management. Release Management manages changes to the environment such as installing vulnerability patches and software release/changes and/or refreshing technology.

At a minimum, the SI shall:

Provide all technical and non-technical aspects of a release, including developing, updating and maintaining system baselines, system documentation, user documentation, training documentation, and supply support materials.

At a minimum, the SI shall:

Provide technical aspects such as: regression testing; testing documentation; remediation of identified defects; the update of system documentation, configuration status accounting data; information assurance scanning.

Provide non-technical aspects such as: coordinating system changes with the host facility; identifying the needed training; developing and updating user documentation including training documentation; and release notes and version description document.

Plan and support the successful roll-out of software and related hardware including the required test, evaluation, and Government acceptance processes.

At a minimum, the SI shall:

Provide a repeatable training, test, and deployment strategy and schedule for planned enhancements and upgrades.

Create and deliver Software Test Plans and Software Test Descriptions that are traceable to requirements.

Support the Government’s Systems Engineering team during Government Acceptance Test (GAT) and assist, when required, with input required to complete Test Incident Reports (TIRs).

Support the Government’s Systems Engineering team with input required to complete GAT Scorecards, reflecting all completed test scripts, remaining test scripts, number passed, number failed, and status of failed tests to be delivered to the Government by close of business (COB) of each testing day. The Software Test Plan with Test Scripts and Cases shall be delivered at the TRR.

Resolve all Severity 1 (Showstopper) and 2 (High) TIRs and other critical issues and update system documentation prior to test completion.

Manage, integrate, and deploy upgrades upon Government acceptance (including production environment regression testing).

Schedule all planned system releases during the approved MCRISS maintenance window. The MCRISS maintenance window is currently a four hour window which is available for use on Wednesdays from 2100 to Thursdays at 0100 ET. Note: The date and timeframe of this window will be changed at the discretion of the Government based on the risks associated with or magnitude of changes included as part of a release.

Design, implement, and support efficient procedures for the distribution, installation, and verification of changes including the client application.

Coordinate and prepare the Advocate and system user community for new release capabilities.

At a minimum, the SI shall:

Provide user training documentation, technical documentation, and other user support material in accordance with the TFITS SEP.

Provide a system notification to all system users prior to implementing any release.

Ensure implementations are traceable, secure, and that only correct, authorized, and tested versions are installed.

Coordinate and plan releases with Change Management.

Provide master copies of all deployed software and update the CITDB.

Provide that all hardware either being rolled out, or changed, is secure and traceable using the service of CM.

Document release plans in a Deployment Plan that, at a minimum, contains anticipated changes to be deployed (e.g., vulnerability patches, software upgrades, defect patches), plan of action and milestones leading up to monthly deployment, CIs that need to be updated (e.g., technical documentation, System Maintenance and System Administration Manual, CITDB, User Manual, Training Material), and a contingency plan.

Support the Government Post Implementation Review (PIR) in accordance with the TFITS management plans.

Cybersecurity Management Marine Corps Order 5239.2A establishes an information systems lifecycle management approach to protect critical Marine Corps information and intelligence. The SI will execute to the requirements within this order. The level of protection will be aligned with the Mission Assurance Category (MAC) III code.

The SI shall have knowledge of and support all certification and accreditation (C&A) activities throughout the system lifecycle in accordance with the latest releases or revisions of the following policies located at :

· http://www.dtic.mil/whs/directives/index.html/

· http://csrc.nist.gov/publications/PubsSPs.html The SI shall support the requirements of MCO 5239.2A[footnoteRef:2] by establishing and implementing proactive protection, detection, reaction, disaster recovery, and restoration capabilities to include the detection and reporting of unauthorized activities. The level of protection will be aligned with the MAC code assigned to MCRISS. [2: Or latest version.]

At a minimum, the SI shall:

Maintain the system’s ATO, review and update documentation (including but not limited to the Systems Information Profile (SIP), Department of Defense Information Assurance Certification and Accreditation Process (DIACAP) Implementation Plan (DIP), and Cyber Engineering Plan), and fulfill all annual cybersecurity requirements for a MAC III Sensitive program.

Ensure all DoD information system cybersecurity-related documentation is current and accessible to properly authorized individuals.

Provide awareness and prevention through assessment and implementation of best practices (code reviews, system scans, vulnerability alerts, vendor notifications, Security Technical Implementation Guides (STIGs)).

Implement cybersecurity best practices to increase the security of the system and eliminate vulnerability threats to include code reviews, system scans, vulnerability alerts, vendor notifications and STIGs.

Ensure all security updates and patches are tested and applied to software and operating systems in accordance with the TFITS SEP.

Ensure all vulnerabilities identified by the hosting facility’s vulnerability scans are incorporated, mitigated and documented.

Conduct code reviews in accordance with Marine Corps policy, using approved automated tool(s), to ensure development of secure and quality code in support of the application.

Conduct Cybersecurity risk analysis to include identification and mitigation of cyber security risks to COTS software.

Facilitate and participate in and provide timely completion of Annual Security Reviews, Annual Security Control testing, Annual Contingency Plan testing, and quarterly update, and submission of quarterly POA&M updates in compliance with the Federal Information Security Management Act (FISMA).

Use the Government’s IA tool to submit, maintain, and review C&A documentation and workflow. The Government will assist in gaining access to the tool, as well as training for the tool.

Support the Government engineering team to register any software implemented on the systems for Marine Corps use in DADMS prior to any system upgrade. The SI shall complete and submit DADMS questionnaire as required.

Facilitate the protection of US Government sensitive, unclassified, and classified information by working closely with the government Information Systems Security Manager (ISSM), Information Systems Security Officer (ISSO), and staff.

Review, implement and report applicable Information Assurance Vulnerability Management (IAVM) and Operational Directives (OPDIRs). Monitor and comply with all DRRS-MC applicable notifications and advisories, including but not limited to Information Assurance Vulnerability Alerts (IAVA), Information Assurance Vulnerability Bulletins (IAVB), Information Assurance Vulnerability Technical Advisories (IAVT), MARADMINs, OpDirs (released on SIPRNET), and DISA STIGs through the TFITS SETR process.

Confirm compliance of annual IA awareness training status for all privileged users.

Review vulnerability assessment scans provided and provide technical guidance on remediation and (including use of STIGS), and develop Program of Action and Milestones (POA&M).

Provide a monthly identification of vulnerabilities and remediation’s in accordance with Communications Tasking Order (CTO) 08-005 Scanning and Remediation and DoDI 8510.01.

Request and maintain a Marine Corps Certification Accreditation Support Tool (MCCAST) account and ensure all documentation is uploaded and up-to-date.

Review documentation, support pre-assessment, review vulnerability scans, test result evaluation, and review POA&M for Independent Verification and Validation (IV&V) test events as necessary.

Review documentation, support pre-assessment, review vulnerability scans, evaluate test results, and review POA&M for Command Cyber Readiness Inspection (CCRI) events.

Service Delivery Service Delivery processes assist in the identification of delivered or provided services, tailoring of services, the timely provision of services, resources, capabilities, and capacities to meet MCRISS’ needs.

Service Level Management Service Level Management (SLM) processes provide a framework by which services are defined, levels of service required to support business processes are agreed upon, and Service Level Agreements (SLAs) developed. SLM processes clearly define IT and business roles and responsibilities and establish clear goals for service delivery so success factors can be established, measured, and reported.

At a minimum, the SI shall:

Manage and provide system performance in support of SLAs, Interface Control Documents (ICDs), and System Interface Agreements (SIAs).

Develop and maintain an SLA, ICD, and SIA for system interfaces.

Plan for changes to SLA, ICDs, and SIAs when there is a change to the system or external interfacing systems. Ensure data transfers are executed according to existing SLA, ICDs, and SIAs in a timely manner with accurate data.

Manage and monitor performance of system interfaces including web services. System interfaces will operate accurately in accordance with Government-approved design and maintain 99.9% level of availability.

Perform the SI role and responsibilities per approved SLAs and participate in the update of SLAs.

At a minimum, the SI shall:

Measure performance, report results, and adjust as necessary.

Report results of performance metrics to the Government as defined in the TFITS management plans and QASP.

Link performance metrics to risk assessments.

Provide mitigation strategies for risks and issues affecting performance.

Continuity Management.

IT Service Continuity Management (ITSCM) provides a framework for developing IT infrastructure recovery plans in support of business continuity management. MCRISS shall maintain Continuity of Operations and Confidentiality in accordance with DoD Instruction (DoDI) 8500.2 for a MAC Level III Classified system. This DoDI outlines the roles, responsibilities, and processes to be enacted in the case of circumstances preventing the continuity of the system. MAC III Sensitive systems have an expectation of being available to its users within a certain period of time following a downing event. In addition, the system has a Recovery Point Objective (RPO) of five days and a Recover Time Objective (RTO) of seven days. Information regarding system recovery plans is found in MCCAST. The SI shall implement a system recovery plan that meets with Government approval. The SI shall ensure that, in accordance with DoD Directive 5230.25, all personnel having access to the system will have appropriate security clearances.

At a minimum, the SI shall:

Conduct risk assessment of IT services to identify the assets, threats, vulnerabilities, and countermeasures for each service.

Conduct risk assessments in conjunction with Cybersecurity Management on a quarterly basis.

Identify and provide threats and vulnerabilities upon completion of the risk assessments.

Provide the Government with risk mitigation strategies for identified program risks as well as the monitoring process to evaluate the impact of mitigation efforts.

Evaluate options for recovery.

Securely maintain system data for recovery.

Control electronic and physical access to system data.

Test, review, and revise the continuity section within the System Maintenance and System Administration Manual as needed.

Utilize the results of the government approved test in Cybersecurity as required by the DoDI 8500.2 and provide corrective actions for analysis to the government.

Capacity Management Capacity Management is responsible for ensuring that IT infrastructure resources are in place or available to satisfy planned needs and that those infrastructure assets are effectively used. Capacity Management is responsible for identifying anticipated growth demands. Activities in this area are proactive rather than reactive, finding application and infrastructure bottlenecks at current and future demands so that corrective actions can occur before service issues are experienced by MCRISS users.

At a minimum, the SI shall:

Monitor the performance and throughput of the system.

Monitor and collect system infrastructure metrics per the TFITS PMP.

Provide metric reporting to the Government in the MSR.

Perform analysis of measurement data, including analysis of the impact of new releases on capacity and system performance.

Conduct data analyses.

Integrate risk management into its assessment process.

Project future capacity needs and how those projections are incorporated into its capacity management process.

Identify and implement performance tuning activities to ensure the most efficient use of existing infrastructure.

Monitor, collect, and analyze established metric data identified by the Government.

Provide metric reporting to the Government in the MSR.

Manage the demands on the Service and future plans for growth (or shrinkage).

Prevent system performance degradation.

Respond when performance degrades.

Provide appropriately skilled personnel with the technical expertise to analyze system performance and remediate.

Provide influence demand for computing resources.

At a minimum, the SI shall:

Identify changes in system and user needs for changes in system computing resources.

Prevent the demand for computing resources to exceed deployed system capacities and capabilities.

Conduct risk assessment of infrastructure and planned capacity needs to be integrated into the risk management processes.

Integrate Capacity Management information within risk processes.

Provide the Government with results of risk assessments in the MSR.

Availability Management Availability Management is responsible for ensuring applications are available to the Users. The process ensures Government system availability requirements are being achieved and ensures the most cost-effective contingency plans are put in place and tested on a regular basis to ensure Government availability needs are met.

The SI shall ensure that the pre-production and training environments are operational and properly configured when needed to support a particular event.

At a minimum, the SI shall:

Ensure service (system) availability meets System User’s…