Migration From DevOps To DevSecOps - A Complete Migration Framework, Challenges and Evaluation-Jul-12-2020-0359
Migration From DevOps To DevSecOps - A Complete Migration Framework, Challenges and Evaluation-Jul-12-2020-0359
Migration From DevOps To DevSecOps - A Complete Migration Framework, Challenges and Evaluation-Jul-12-2020-0359
The customary way of adding security at the end of a product life cycle was inherently
slow and became the reason for slaw and faulty delivery. This accelerated the need for
automating the security testing process and a collaborative working style of security team and
DevOps team. This requirement strictly stated that these two should not work in silos and should
be in tune. The concept of DevSecOps is then explained the idea of delivering security as a code.
DevSecOps Centre of Excellence (EGT LAB) defines the best practices of DevSecOps as
establishing a security culture, coaching, security first design, automation, build-deploy-test
often and DevSecOps friendly acquisition (E global tec, 2018).
DevOps was not very much in differing to security. DevOps features such as consistency,
auditability and increased predictability favoured security; but was worried about the security
issues in faster production, more deployments, less test cases and no audit (Storms, 2015).
DevSecOps addressed these issues by embedding security at the very basic level of development
and promoted threat hunting, immutable infrastructure, security auditing and monitoring, cost
reduction by ensuring customer value, culture of openness and transparency and measuring
ability (Raynaud, 2017).
Integration security in DevSecOps adopted the style of shifting security to the left. This
facilitated the development process by reducing the time and cost incurred if a rebuild of
software is dispensed (Ebert et al, 2016). This migration should consider the different layers of
security integration such as infrastructure, platform and application (Myrbakken et al, 2017). It
has been suggested by software practitioners as DevSecOps should focus on software quality and
security, compliance requirement and risk avoidance in the process of software development and
deployment (Synopsis, 2018) .
DevSecOps practitioners cautioned the migration team that they should try adapting
security with operations not vice versa and remember 100% security is not attainable. The rest of
security can be compensated with security applications, identify and remove known
vulnerabilities, train developers on security coding and will definitely ease the migration process
(KnowledgeHubMedia, 2017). Some common security measures that will reduce these
unexpected issues after implementing are sanitizing the input to block common attacks like
buffer overflows, SQL injection and cross site scripting (MacDonald and Head, 2016).
This area of DevSecOps is still in its budding stage and practitioners are fighting to get
good references for their migration. One best practices suggested for the migration include good
documentation, strong collaboration, process automation and enforcement of separation of duties
(Mohan et al, 2018). Stemming NIST framework along with the DevOps delivery pipeline is one
method adopted for DevSecOps implementation in healthcare sector (Colomo-Palacios et al,
2013).
Another challenge this collaboration of security face is the mandatory information
sharing happens between the teams when the integration takes place. Even though it is very
necessary for a smooth integration of functions it will have incalculable security implications. It
is better to have a proper policy defined for this information sharing before the organizations
plan for DevSecOps migration (Mohan et al, 2016). This integration and collaboration may also
result in unauthorized access and the policy should address it very carefully without hammering
the very basic idea of collaborative environment (Rahman and Williams, 2016a.). One major
challenge identified is the slow maturation of the security tools which will enable the integration
of security in DevOps environment (Hulme, 2018).
Another challenge this migration is bringing to the organization are the conflicts in
workgroups and the problems in group dynamics. One research suggests the use of agency
theory to solve this issue by defining the development team as the agent and customer as
principal. The conflicts happen in the goal attainment can be addressed by goal abstraction and
information transparency (Lee , 2018).
Lack of a standardized model is troubling the migration process and organizations are
eager to know their DevSecOps adaptation posture. The only one model available is a
DevSecOps maturity model is defined with the stages Burp, Crawl, Walk, Run and Fly
(Lietz,2016). The different aspects of DevSecOps like the definition, security best practices,
compliances, process automation, tools, software configuration, team collaboration, availability
of auditing data and information security is analyzed to find the momentum of this concept in the
software development methodology (Mohan et al, 2016).
We are at the very nascent stage of DevSecOps migration and organizations are still
having no clue about how to approach the change and how to benchmark their progress.
Researchers and DevSecOps practitioners are working together to find out a comprehensive
model which can be used as a checkpoint when the organizations migrate to DevSecOps
approach. This paper is trying add to the research area by integrating all the different aspects of
security migration in to a single framework and provides a consolidated technique to fix the
problem that organizations undergo when migrating to DevSecOps. This framework is unique in
the aspects that it comprehensively covers all the different components of information system
development and their contributions to the DevSecOps migration.
Migration to a new platform always brings risks to the organization. Companies are still
not a position to talk about the DevSecOps migration risks and challenges as it is just started
experiencing it. They trying to align it with many other migration scenes and finding out the
possible risk factors that the migration should care for. Agile and to DevOps migration and cloud
migration are the recent past in the software development framework and this study does a
literature review on the challenges, risk factor and issues identified in these migration and the
framework evaluation.
Basically the risks associated with any migration can be categorized as business risk,
organizational risk and technical risk. A decision support system to decide the cloud migration
identifies the risks as Business value, organization function, Confidentiality, integrity,
availability and transparency (Islam et al, 2017). A cloud migration framework is evaluated
using different parameters categorized as generic and cloud specific risks (Gholami et al, 2016).
All the migration is talking about the basic business attributes such as cost saving, efficiency,
scalability and maintainability (Rai et al, 2015) (Taibi et al, 2017). This pointed to the fact that
any type of migration should take care of the business and its basic functioning mechanism
keeping in mind the intangible benefits of it.
Based on this basic idea on how a new software development framework should be
evaluated and what are the challenges the migration will face; we are defining the factors on
which our DevSecOps migration model should be evaluated. This study also identifies the key
challenges in the migration process and how the model addresses it with the aid of the
components identified.
3. CONCEPTUAL FRAMEWORK- MIGRATION FROM DEVOPS TO DEVSECOPS
A smooth transition from DevOps to DevSecOps requires complete strategy and should
own a secure culture. Unplanned and unthoughtful migration may not achieve the main purpose
of DevSecOps. Before integration into DevOps, security teams should undergo a series of
homework including risk assessment, threat modelling and defining security baselines. This
helps the security team to flawlessly integrate security in to the automated CI and CD phases.
The migration framework explained bellow talks about the following components.
• Levels of migration
• Migration Strategy
• Migration Procedure
• Support functions
• Tools
Figure 2 shows the complete migration framework including all the above mentioned
components and their interrelationships. It provides an instrument to identify the tools used in
every stage of integration and the support functions at each level that needs to be aligned with
the migration.
Figure 2 Migration Framework
3.1 Levels of Migration
DevSecOps migration strategy is focused on four levels: Governance, People, Process and
Technology (Moore and Bovoso, 2018) (Wootton and Erkunt, 2018).
• Governance
Governance is the base level from which the migration should start from by ensuring the
top management support for the security integration to DevOps. This may necessitate a complete
remodeling of the governance and compliance framework with proper delegation of authority to
the operational support.
• People
People, considered to be the weakest link of security plays an important role in
DevSecOps migration too. They are responsible for removing the silos by communicating
effectively in the entire process of DevSecOps migration (Raynaud, 2017). They need to
innovate and adapt quickly to the new environment (Myrbakken et al, 2017) to make sure that
the inclusion of Security into DevOps does not ruin the speedy delivery concept of DevOps.
Proper communication, feedback mechanism and employee training is effectively included in
this migration framework as migration procedures and support functions.
• Process
Aligning the software development process with security is the important concern in
DevSecOps migration (Myrbakken et al, 2017). There should be a proper integration of security
process to the development and deployment process flow adding incident response, clear
documentation and version control (Ebert et al, 2016) (Wootton and Erkunt, 2018). It should
include a policy to move security to the earliest, for standard enforcement, security testing,
release and deployment (Storms, 2015). Establishing a concrete DevSecOps practice is necessary
to make sure that the new security process does not affect the agile behaviour of DevOps.
• Technology
At this level the focus will be to identify the extent to which technology can enable the
migration process. The migration framework identifies the repetitive tasks for establishing
security and applies automation to the utmost level it can. Host hardening, CI/CD patching etc.
are some of the examples of the technology adaption for DevSecOps migration (Raynaud, 2017)
(Myrbakken et al, 2017). Technology should aid the reduction of manual intervention in security
testing so that the migration to DevSecOps will be smooth without any hurdles and delays.
3.2 Migration Strategy
The strategy for the migration to DevSecOps describes the approach organizations
follows while migrating which ensures all the aspects of migration has been taken care of. We
suggest set of migration strategy which extensively covers all the phases of migration starting
from understanding the requirements to continuously monitoring and vulnerability management.
Strategy 1: Understand DevSecOps and it’s extend with depth.
Strategy 2: Identify requirements of DevSecOps.
Strategy 3: Gather required tool set and infrastructure changes
Strategy 4: Harden the core infrastructure and integrate secure development tools
Strategy 5: Adopt secure development processes with enhanced security automation.
Strategy 6: Integrate security controls and compliance automation tools and practices in
operations
Strategy 7: Continuously monitor and analyse output at each process and integrate feedback
mechanism for entire lifecycle to continuously update security posture.
Strategy 8: Set vulnerability management program, threat intelligence mechanism and red team
for security testing at regular interval as well as in ad-hoc manner.
3.3 Migration Procedure
After identifying the levels and understanding the migration strategy, this framework
defines the migration procedure from DevOps to DevSecOps which involves the following steps.
• Step I : Initial assessment of entire DevOps process
• Step II : Imbibe Threat Modelling to secure network
• Step III : Harden the development environment
• Step IV: Integrate security tools in development environment and then proceed for
coding.
• Step V : Update security definitions and integrate tools to automate code review
• Step VI : Integrate extra layer for compliance and penetration testing by Red Teams
• Step VII: Secure configuration and deployment procedures and automate the process.
• Step VIII: Establish monitoring, intrusion detection mechanism
• Step IX : Setup rollback mechanism in case of incident and app update tools
• Step X : Automate log and incident analysis using tools
• Step XI : Setup repose process, escalation ladder and remediation process using enhanced
tools
• Step XII : Integrate tools to predict upcoming security requirement
• Step XIII : Establish feedback mechanism in the entire lifecycle to speed up changes
• Step XIV : Train employees while establishing new procedures and adopting new tools
• Step XV : Threat Intelligence and Vulnerability management program will update
security tools
• Step XVI: Continuously optimize the process to maintain speed and agility with security.
We have also identified that component in the migration frame work which will aid the
DevSecOps practitioner in addressing the challenges. We have identified it in two different
dimensions as the level at which the challenge should be addressed and the support function
which will aid the migration framework to overcome the challenge. Table 3 describes this
concept and identifies a matrix for the challenges.
The challenges vary from different aspects of implementation and requires a wholesome
method to identify and rectify it. This model clearly enumerates all the challenges and how it can
be rectified with the help of the migration framework suggested. It highlights the fact that there
should be collaborative environment as suggested by the migration framework in the
organization to make this transition smoother and effective.
5. FRAMEWORK EVALUATION MATRIX
A framework developed need to be evaluated considering the factors that attribute it in
the business space. The challenge was to identify that factors which can be used to evaluate the
migration framework. Since at the organizations are still struggling to find a way to migrate to
DevSecOps, the framework evaluation is a distant dream.
Table 4 Challenges addressed
In this research we are trying to evaluate the conceptual model, even though in the very
preliminary stage by identifying the key factors. Since no model is developed and tested, we are
taking the background study of other major migrations occurred in the software industry as cloud
migration and DevOps migration. These two migrations also created a major breakthrough in the
software development scenario, the factors taken from that background was convincing enough
to evaluate the framework.
The key factors identified are listed below. We have classified these factors on the basis
of the four levels that we have identified in the framework as Governance, People, Process and
Technology. We could also connect it with the eight challenges and how these factors are
addressing it. Later we have analyzed how this model addresses the business, organizational and
technical risk that comes as a byproduct of the migration.
1. ROI
For any business process, ROI is perceived as an important issue. If migration is the only
choice, business need to find a way to accept it. Calculating ROI in terms of financial attributes
in one way to evaluate the model.
2. Business Value Increment
The business value in terms of profit, growth, service enhancement and low maintenance
are the measures of success of a new model. Evaluate it on qualitative terms to judge the model.
3. Transparency to the stake holders
Every business has a commitment to the stakeholders to make the process as transparent
it can. The more transparency it can bring, the better will be the model. Migration framework can
be evaluated on the basis of transparency it adds to the entire scenario change.
4. Business Process Refinement
Any update of an existing model should bring some change in the business process. The
model can be evaluated on the basis of the refinement it brought to the existing model.
5. Business Domain Adaptability
Every business domain will have its own peculiar characteristics. The migration should
be in such a way that the adaption to the business domain is stress-free.
6. Business Environment Friendliness
The external environment pedals the business to a very great extend in a veiled way. The
migration should consider the external factors and should make sure that it addresses all those
concerns.
7. User Training Requirement
Any change requires user training. The migration should be evaluated on the basis of the
new training requirement that arise and how the transition can be smoothened.
8. Organizational Structure Re Architecture
It will be a big pain to the management if the organizational structure need to be revised
as part of the migration. The migration model is evaluated by the top management on the basis of
how much painless will be the re-structuring, still performing the necessary tasks.
9. CIA Confidentiality, Integrity, Availability
As we are embedding security in to the DevOps environment, the extent to which the
three basic attributes of security are handled is another evaluation criterion for the model.
10. Maintenance Reduction
Any new model or a migration should reduce the complexity of the maintenance that will
be required in the next stage. This should make the distribution simplified and contribute to the
understandability.
11. Scalability to Technology
Scalability makes sure that it can be easily adapted to any new technology which may
come in near future. In this frequently changing technology era the migration should foresee the
changes and should prepare the migration to accept the change.
12. Infrastructure Flexibility
Infrastructure of the organization should be prepared enough for the migration. The
flexibility of your organization to adapt to the migration is another area of evaluation to be done.
13. Platform Support
The operating system and the network architecture is another area where the migration
should happen and is where migration evaluation should happen.