DevSecOps is a way of IT Application Lifecycle Management (ALM) where the security aspect is embedded with the DevOps software delivery framework. DevOps (Development and IT Operations) was an application-centric discipline whereas the SecOps (Security Operations) was mapped to the infrastructure-centric discipline. DevSecOps fallow security practices embedded early in the lifecycle of software, with integration to the IT estate's security needs across the platform, storage, cybersecurity, information access, and data flow.
In the previous articles of DevOps Value Chain and DevOps in 21 Century, we have seen the various needs of an IT Estate. Landscapes are diverse and expanded, it needs a nimble process to meet the varied demand for change - Omni-Speed IT. This speed of change can at times result in overlooking critical security controls, putting the business vulnerable. Thus came the need for making security a 'must have' requirement for any software application development. In this document, we will explore what it takes for a DevOps setup to become a DevSecOps.
In traditional security operations, the primary focus used to be on infrastructure domains like platforms, networks, focusing on external attacks over networks, physical security of premises, operating systems, firmware, etc. The application-level security like Identity and Access Management (IDM), Governance Risk & Compliance (GRC), Roles and Authorization were managed as a division within application support. Few areas around IT controls and compliance was at times left to be reactive in nature around audit risk mitigations. Thus application security was cyclical and not continuous. Some key vulnerabilities like data in motion, rouge behavior of staff, loopholes in software code which could compromise the integrity, authorizing excess access, etc. were overlooked. In ERP applications, code-level security or even a security design approach in an implementation is seldom an afterthought. Pick any analyst report and search for top priorities for a CIO, and Security would be there in the top 3. This has created the need to relook at an IT estate from the lens of security for the right treatment. Security needs are thus beyond user access and authorization.
The infographics below explain DevSecOps, how we embed Security in the Application Development Cycle. This software application security is integrated with the infrastructure security operations of the IT estate.
 |
What are the phases of DevSecOps?
We will consider what is the differential changes to an existing DevOps setup here. This has the same six distinct phases of DevOps with a twist.
The journey starts from planning. Any change, whether through a new requirement, modification, or enhancement of existing functionality will start with this phase. When a requirement is captured, it has to be validated and the purpose understood. The lifecycle of the requirement, access needs, who are authorized to view, the data it accesses, stores or modifies, the information it transfers, the criticality and sensitivity of the data it needs to works on, compliance to regulations, etc... These specifics are to be mapped, and in your template for requirement specification documents, the section for security requirements should be created and filled.
The realize phase is when the software build and testing of the requirement will take place. The software takes its shape. It is very important to embed security principles here. For example, all code development will need to be evaluated for code vulnerability assessment, and undergo testing. Even all configuration changes have to meet all compliance and mitigate any identified risk. Security testing like role-based testing will need to be augmented with penetration testing, automated vulnerability checks, encryptions, certifications, etc. Even security designs are to be made such that even an authorized person sees only that data which is the minimum one needs to complete the task. Enabling of logging and alerting would be needed as those are the hooks that will integrate the solution with the Security Operations Center (SOC). Security Quality Gates will need to be enabled at every handshake of the application life cycle.
in the deployment phase, the work package is prepared and released in the live environment. Based on the nature of the application product, it could be a major release, a minor release, or a new solution cut-over. Whatever may be the scenario, the work package that will be transported or compiled into, would need to be statically tested for any security vulnerability. Compliance tools like SOX conflicts are to be mandatorily checked before deployment. This is the last gate to check before a code goes live. The lifecycle of the requirement has now reached the go-live state and is into its maintenance. Any security defect that is found hereafter would be costly to repair and remediate. Security Design and Configuration documents are handed over to the support team and the system is hooked up to SOC.
In the run phase, the software application is maintained and observed to be working as per the requirements. System alerts, logs, user behavior are recorded and analyzed. Regular and dynamic vulnerability checks are conducted. Applications are also continuously monitored for any new emerging risk or vulnerabilities, need for software patching or upgrades, user access, licenses, data access, etc. Any threats need to be immediately dealt with. SOC operations can be autonomous or manual but are very important to be effective. The Security Runbook is updated regularly and all incidents are recorded.
In the improvement phase, the software application is being monitored, measured, and managed through the active engagement of architects and business analysts. Process improvements are continuous for any emergent application. Automation and reducing overheads are other drivers for further optimization. Many a time these exercises will lead to further requirements, which could be new, modified, or enhanced change. A Continuous Improvement Process needs to be set up that collates and looks at the holistic picture and proposes the opportunity to improve. IT security audit findings and observations also leads to changes and mitigations. These plans thus start as the requirement and go back to the requirement process, which starts with a plan. Thus the application lifecycle.
How do we implement DevSecOps?
To implement DevSecOps, an IT estate or an IT service provider will need to focus on four areas of governance, practice, process, and tool.
Governance will need to focus on establishing operations and compliance framework that looks deep into IT Security requirements, business requirements, the future roadmap. The group will need not only inputs from inside the organization, but also have awareness of the changes in the external eco-systems. It needs the existing change and release mechanism to be revisited to accommodate the additional checks and balances before it signs an approval. The governance model will need to take accountability for the events, logging, and controls that get monitored and analyzed. This group has to have visibility beyond just applications but to the infrastructure and the entire span of security scope.
Practice has to be developed for the practitioners to be self-aware of the need for DevSecOps. Learning and training are a must, for awareness. Everyone should understand the important role each one plays in the chain of events, and what the risks are, and how they are mitigated. The fort is as strong as the weakest wall. Developing the right skills and the right behavior is required. The competency and capacity will need to be developed.
Process changes are a must. Security alerting and tracking is a must. Although this is not new in the infrastructure space, for many in applications space this will be something altogether new. System and audit log-based triggers and tracking would increase greater scrutiny and the same would be used by the Security Operations Centre for monitoring and alerting. In some of the ERP applications and also many applications that were behind secured networks did not spend resources in code and configuration vulnerability checks. this will need to be enforced.
Tool will play the most important role from tracking to corrective measures. Software code vulnerability assessment products have to be embedded in the ecosystem. Testing automation is a must. Governance Risk and Compliance software will play a pivotal role in housekeeping and tracking changes. These tools will need to be integrated with the change and release tool and process. A roadmap is developed on the onboarding of these tools.
Conclusion:
DevSecOps is an integral part of the software development lifecycle and will need to be treated with importance. This will need to be in the top 3 of the charter for any IT lead. This will need to bring in behavioral change in approach, treatment, and adaptation. The change management involved is not very complex but adds to the complexity of an already complex web of change and release processes.
Did you know the toolchain bundled within your SAP Enterprise Support holds the key to a successful and effective DevSecOps for your SAP estate? To look at these building blocks, do read Extending DevSecOps to your SAP Landscape
-- x --
