DevSecOps - Embedded Security With Omni-Speed DevOps

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.


DevSecOps








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.


In the design phase, the requirement is mapped to an IT specification. Traditionally workshops are done for new and complex designs with help of process consultants and business analysts. If the requirement is simpler, still it used to go through minimal scrutiny through a process consultant.  When one has to design a process, a security consultant would now need to be included along with. This consultant would play the role to map the requirement to security actionable. The consultant would need not only to understand the role and access design but also Center of Internet Security (CIS) benchmark best practice, Open Web Application Security Project (OWASP) standards, International Organization for Standardization (ISO) standards, General Data Protection Regulation(GDPR), Sarbanes-Oxley (SOX) Act, International Traffic in Arms Regulations (ITAR), IT Infrastructure Library (ITIL) standards, other various Personally Identifiable Information (PII) requirements, various country-specific compliances, etc. They will also need to identify the security requirement that goes beyond the applications in the domain of infrastructure and engage the right architects. The deliverable of the technical design document will have a section on security design.


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 --

Extending DevSecOps to your SAP Landscape

IT managers would at one point wonder 'How do I transition my SAP Ecosystem to an effective and efficient DevSecOps compliant landscape?'


In the earlier post, we read about how one can transition to DevSecOps. But SAP landscape has some inherent challenges to the industrial definition of DevSecOps. It has multiple development environments that integrate into almost all technology platforms. A business process transcends multiple systems, both SAP and non-SAP.


Did you know the toolchain bundled within your SAP Enterprise Support holds the key to a successful and effective DevSecOps for your SAP estate? 






The Challenge:

Let us understand the challenges in an SAP Estate and how we can help them to adopt agile and DevOps approaches.
1. Not Continuous Not continuously integrated or deployed. Typical releases are monthly, while at best daily emergency changes are only moved. No simple rollback approach. The deployment integrity is part of the software architecture itself.
2. Complex Maintenance All major deployment has multi-layered integration and security needs. Outages and downtime high risk and business impact making lifecycle management a complex orchestrated task.
3. Tailored Solution Customized solutions and customizing functional configurations are huge investments, that accumulated over time and difficult to discard. Fit-to-standard where not possible leads to tailored solutions.
4. Cost of Ownership High solution ownership cost, both license, and infrastructure. This limits the availability of parallel systems, building environments on demands, etc. This is the reason why multiple projects run and share the same system.
5. Practice Gaps SAP development and configuration process has its own methodology and thus gathered inertia. SAP consultant, develop and release management need to adapt to a process that bridges that gap.
6. Tooling No single solution to support all SAP DevSecOps requirements thus the requirement of defining the toolchain that will support the governance framework. Existing toolsets thus require tweaking to adapt.

The Toolchain:

Using Solution Manager as the core below is a proposed Solution Inventory of DevSecOps Building Blocks. The tools marked with Asterix (*) are products that are not bundled in the enterprise service. They could be part of your license bundle, else could also be purchased separately. There are other OEM that also provides tools to supplement these building block in case something is not available for use. Except for Dynamic Security Testing and Performance Testing, all other products come from SAP as of date.

SAP Solution Inventory of DevSecOps Building Blocks


In your DevOps landscape, most of these products may be already available and configured. In that case, a fit-gap study would be required and deployed. Even if one does not have a set-up ready, a roadmap can be developed with sprints for early business value realization.


Thus the first step to a DevSecOps can be set up using your SAP Enterprise Support products from SAP. A foundation technology platform is available, which can be configured to scale-up, scale-out, and optimize as per your business needs.


--x--


---------------------------------------- Acknowledgments Of Contribution ---------------------------------

Thank you all for the thoughts and action on this evergreen topic of DevOps and DevSecOps and help develop proof points and take them to customers.  Vikas GoyalNiharika GoyalPatro SrinivasRajesh DadwalSulagna DasguptaMriganka BasakAbhilasha SinghRavi Shankar OjhaPooja GuptaSoumen sasmalKULDEEP SINGH. Thank you, Kapil Pandey, as a DevSecOps architect for guiding us all to excel in what we do. Team #SAPbyHCL #ArtOfPossible