5 Ways to Train Security Champions in Cross-Functional DevOps Teams

Whether it’s for the goal of having your software, systems, and services continually deployed so your customers don’t experience downtime. Or you are speeding up development by having your operations working lockstep with developers or whether you’re working towards deploying automation widely across the enterprise. The benefits of DevOps are vast, but the critical element organizations often miss? Security. Here we'll explore 5 ways training can help.

1. RAISE THE BAR ON SECURITY AWARENESS ACROSS THE TEAM
2. BALANCE TRADITIONAL TRAINING WITH HANDS-ON LEARNING METHODS
3. TACKLE ROLE-BASED SECURITY TRAINING
4. LEVERAGE MODULARIZED TRAINING
5. ESTABLISH A SECURITY TRAINING PLAN FOR DEVOPS TEAMS

When it comes to security, that cost is tangible. Fighting back against attackers after intrusion and damage done is enormously expensive.

DevOps was not intended to handle all security issues by itself. DevOps chaos is expounded when security is left as an outside function and not integrated from the onset. Security issues can cause delays in testing, or worse, breaches down the line with leaked customer data or downtime.

The problem isn’t DevOps itself. With security expertise on the team, the team can handle mitigating risk just fine. The biggest issue, then? The skills gap.

In Puppet's annual The State of DevOps Report, Security was identified by survey respondents as a primary concern. Many organizations' challenge is blending security into every step of the software life cycle without slowing the whole process down. The 2020 report argues that DevSecOps is the new approach for unifying people, processes, and technology to automate security. According to the report, among companies with full security integration in the software delivery process, 45 percent can remediate critical vulnerabilities within a day.

Cross-functional DevOps teams—and even non-DevOps teams moving toward continuous delivery of software—need all their members to skill up with both generalized and specific security training. From developers to DevOps engineers to site reliability specialists to database professionals, while each role has shared responsibility for security, how they accomplish it will vary significantly.

The definition of DevSecOps is simple. It is a standard created to implement security into the phases of the DevOps lifecycle.

Deploying code bases continually could introduce vulnerabilities that need to be handled before they are integrated and then deployed into your products, systems, or services.

DevSecOps is the integration of security procedures, processes, and tools into an organizations' DevOps culture. The demand for better security has reached a tipping point. DevSecOps alleviates the impact of failing to provide agile, flexible, and persistent security.

Gone are the days where the security team can hold all the relevant knowledge for an IT organization and personally enact all the security checks on software code or infrastructure hosting applications. There are too many new applications and features being deployed, too much infrastructure spun up and down daily.

Everyone needs to chip in, and the only way they can do that is if companies properly train members of cross-functional teams on what it means to build and deploy secure software.

So let's look at a couple of ways to accomplish secure DevOps – DevSecOps:

The goal for modern security training in the DevOps era should be two-fold. First, organizations should seek to elevate security awareness across all IT functions generally. Second, they should seek to train up an elite cadre of security champions with more profound levels of security knowledge who work in various capacities for the team.

The first objective of awareness isn’t to make everyone deep security experts but instead to raise the overall bar for awareness about security from anyone that touches the continuous delivery/continuous integration (CI/CD) software pipeline. This includes developers but also QA engineers, operations professionals, DBAs, and more.

The second objective recognizes that in a DevOps environment that deputizes technologists of all types to execute on security strategy, there are going to be times where the organization risks watering down deep technical security competence in the trenches. Seeding teams with at least a handful of security champions with deeper levels of security knowledge as it applies to their specialty ensures that things don’t get overlooked.

DevOps depends on increased collaboration between IT roles and self-service. The challenge is as roles start to bleed into one another through deeper collaboration, individuals start to need a wider breadth of knowledge than ever before about how their actions impact the organization’s threat posture. Take developers, for example. So much application security (APPSEC) training today is focused solely on secure coding techniques, without accounting for the reality that developers today are using open-source libraries, spinning up servers, containers, and otherwise self-provisioning the infrastructure their software is running on.

Even when developers take the best secure coding training available, they may be missing a lot of knowledge about the dangers of security misconfiguration when they’re setting up their infrastructure.

There should be a core set of common knowledge that everyone needs to know about security principles: things like regulatory concerns, infrastructure issues, commonly used tools, and so on.

This would give your architects, developers, database administrators, and anyone else in the CI/CD world a common foundation of awareness. In this scenario, ideally, they would all be asking themselves, “Is this the most secure way to do this task?” At the same time, security champions who are more interested in the technical details of these issues should also have the opportunity to extend their learning path beyond the basics to bring greater technical knowledge to bear and act as a security resource for the rest of their team.

