Overview

Software development best practices are ever-evolving as new ideas, new frameworks, new capabilities, and radical innovations become available. Over time we witness technological shifts that relegate what was once state-of-the-art to be described as legacy or deprecated. In wireless, 2.5G systems have been fully retired, 3G systems were aggressively replaced by 4G LTE with shutdown dates publicly announced, and now 4G LTE is being supplanted by the rise of 5G. Software is no different, and Practices depicts the broad trends over the last 30 years. Different programs and application teams may be more advanced in one aspect and lagging in another.

 

While tightly coupled monolithic architectures were the norm, the growth of finely grained, loosely coupled microservices are now considered state-of-the-art and have evolved the Service Oriented Architecture (SOA) concept of services and modularity. Development timeframes have compressed, deployment models have shifted to smaller containerized packaging, and the cloud portends to deliver an endless supply of computing capacity as infrastructure for compute, storage, and network have shifted from physical to virtual to cloud.

The shift towards DevSecOps, microservices, containers, and Cloud necessitates a new approach to cybersecurity. Security must be an equal partner with the development of business and mission software capabilities, integrated throughout the phases between planning and production.

The alluring characteristics of DevSecOps is how it improves customer and mission outcomes through implementation of specific technologies that automate processes and aid in the delivery of software at the speed of relevance, a primary goal of the DoD’s software modernization efforts. DevSecOps is a culture and philosophy that must be practiced across the organization, realized through the unification of a set of software development (Dev), security (Sec) and operations (Ops) personnel into a singular team. The DevSecOps lifecycle phases and philosophies, depicted in Figure 4, is an iterative closed loop lifecycle that spans eight distinct phases. Teams new to DevSecOps are encouraged to start small and build it up their capabilities, progressively, striving for continuous process improvement at each of the eight lifecycle phases.

 

The Security value of DevSecOps is achieved through a fundamental change in the culture and approach to cybersecurity and functional testing. Security is continuously shifted left and integrated throughout the fabric of the software artifacts from day zero. This approach differs from the stale view that operational test and evaluation (OT&E) and cybersecurity can simply be bolt-on activities after the software is built and deployed into production. When security problems are identified in production software, they almost always require the software development team to (re-)write code to fix the problem. The DevSecOps differentiation is realized fully only when security and functional capabilities are built, tested, and monitored at each step of the lifecycle, preventing the security and functional problems from reaching production in the first place.

Each of the shields surrounding the DevSecOps lifecycle in Figure 4 represents a distinct category of cybersecurity testing and activities. This blanket of protection is intentionally depicted surrounding the eight distinct phases of the DevSecOps lifecycle because these tests must permeate throughout the lifecycle to achieve benefits. Failure to weave security and functional testing into just one of the eight phases can create a risk of exposure, or worse, compromise, in the final production product.

Some people describe DevSecOps as emphasizing cybersecurity over compliance; this is recognition that you can be compliant, but not secure, and you can be secure, but not compliant. Sidestepping the debate on the fairness of this characterization of DevSecOps, the below considers the specific characteristics espoused by DevSecOps practitioners:

• Fully automated risk characterization, monitoring, and mitigation across the application lifecycle is paramount.
• Automation and the security control gates continuously evaluate the cybersecurity posture while still empowering delivery of software at the speed of relevance.
• Support meeting Cyber Survivability Endorsement (CSE) Cyber Survivability Attribute (CSA) number 10 – Actively Manage System’s Configurations to Achieve and Maintain an Operationally Relevant Cyber Survivability Risk Posture (CSRP).

 

Application Assessment

DCS provides a thorough assessment of an Application’s composition to determine the proper modernization and migration methods necessary to host an Application in a DevSecOps environment and capitalize on cloud services.

DCS will then develop a modernization plan for an application applying Cloud Native Design Principles and prioritize use of Software as a Service (SaaS) and Platform as a Service (PaaS) over Infrastructure as a Service (IaaS).   

Areas of focus for the Application Assessment Report include, but are not limited to:

