MOD CRP - Modernising Patching Alpha Agile Development and Cloud Deployment (DevOps & Support)

Tender description

Summary of the work The Ministry of Defence (MOD) is seeking to procure a Supplier to deliver an Alpha implementation of a MOD owned and designed bespoke capability that provides secure patch acquisition and distribution services to meet the evolving needs of the MOD Enterprise. Expected Contract Length 6 months, with an optional extension of up to 1.5 months Latest start date Monday 11 October 2021 Budget Range It is estimated that the work can be delivered, with the skillsets requested, within the budget of £600,000 (exclusive of VAT) Why the Work is Being Done Defence is a complex enterprise operating in all five domains. The cyber domain is becoming increasingly critical as operations in the ‘information age’ rely daily on connected capabilities to underpin strategic, operational, and tactical outputs. Exponential growth in systems that rely on software components drives equivalent expansion of the need to maintain and update all components to safeguard against emerging vulnerabilities. The volume and pace at which vulnerabilities are exposed, exploited and weaponised is ever increasing. Remediation must also keep pace. Defence faces the same challenges as the global IT industry, whilst also facing the threat of determined adversaries seeking disruptive effects across the five domains. All these threats are persistent in nature and global in scale due to the connected information age. The critical nature of patching to maintain the health and security of systems means that there is a large marketplace available providing off the shelf patch management tools. The services available in the marketplace do not realise all MOD requirements within a single solution. The MOD has commissioned the generation of a Modernising Patching Strategy to plan and direct the way in which Defence approaches the challenge of maintaining and updating its capabilities and systems. Problem to Be Solved The Alpha patch acquisition and distribution capability will be the first iteration in delivery of a MOD owned centralised cloud patching solution. The phase outcome is to develop and test with a set of early adopters, an accreditable cloud (Azure & AWS) hosted capability, that securely enables easy patch and firmware consumption through automated and manual mechanisms. The Authority has responsibility as the Design Authority, for the technical design, IPR and management of requirements of the Alpha phase. The successful Supplier will be required to undertake a collaborative approach to enable the fulfilment of the requirement. The Supplier should include the following in its response: a. Capability Delivery through delivering software development, tool customisation, capability testing. Expected magnitude of resources. Using an assumption 1 Story Point = 1 Person Day of effort, t approximately 780 story points are required between October 2021 and March 2022 b. Capability Support through providing service administration and support as the Alpha capability is made available to early adopters. T approximately 60 story points are required between February 2022 and March 2022. c. Authority Integration through providing management and technical support to Authority led activities. Who Are the Users Defence capability operates in the traditional domains of Maritime, Land and Air. This drives complex physical constraints on the operation of digital capabilities. Digital technology in defence is integrated in nature, embedded in weapons systems, complex platforms and mission critical information systems. Defence capabilities do not follow an IT industry standard or pattern. Systems do not always have traditional network solutions, modern connection quality or physical security. Users demand far more than office-based working patterns or business availability targets. In IT terms, normal assumptions do not apply. Work Already Done Discovery phase completed, outputting User Requirements and Alpha Architecture. Existing Team The existing team which will act as the technical authority consists of: Project Manager Requirements Manager Product Owner Senior Technical Lead Cloud Architect Security Architect Security Assurance Controller Current Phase Alpha Skills & Experience • Experience of developing, deploying and supporting a large-scale system on Azure and/or AWS in an agile manner. (Experience with a system deployed across multiple different clouds would be an advantage.) • Provide details of the agile process(es) used for such development. • Provide details of automated Continuous Integration and Deployment tools created/configured/used. • Provide details of "cloud native" services/technologies used (cloud technologies beyond running VMs in the cloud). Experience with containerised systems would be an advantage. • Provide details of implementation and use of Management Information (MI) systems, dashboards and other tools to support, manage and continuously improve a large cloud-based system. • Can you provide the following Capability Support Services: Core hours (08:00 - 18:00 Mon-Fri), Extended (07:00 - 19:00 Mon-Fri) Out Of Hours (24/7) for incident management, response, release activity • Detail how you scale up engineering skilled resources to meet customer demand at pace • How will you integrate with our in-house engineering resources seamlessly, share knowledge, provide skills transfer and develop our resource's capability? Include tools/best practice/past examples. • Demonstrate how you'll provide an integrated SCRUM Master managing daily delivery of teams, allocating resource to agile ceremonies, respond to requirements for incident, problem resolution, technical requirements reviews. Nice to Haves • Describe and evidence your ability to work with Cloud service providers ( Microsoft and AWS) to manage and maintain infrastructure and platform services, working collaboratively to resolve platform incidents? • Provide an example of your experience of delivering within large scale deliveries with multi-faceted workstreams? • Describe your ability to demonstrate keeping your workforce up to date with current and emerging technologies and toolsets? • Provide examples of developing, supporting and maintaining a large multi-cloud system (a system in which different interacting components are running on different cloud platforms). • Describe any developer experience with Public Key Infrastructure (PKI) or Business Process Management (BPM) tools and technologies. Work Location Multiple locations, including, but not limited to: Remote Working MOD Corsham, Bath MOD Abbey wood, Bristol MOD Main Building, London Working Arrangments The supplier staff will be expected to primarily operate in-line with CRP team hours: Monday to Friday 0900-1700, however flexible working can be agreed if it doesn’t affect delivery or meeting attendance. The primary working location will be remote, with occasional travel to the MOD premises to collaborate with stakeholders. Meeting cadence to be agreed between the Authority and supplier upon contract award. Security Clearance All Supplier staff shall hold a Security Check (SC) clearance for anyone actively engaged in the delivery of services within the contract from the Point of Service Engagement. Additional T&Cs To proceed to Stage 2, suppliers must clearly demonstrate ability to view and respond to OFFICIAL SENSITIVE materials. Annex C - Official and Official-Sensitive Contractual Security Conditions MPP Alpha Evaluation Criteria https://drive.google.com/file/d/1wwQlc_OZN2CkWM6xJrjrgx6AG0BSy-Gf/view?usp=sharing No. of Suppliers to Evaluate 5 Proposal Criteria • Provide up to 3 examples of relevant previous contracts worked on in the past 2 years. Examples must show the skills/experience of resources who’ll be working on this requirement. (20%) • Describe the approach you’ll take to meet CRP requirements. How you’ll manage the work and maintain quality. Describe any innovations you would propose in the delivery of the requirements. (20%) • Describe the specific technical / Agile approach you’re proposing. The capability should be demonstrated with an example showing where this has been delivered elsewhere previously. (25%) • Describe the team, how they’ll work together and with others. List the number of roles, responsibilities, relevant qualifications. Demonstrate how quickly the team can be mobilised and ramped up. (15%) • Describe how your proposal will optimise costs and generate savings. Please give details of previous experience optimizing cost for a customer like Cyber Resilience Programme (10%) • Describe your method for measuring and maintaining speed of delivery, including your approach taking accountability for achieving deliverables (5%) • Explain any risks and dependencies identified and your proposed approaches to manage them. Set out how you will identify and manage risks and dependencies during the contract. (5%) Cultural Fit Criteria • Describe how you will work as a team with The Authority and its stakeholders, in a transparent and collaborative approach to share knowledge with wider teams and build capability (25%) • Describe how your organisation will create employment opportunities particularly for those who face barriers to employment and/or who are located in deprived areas (25%) • Describe how you will create employment, re-training and other return to work opportunities for those left unemployed by COVID-19, eg: workplace schemes and opportunities for apprenticeships and traineeships (25%) • Exhibit a ‘can-do’ attitude, seeking resolutions rather than problems, when addressing operational and developmental issues. Use initiative to take ownership of problems and issues to ensure a successful outcome. (25%) Payment Approach Fixed price Evaluation Weighting Technical competence 70% Cultural fit 10% Price 20% Questions from Suppliers 1. The link for the evaluation criteria on google drive does not work. Would it be possible to provide a working link. New working link:https://drive.google.com/file/d/1YWOjpzh-fMuJR-Ie9dSZJNR8r8hyJjdb/view?usp=sharing 2. Is there is an incumbent supplier? There is no incumbent supplier for the service as described. 3. Which supplier delivered the Discovery Phase? The Discovery Phase was delivered by an Authority lead team. 4. Is the budget of 600k covering the additional 1.5m extension as well as the core 6 months? The £600k budget is for the initial term. 5. What is the scope of the patching? Applications only? Everything on MOD Cloud? Please clarify Ultimately everything within the MOD that requires a software or firmware update is in scope for patching, including OSes, applications, firmware for network infrastructure, etc. 6. Where would the service transition to? Incumbent, existing team, etc.? The Authority plans to tender for subsequent Beta and Live phases which shall deliver additional capability and provide operational support. 7. Is there a design already in place for the expected solution? The Technical Authority (TA) has produced a Conceptual Architecture for the patching capability, as well as, Cloud Architecture documentation. This is an Agile project and as requirements are evolving, the design documentation will continue to evolve in line with this. 8. Please explain how you see BPM fitting into a patching system requirement? The BPM is intended to orchestrate flow within the system in order to deliver a large degree of flexibility (compared to hard-coding the same logic) in how the system can be configured and used. This is motivated by the likelihood of emerging and evolving requirements. 9. Is the intention integrate commercially available patching solutions to meet the MOD’s req’s or is a bespoke solution preferred? It is the intention to develop a bespoke capability that incorporates commercially available solutions (e.g. Microsoft Windows Server Update Services (WSUS)) that meet the specific patching needs of the MOD. 10. Please can you provide a clear set of requirements as to how you would like us to “demonstrate ability to view and respond to OFFICIAL SENSITIVE materials”. We do not want to spend the effort to be shortlisted to then later find that MOD are not happy with our solution and won’t share the documents for the next stage. Suppliers are required to demonstrate that they can receive, store and respond to the OFFICIAL SENSITIVE material that will be included as part of the next stage of this process. Suppliers will not be scored at this stage by the demonstrated method(s), as long as the chosen method is accredited. 11. The Problem To Be Solved overview is very limited. Could you elaborate on the outcome(s) specifically required/desired in the Alpha Phase? And what other phases will include. Will subsequent phases seek to broaden out content consumption and delivery to a wider audience or will they include other additional services? The primary outcome of the Alpha Phase will be a Cloud Hosted Capability that enables a pre-selected set of early adopters to pull an agreed list of patches to enable the patching of the systems they are responsible for, this capability will require technical support to be made available to the early adopters to enable them to exploit the benefits delivered by the capability. The supplier will also be required to provide management and technical support to Authority led activities.Additional information will be provided to shortlisted suppliers as it is OFFICIAL SENSITIVE. 12. Who is the author of the Modernising Patching Strategy and what is in scope for this Alpha requirement? Scope of Alpha referenced in answer to question 11, The Modernising Patching Strategy was produced by MPP Technical team, on behalf of the MOD Defence Digital SRO for patching Additional information will be provided to shortlisted suppliers. This information is not being provided at this stage of the tender process as it is OFFICIAL SENSITIVE. 13. Could you confirm what patch content the Existing CRP team needs to consume via the platform during the initial Alpha phase of 6-7.5 months? Is there a product or vendor list for which patches and updates should be consumed by this Platform within the Alpha phase of development? The Alpha Phase is being delivered inline with the Minimum Viable Product (MVP) generated by the Modernising Patching Project Product Owner. The MVP is evolving to align with the MODs highest priority requirements, at present, the MVP includes, but is not limited to, delivery of Microsoft patches available through Windows Server Update Services (WSUS). 14. Does the remit of the CRP’s accreditable Platform include trusted data verification for patch/update content within it at this Alpha Phase? The patches that are acquired by the capability will need to undergo integrity checking and malware scanning. 15. Is this Alpha Project looking to deploy and support internal service offerings within MoD Cloud, ICE and ACE environments? The aim of the Alpha Phase is to deliver a Patching Capability that is hosted in MOD Cloud to enable a pre-selected list of early adopters to patch systems across the MOD Enterprise.The ambition is to provide a multi-cloud solution running in both ICE and ACE, but this is subject to change and may not be deliverable for Alpha. 16. Will partners currently assisting the CRP team with this requirement be eligible to bid directly or indirectly for this requirement? The Authority will allow suppliers to operate on both the client and supply side providing an actual Conflict of Interest (COI) or potential COI can be satisfactorily managed to avoid any unfair distortion in competition. If a supplier identifies an actual or potential COI where it may be possible to mitigate the risks, the supplier must demonstrate how they could resolve it within their proposal submission. 17. Where do you envisage the central repository to be housed? For the Alpha live and staging systems, patch repositories will be held in the cloud using managed SQL DB service (for meta-data) and object storage (for files). We will also maintain the capability to run the system on-premises if required (using our own SQL DB and object storage instances) and will simulate this in the cloud in an Integration environment. 18. Would you have cache repositories closer to the cloud components to reduce network tromboning? The conceptual architecture includes Distribution functions. For the Alpha these will be located only in the cloud and it's anticipated that this should be sufficient for most office-based clients. However, beyond Alpha, for clients with intermittent or no connectivity it's anticipated that there will be a need to support local Distribution functions. 19. You have mentioned patching firmware, firmware is associated to physical hardware so would this be needed as it is all virtual? Although (for Alpha) this system will be entirely virtual the patches it contains are to serve the wider enterprise, including devices that require firmware updates. From the perspective of this system there is not likely to be a material difference between a software patch/update and a firmware patch/update, firmware is mentioned to help clarify the eventual scope of the system. 20. What parts of Azure/AWS do you want to patch ie. Compute and Blockchain or all services AI + ML, Analytics, Blockchain, Compute, Containers, Databases? The system runs in the cloud and provides patches for the (much) wider MOD enterprise. While components of the system may themselves consume patches from the system (for example, if the system is running virtualised RHEL instances these will themselves require patches) we will not be "patching" cloud services provided by Azure and AWS - just consuming them. 21. Many services in Azure and AWS patch themselves ie. Managed Instance of SQL how would you want to tool to exclude trying to patch these? Where we can consume managed cloud services we will leave such management up to the cloud provider. If a cloud provider (as a supplier to the MOD) also becomes a consumer of our patches then that would become a separate matter (they would be just another client from our perspective). 22. Do you want to patch software that has been acquired from the Azure/AWS marketplace? This isn't a target for Alpha capability. 23. How will you test the patches before they are deployed? Acceptance testing of patches is not currently in scope for Alpha, it is currently a matter soley for the client system owners. For Alpha only malware scanning and integrity checking will be undertaken. 24. What patching schedule are you looking at? The Alpha Capability that is delivered by the supplier will be subject to a two-week patching schedule (microservices rebuilt with updated dependencies, etc). Consumers of patches from the Alpha Capability will be responsible for defining their own patching schedules. 25. How will you report and remediate any patches that fail? The patch failure may occur due to a number of reasons, including, but not limited to:- Failed Acquisition or Delivery- Failed internal integrity check or Malware Scanning- Failed during System Owner Acceptance Test or Application/InstallationIn all of these scenarios, the supplier will be required to provide a Support Capability that provides a process for resolution (to be be agreed with the Authority). This resolution may not require patch remediation but will involve support to patch consumers and an investigation to the cause of the issue. 26. How will you ensure the patching service does not get compromised? The system will be subject to security accreditation by the MOD. Which will be lead by the Technical Authority team, with the supplier supporting 27. With responses to questions up to and including 19th August is the deadline of the 20th extendable affording time to consider the responses? No extension will be afforded. 28. Does the remit of the Alpha Phase require both Azure and AWS capability outcomes or just one or the other? Currently we expect to run the system on both Azure and AWS (ICE and ACE) for Alpha for High Availability but this may be subject to change based on the constraints/provisions of MOD Cloud. 29. Is the Authority seeking a fixed time and materials price response or a fixed pricing for deliverable outcomes within the Alpha Phase? The Authority is seeking a fixed price for the outcomes described in the Problem to be solved section. 30. Please can the supplier confirm how they would like the 100 word example response to be structured in response to the question ‘How will you integrate with our in-house engineering resources seamlessly, share knowledge, provide skills transfer and develop our resource’s capability? Include tools/best practice/past examples. The Authority is looking for a description of the approach the supplier will undertake, this could include one or more previous examples of where you have applied this approach. 31. Please can the authority confirm how they would like the 100 word example response to be structured in response to the question ‘How will you integrate with our in-house engineering resources seamlessly, share knowledge, provide skills transfer and develop our resource’s capability? Include tools/best practice/past examples. The Authority is looking for a description of the approach the supplier will undertake, this could include one or more previous examples of where you have applied this approach. 32. Please can the authority confirm whether they are looking for a previous example, or for us to demonstrate how we would approach this delivery for the question ‘Demonstrate how you’ll provide an integrated SCRUM Master managing daily delivery of teams, allocating resource to agile ceremonies, respond to requirements for incident, problem resolution, technical requirements reviews. The Authority is looking for a description of the approach the supplier will undertake, this could include one or more previous examples of where you have applied this approach. 33. Please can the authority confirm whether, in the 100 word response, you are looking for an example of where we have scaled before, or how we approach scaling generally, for the question:‘Detail how you scale up engineering skilled resources to meet customer demand at pace' The Authority is looking for a description of how the supplier will source and scale resource to meet the project demand, as well as previous examples of managing changing resource demands in projects.. 34. Can the authority confirm if they are looking for a positive statement of yes/no or demonstration of previous experience for the question ‘Can you provide the following Capability Support Services: Core hours (08:00 – 18:00 Mon-Fri), Extended (07:00 – 19:00 Mon-Fri) Out Of Hours (24/7) for incident management, response, release activity’ The Authority is looking for a positive statement, this could include one or more previous examples of where you have met this demand. 35. Will the modernised platform need to consume content during critical situations such as when gateway connections are closed? Continuity of distribution of acquired patches is more critical than continuity of acquisition of new patches. However, the system should be robustly Highly Available (HA) with respect to both acquisition and distribution. (Possibly with less seemlessness required on the acquisition side). 36. Is patch distribution to cloud connected end users only? For Alpha our direct clients will require network connectivity to our system. This connectivity may not be direct and they may not have any cloud resources of their own. They may then re-distribute patches to end-users by their own means. 37. Is there a target minimum timeframe for a patch file to be made available from Vendor file release to its usage/availability for use? Additional information will be provided to down selected suppliers. This information is not being provided at this stage of the tender process as it is OFFICIAL SENSITIVE. 38. Please can the authority provide clarity on the experience/scenario that is being asked to be demonstrated and with the question:Provide details of the agile process(es) used for such development. Does the response for Q2 need to describe the agile processes used in the case study for Q1? The examples provided can be different for each of the questions.