Traditional training is still the best starting point for disseminating security knowledge across teams. Continuing professional education (CPE) classes and overviews are all relevant and help build a foundation of introductory awareness. They’re not always the most exciting learning method, but they are incredibly effective when paired with more advanced training.

At the same time, traditional training is more likely to stick with employees when supplemented with additional hands-on reinforcement. Security leaders hoping to build out security knowledge across the DevOps contingent should start exploring gamification and simulation benefits and how they can improve performance on the job.

Software engineers/developers, IT operators, and architects are much more likely to appreciate the nuances of security risks when their “book” knowledge is paired with hands-on training in simulated environments or some kind of area where they can appreciate what they’re defending against. Rather than just academically saying, “Here’s what SQL injection is, here’s how to defensively code against it,” it’s better to allow security champions to exploit those issues, so they understand them from all angles. This “learn by doing” approach is proven in its efficacy to transform knowledge into permanent skills.

Even with a sophisticated blended learning experience, generic security training should only be the foundation for developing security champions within DevOps teams. A security champion program depends on training that’s tailored to specific roles. Not only that, this training needs to be designed for the new reality of collaborative DevOps roles, rather than the limited and siloed IT functions of years past

Organizations can take a team’s security knowledge to the next level with tailored, prescriptive training based on specific roles and skills. Once individuals have the primary education and some hands-on experience, it pays to take the information about how they performed in these training and direct them to focus next based on their job duties. So developers would get one suggested learning path, QAs another, infrastructure specialists a different one, and so on. By doing that, it’ll give every security champion a much deeper level of training applicable to his or her daily workflows.

The training needs to offer people the path not necessarily to turn into security staff but to learn how security applies to their specific role at an elite level. Suppose teams can pepper even just a percentage of these elite security champions across each common role. In that case, these highly trained individuals can help their peers level up their skills organically as they work together on a daily basis.

Many of the security principles taught to different roles will overlap, so there’s no reason to reinvent the wheel with a brand new curriculum for every unique role. One way to do this is to develop a modularized training approach.

Modularized training breaks down certain principles into individual components of a curriculum library. An organization can then mix and match these components for each person’s appropriate path—based on their role and the depth of knowledge they need. Not only does this make it more elegant to shift to role-based security training, but it also adheres to the latest research in education that favors shorter, more consumable modules. Additionally, it offers a greater degree of curriculum flexibility and customization without reinventing learning content for every role-based training path.

Gartner analysts predict that DevSecOps practices will become embedded into 80% of rapid development teams by 2021. In this day and age, where every company is a software company, IT leaders need to develop a security training roadmap to help their teams keep up with cybersecurity best practices to ensure that applications don’t add unnecessary risk to the business.

Without clear, prescriptive learning paths based on roles, organizations risk wasting their training dollars on generic knowledge. Companies simply require several hours for professional development in security without offering any guidance or prescriptions of the course matter. As a result, employees often choose the easiest path to racking up those hours without gaining any appreciable skills or knowledge along the way.

Because there are so many moving pieces to building out training that grooms security champions across so many IT functions, security and IT leaders need to lay out a detailed plan for how they will develop security skills relevant to every function of a DevOps team. While each role needs to understand the fundamentals of secure DevOps, privacy protection, the OWASP Top Ten, and other core topics, additional job-specific training is required to do their specific tasks.

Ensure that we map each building block of our pipeline step with some security implementation. Various methods and best practices ensure security and testing are integrated into a DevSecOps environment without compromising speed, security, or quality. There are other advantages to this new approach, including:

• Greater Speed and Agility: whenever there is an identified vulnerability or a new vulnerability, a security team can go and can plug in the required patch, which can take care of the security vulnerability
• Provides better collaboration and communication: By moving to DevSecOps and building Security Champions on your DevOps teams, you’re not able to only further the skills of your teams but also progress towards a common nomenclature by moving security into the fold of the development process.
• More opportunities for automated builds and tests: Yvonne Wassenaar, CEO of Puppet, a provider of pervasive automation solutions, believes it is the responsibility of technology to eliminate soul-crushing repetitive work. Breaks in security are largely a human problem and an outcome of the toil of monotonous work. By automating human breakpoints in security, tech professionals can find more meaningful and rewarding work resulting in more robust security
• Early identification of code vulnerabilities: Whenever you're able to discover or identify vulnerabilities early, you'll be able to act on them early. So security threats will not get passed onto other phases
• Assets are freed up for high-value work: With an eye towards decreasing disruption and mitigating risk, team members will become less reactive to fixing mistakes and more proactive in moving products and services forward.

Bad actors have more surface area to work than ever before. Invaders just have to exploit one vulnerability, while DevSecOps need to defend all of them. It isn’t a fair fight. DevSecOps levels the playing field.