Given the great migration to the cloud and management platforms, like Kubernetes, there is an enormous focus on DevOps processes and distributed applications based on microservices. DevOps and the larger microservices environments, including cloud-based targets and flexible infrastructure, add a great deal of complexity to security. Incorporating security thinking and processes into DevOps’ practices addresses the DevSecOps challenges presented by new microservices landscapes. As APIs and containers and Kubernetes play larger roles in application fast-moving CI/CD pipelines, security will depend on this DevOps integration more than its particular toolsets.
DevSecOps is more than a corporate buzzword. As a combined term, DevSecOps bears out the interdependence of responsibilities that lead to security transformation from a fixed set of inflexible tools into security as a process.
So what are the challenges that prevent a business from moving into a DevSecOps mindset? How do we solve for them?
Security Can Be a Natural Part of DevOps
Security testing can be easily incorporated into the testing phase of any integration or deployment. The ROI may not always be as evident as it is following a breach or code issue, but hindsight has little value. Since it can be integrated at any point, why aren’t we optimizing for it?
Rethink Security & Improve Code Quality
The way we think about security is an enormous obstacle to DevSecOps. Most people don’t see the immediate value add. Instead, security is often seen as a sacrifice of time and resources for a “what-if” doomsday scenario.
Security adds tremendous positive value if we broaden our understanding of testing. It doesn’t have to wait for deployment or be limited to application checks. The most comprehensive security checks can be done on the total environment.
By testing throughout the CI/CD lifecycle, teams get ahead of security issues and help improve code quality. Continual testing can identify repeat issues and systemic problems.
For example, you may have a problem with your timed delivery due to code that goes unidentified until after shipping. Identifying recurrent problems outside libraries can help create cycles with a better overview of new input and ultimately up code quality. Problems unique to your business can be discovered and resolved before problems arise.
So, the real transformation from DevOps to DevSecOps is the movement from security in a stack to enabling developers with security processes. Technically, there is nothing stopping developers from testing apps before launching new code. That will only happen if the business processes support and help developers to establish security as a primary KPI.
For its part, security can create policies for developers to generate tests for their apps and fix issues ahead of releases. Operations can help Development test apps in each development stage, setting workflows and processes accordingly, and only release apps after testing is complete.
4 Steps to Develop Your DevSecOps
There isn’t time to do everything we should do for security, which is why it’s important to automate and understand how to prioritize according to personal business logic.
It is impossible to apply all the tests and variance we know and then generate and analyze the results of hundreds of thousands of requests on any particular app in a timely manner. To fit with CI/CD timelines, testing needs to be done in a couple of hours or during nightly builds at most, including running functional, security, and all other tests.
The right security-as-a-process planning, processes, tools, and demonstrable adoption will help make the Security in DevSecOps more realistic. Here is a basic overview of what you can do.
#1 Prioritize Security Areas & Goals
Just as processes vary across organizations, so do security priorities. The first step in creating a working DevSecOps organization is to identify which types of tests should be applied and how. The planning and action plan phases identify your particular threat landscape and simultaneously bring together the leadership and goals of Business and Security.
Plan Around Your Security KPI’s & Goals
Never trust one-size-fits-all security promises.
Build a security framework particular to your organization and security needs. It should center around realistic KPIs. What your security landscape looks like depends on the overall business environment, including organizational structure, product lifecycles, business goals, and the processes implemented within the organization as a whole and in individual departments.
Professionals with experience in security audits know that security solutions and planning are particular to each company, and it’s impossible to cover 100% of the variables. Say you identify every anomaly. In the era of big data, the resources to manually sort that would be astronomical. Automation helps, but cannot be randomly and globally applied.
Start by auditing your organization, running a risk assessment, and looking at your own organizational and processes infrastructures. Ask people from the same industry and the same business types and of similar maturity to share their own practice and experience.
Create an Action Plan
No one can solve for everything in the era of big data and quick CI/CD, as explained earlier. Effectively integrating security into DevOps without KPIs and goals is impossible. Targeted security actions are vital.
Action plans have to be based on understanding what’s implemented and the best practices related to your particular organization. Consider the security issues for an established enterprise or storefront company with 25 years of operations that is conducting most business offline or relies on on-premises servers and databases. Compare that to an e-commerce or modern enterprise company. Their business is oriented to the internet and mobile traffic and likely has multiple websites and more complex IT architectures.
Once you choose best practices, Security can actually develop a security integration plan or other action plans specifically tailored to your business vulnerabilities and needs.
#2 The Right Processes
Integrate security testing into a testing framework.
Once you begin integrating security according to your threat landscape, you need to be targeted around real and priority threats based on your framework. Wallarm products, for example, are designed specifically for application-level security; featuring Layer-7 deployment. We could have built a lot of security products and frameworks, but we saw a problem arising from changing technological and business environments. Project managers and developers are moving fast under the pressure of fast software lifecycles and continuous deployment. To adequately protect the concerns arising from those changes, security has to be native to that location, not a foreign agent sitting far away and speaking in a different language. It has to be able to understand and work with these challenges at the application level.
Align Developers and Security
Cross-functional support and adoption of a security mindset need to have actual communication pathways open. Leadership across departments needs to make room for and positively nurture these relationships. Create shared dashboards, align workflows, build in transparency, and schedule meetings where everyone has a seat at the table. Encourage cross-team communication and smash organizational silos. Include Business, so that DevSecOps is aligned with the functional goals of product and demands generated by the customer base.
Security and Development both have to start with a shared understanding of the product requirements, relevant business and user needs, and team relationships. Then, each needs to compassionately understand what the other is being measured on. For example, programmers need to know specifically what stored procedures you cannot trigger, what code you cannot generate, and other parameters for security requirements.
#3 The Right Tools
New tech that plays well with others.
Make more go further with friendly tools that amplify existing security. You don’t have to get rid of legacy tools and procedures. You have to be sure that the old tried-and-true isn’t leaving areas unprotected.Think Ahead to Easy Adoption
Find tools that can play nice with existing security tools and protocols to help extend the time and resources your existing security team has. Look for out-of-the-box, quick-deployment utility that will increase adoption with minimal disruption to your CI/CD. Automating the iterative aspects of threat detection and resolution helps both security and QA teams.Scalable Tools & Automation
Consider technology better suited to the new development environment; it’s likely that the strongest security tools will have to grow and adapt to an ever-changing threat environment and multivariant development protocols and nuances. AI-powered security tools, machine learning, advanced neural networks, and specialized security can help security teams cover more ground with less work.
#4 Adoption of DevSecOps
The final stage is adoption. Putting the goals, processes, and tools into action is the final and most crucial part of creating a robust DevSecOps mindset. That means continually having security as part of training, oversight, and thinking.
Get Everyone Onboard
Starting cross-team talks to align leadership in Development, Operations, and Security (and we’d recommend including business leaders from other areas, like Product) is essential to truly integrate security.Onboard Everyone
Training for all teams is important to assuring real security. Set up policies and train employees, making sure there are regular security audits, best practices, and compliance measures that team leaders are responsible for enforcing. Everyone who works remotely, even answering email on a smartphone while on vacation, can be a liability.
Strong adoption also means focusing on simplicity, finding tools that strengthen teams and cross-functional understanding. Create a supportive environment, which allows us to listen to security concerns. Make security protocols and do audits of security policies that help increase your overall security health. If you have the resources, invite a Marketing, HR, or Communications element into security initiatives and planning to boost awareness.
Developers and security working together
Given the brevity and rapidness of the continuous integration and continuous deployment (CI/CD) lifecycle, Development and Operations teams have evolved into a combined team, DevOps, in many organizations. Together they manage and support the CI/CD systems in an intuitive, powerful symbiosis. When multiple deployments happen minutes apart, saving room for functional tests is hard. If Security is to be part of DevOps, it will have to be security as a process that is supported by Operations and carried out by developers as a part of their shared CI/CD workflow.