• Application Architecture: Analyze the application structure (presentation layer, application layer, data/layer repository) and the ability to virtualize it as well as identify the integration of the common services required along with the native cloud services to be used.
• Data: Analyze the applications’ data schema, data transfer and database requirements and identify potential alternatives to meet the Government’s objectives for reduced cost or improved data accessibility.
• Performance: Analyze the application’s performance and throughput requirements to identify equivalent performance requirements are met with the post migrated, cloud-based, application. Specifically analyze the impact of changes in network latency on application performance.
• Availability: Analyze the application’s Recovery Time Objective (RTO) and Recovery Point Objective (RPO) and data replication requirements.
• Integration: Analyze the application integration requirements and determine whether any modifications are required to the hosting environment to include those required to support legacy system interfaces.
• Operations: Analyze the operational and maintenance needs of the application and whether it can be supported by the hosting environment.
• Cybersecurity Risk Assessment: Analyze an application’s cybersecurity risks including code STIG and design flaws that would prevent the application from operating securely in the new target hosting environment.
• Cost & Schedule: Analyze the application’s modernization, migration and hosting cost as well as schedule to migrate. DCS has extensive experience using the US Army Cost Benefit Analysis (CBA) methodology developed by Deputy Assistant Secretary of the Army Cost & Economics (DASA-CE) for cloud migration course of action (COA) selection.
• Target CSP Environment: Analyze whether Application X is more suited to AWS and/or Microsoft Azure
• Licensing: Analyze if and how licensing associated with Application X will be impacted by proposed modernization and migration.

 

Modernize and Migrate Application

DCS will provide application modernize consultation.  DCS will ensure that the application modernized fully complies or exceeds the RMF categorization security requirements in the DoD Cloud Security Model SRG

DCS will develop an application transition and cutover plan and ensure that application modernization and migration is compliant with Agile/Development Security and Operations (DevSecOps) methodologies.

In addition, DCS will:

• Collaborate with the Government to establish application access controls
• Determine and integrate the required common services for the application
• Conduct unit testing and user acceptance testing (UAT) including providing test scripts/test reports to the Government PMO
• Assist the Information System Security Engineer (ISSE) and/or the Information System Security Manager (ISSM) in conducting A&A to demonstrate that the Risk Management Framework (RMF) requirements have been met.
• Migrate the application to a DevSecOps production environment based on a “go-live” decision

 

Operations, Maintenance and Continual Enhancement

Using Agile/DevSecOps principles, DCS will provide application operations, maintenance, and continual enhancement activities such as, (but not limited to):

• Patch Application, Platform and Operating System as appropriate
• Fix Production Defects
• Fix Cybersecurity Vulnerabilities
• Provide other Application-level CSSP Support: non inherently-governmental application cybersecurity services as defined in DoD Instruction 8530.01 Cybersecurity Activities Support to DoD Information Network Operations to Protect, Detect, Respond, and Sustain applications and data in the commercial cloud

DCS will ensure that all current application architectures are maintained in a government repository.  

DCS will develop an application Service Level Agreement (SLA), which shall minimally include the following metrics:

• Availability: defines system/service uptime and accessibility
• Reliability: measured against mean time between failures (MTBF) and mean time to repair (MTTR) or return to service
• Recovery Point Objective: permissible data loss within a service or group of services
• Recovery Time Objective: permissible time to recover to operations

 

Optional Training

A key element of the DCS DevSecOps service offering is the concept of “Right to Hire” contracting labor similar to that used in agile commercial environments and/or specialized government focused DevSecOps training. 

The “Right to Hire” concept allows government organizations to hire DCS contractors who performed well after six months on a contract.   The government will be free to negotiate terms directly with DCS contractor.

Government focused DevSecOps training includes access to DCS created customized DeVSecOps online training modules based on the “Platform One” architecture.   This training includes full online mentoring.    All DCS supplied contractors will have completed the full DCS Platform One training curriculum prior to engaging under our DCS GSA contract