How Teams Can Overcome the Security Challenges of Agile Web App Development

Business dynamics have always challenged companies to find ways to stay ahead of their competition. There's no doubt that agile delivery models are the best choice for companies seeking to deliver rapid value to their customers. 

However, as someone whose background is in cybersecurity, I must say that continuous delivery models pose serious security challenges. That’s not to say that security and ongoing rollouts are by any means mutually exclusive. When I offer my cybersecurity services to software shops, I’m always the first to admit that security must adapt to business needs rather than vice versa. 

In-house CISOs these days find themselves under pressure to secure project deliverables throughout the SDLC. It's no wonder that many of the security professionals I interact with talk about "agile" security systems as a means of coping with the pressure, and in almost every situation, the first challenge they say they have to overcome is grounded in team culture.

Changing Cultural Values 

Cybersecurity protocols are rooted deep within a company's culture. A study conducted by McKinsey & Company early this year found that cybersecurity operating models at most companies don't operate at "cloud speed." As digital delivery models have evolved to emphasize experimentation and innovation, cybersecurity has been left behind in the dark ages of siloed communication.

The typical project lifecycle has security inputs at previously agreed-upon points in the delivery process. The interaction that takes place between security professionals and developers is heavy-handed as teams attempt to conduct security audits on code that could change as quickly as the following week.

When code does get merged, the previous security audit is rendered invalid, and this leads to another round of deciding an appropriate time for a security review. The security team grumbles about developers shifting goalposts while dev teams complain about security getting in the way of delivery deadlines. 

Does any of this sound familiar?

Change begins from the top, and CEOs need to communicate the importance of cybersecurity as a foundation of a successful digital transformation. That same McKinsey study revealed that cybersecurity is buyers’ top priority when purchasing IoT products, and I’m sure that’s the case in other verticals as well. Security protocols aren't just a regulatory hurdle. They're a means of enhancing customer value.

CIOs and CISOs need to work closely together to implement new security paradigms that support faster product releases to market. The old-fashioned gatekeeper role that CISOs play is obsolete. The CISO needs to advance new conversations with management about how security can generate market advantages for their company.

What’s more, security teams and developers need better education about each other's priorities. Both parties must view themselves as being part of the same team that delivers customer value. Security compliant development is just as important as continuous releases. Security usually occupies a low priority in a developer's mind, and this needs to change.

Transforming the Roles of the CIO and CISO

CIOs also need to review the traditionally gated approval process in project lifecycles. Typically, code pushed for approval by dev teams is reviewed by a deployment team. This process ensures segregation but creates an "us versus them" environment between both teams. Unsurprisingly, security teams are a part of the deployment approval team. 

Instead of segregating duties in this manner, automating the approval process can facilitate faster cultural change. Developers can release code into a fully automated delivery pipeline that has been created by QA and security teams. The code can be tested for acceptance, security and pre-deployment. Implementing this process requires every functional department throughout the SDLC to use automation tools. 

CIOs need to work closely with the functional team leads (including the CISO) to conduct tool and DevOps reviews, which can often run into governance process friction.

Managing company secrets in an agile environment means CISOs need to rethink the scalability of their current security solutions. With rapidly changing codebases, it’s essential that enterprises use security tools that support agile development and also extend to other platforms that devops teams might use. Akeyless is a versatile security tool that fragments encryption keys and provides a high degree of data security. It supports agile release environments and can be scaled to different platforms as needed. 

One of the reasons I like implementing this solution when consulting for app companies is how easily I can integrate it with all the major development platforms through plugins, ensuring that in-house departments and subcontractors alike can securely manage access to sandbox servers and databases, without interrupting their workflows.

Beyond governance concerns, in my experience, compliance and audit teams generally stand to gain a great deal by learning about how automation can help them achieve their goals, along with how their protocols can improve with automation. 

On the other hand, complete automation might not be possible in every area. Team leads need to work collaboratively and agree beforehand on processes that will require manual approval. CISOs need to emphasize that the integrity of their security testing tools is directly related to the integrity of the finished product. Doing this creates a culture that emphasizes the importance of agile security to both security and dev teams.

What’s more, the use of an automated process enhances collaboration, and this is the message that the CIOs and CISOs need to communicate. A point that needs special discussion and possible cultural reorientation is the trade-offs between rapid deployment and security needs. Rapid deployment, sometimes as much as multiple times in a day, allows companies to test products with users and gain fast feedback.

However, rapid deployment can only work by reducing the batch size of both the code as well as the security tests that accompany it. CISOs need to define timelines and priorities for risks and communicate this to dev and deployment teams. For example, only high-risk vulnerabilities can be tested in each rapid release, relegating full security audits to a weekly cycle. 

Such an approach increases the chances of a bug making its way into production and this might go squarely against existing security culture. To mitigate this risk, agreeing upon rollback procedures and creating new procedures for benchmarking stable code is essential, but implementing an agile security solution requires company leaders to think differently. 

The definition of security and its function needs to evolve. This cultural change needs to be backed up with resilient processes.

Installing Agile Security Processes

CISOs need to reinvent themselves to ensure security is maintained in a rapid release environment. There are a few best practices they can adopt to overcome some of the challenges I’ve  outlined above.

Enforce Continuous Participation

Instead of earmarking certain points in the delivery process where security teams get involved, CISOs need to design processes that empower developers to deliver great products and allow security teams to monitor organizational risk. Installing a delivery support team within the security department is a way of doing this.

Security can be embedded in development by creating pre-approved coding standards, design patterns, and design decisions. These standards will allow development teams to move forward without requiring security input at every step. Incorporating cybersecurity team members into initial design teams is a great way of building security DNA into the project right from the beginning and will help avoid costly modifications down the road.

Revamp Training Procedures

CIOs and CISOs need to design employee training programs that move beyond the typical security “awareness” goal and instead emphasize behavioral change. It isn't just dev teams who need training. Security teams require education in agile delivery models as well. They need to understand the difference between acceptable risk and high-risk vulnerabilities to support continuous release models.

I’m sure there are plenty of exceptions, but from what I’ve observed, the average cybersecurity employee does not have development experience, and the average developer has no security background. Creating collaborative teams during training exercises will help foster dialogue between them and will break down silos. Some of my clients are emphasizing greater collaboration by hiring security personnel from development areas.

Consider creating a security champion program that puts developers and security members in touch with one another. Developers will gain a stake in security protocols throughout the process. Ensure your security messaging is consistent throughout your organization.

Smarter Deployment of Automation

Install automation at strategic points throughout the SDLC. They're an easy way to enforce security protocols throughout your organization. However, automating processes brings its challenges. Begin by identifying the areas that will bring you the best ROI and reduced risk through automation. 

Automate a few small tasks and increase the degree of automation incrementally, in stages. This way, dev and ops teams will have the chance to adjust to the new process gradually and won't have to deal with an avalanche of changes in an already high-pressure environment. 

Automated vulnerability scanning tools such as StackHawk and WhiteHat Sentinel need testing before implementation. According to Infocyte, false positives account for roughly 40% of the alerts that security teams receive. Track the rate of false positives the tool produces and the amount of additional work it creates for ops and dev teams over time.

Preparing a sandbox for developers to test their solutions from a security perspective will allow them to incorporate security into their code at every step. Security teams can monitor these tools and configure them for increased usage. If teams are already using automated tools to deploy code, integrate security tests directly into it, instead of forcing teams to use a new tool. This will increase the efficiency of their output and will drive the collaboration point home. Constantly testing automated security tools is critical to achieving dev team buy-in. A tool that generates a high number of false positives needs immediate intervention. 

Technology is improving at a rapid rate, and this means security needs to keep pace with it. In addition to accounting for the speed of delivery, CIOs and CISOs need to account for increased infrastructure. Cloud hosts, containers, and virtual machines are increasingly becoming staples at workplaces and bring their own security challenges.

CISOs need to embrace new technology instead of viewing them as another hurdle to overcome. Automation holds the key. Integrating existing automated tools into new infrastructure or improving them through the use of new technology will help the security team remain robust.

At the very least, security teams need to make sure their considerations are accounted for in every deployment. While collaboration is great, security teams must have the final sign-off on deployment. Applications can be robust and secure through this process. 

Develop Security Telemetry

The volume of data that organizations generate these days can provide security teams with unique insight into threats. Using proper feedback tools and developing appropriate telemetry that allows security teams to standardize reports is critical.

The first step to take is to develop templates of code that developers can use to generate the telemetry desired by the security team. Telemetry is effective only if it helps the dev team meet its goals. 

CISOs need to examine the way security data is communicated to dev teams. For example, a visual report of the result of a security check on code will help developers quickly identify shortcomings. It also minimizes the need for manual security checks. You might also do well to set up a dashboard with visual analytics that display the number of security flags per development sprint, so that both security teams and product teams can easily visualize their collective success over time.

Contrast these tactical ideas and cultural dynamics with a black box that requires dev teams to get in touch with security teams to receive results, and you can easily see the advantage of transparent telemetry.

Rethink Hiring Standards

As some of my clients have done, rethink the way you hire members to your security and dev teams. Consider promoting one of your dev team leads to a security position. Such changes increase collaboration, and your security teams will gain a unique insight into the development needs. 

For their part, dev teams are less likely to adopt an adversarial attitude towards security teams if they know one of their own is a key member of the security team.

Development team members might not have adequate security training, and this is where interactive and collaborative training modules play an important role, as I explained previously.

Preparing for the Future

Implementing such changes takes time and requires shifts in organizational leadership. It can seem daunting to make these changes. Change begins by asking five key questions that will help CISOs assess the organization's ability to revamp legacy structures and to install agile security standards.

1. Does your team possess the skills to support a collaborative culture? 

Many teams are dead set in their ways, and silos can be hard to break down. While some teams might possess the skills, the organization's culture might prevent them from collaborating more with one another. If culture is the culprit, change needs to come from the CEO down through the CIO. Consider enhanced training programs and better hiring if culture isn't the problem.

2. Are collaborative efforts geared towards the organization's goals?

Collaboration just for its own sake isn't of any use. CISOs need to review whether the processes they're installing serve the organization's goals and create a better product. For example, a slightly longer release cycle that incorporates more security testing might result in a schedule that consumers aren't happy with. Security protocols need to be reevaluated to account for this.

3. How well does your organization understand Agile?

Many organizations believe they're Agile, but they're not. CIOs need to review their practices and assess their understanding of the SDLC as it relates to market needs.

4. How aligned are the CEO, CIO and CISO?

Collaboration is impossible unless these three roles are on the same page with regards to security goals and enforcing standards. Develop standard KPIs that provide a standardized view of your organization's security picture.

5. Is security supporting innovation?

As consumers become more conscious of data security, organizations need to ensure they're evolving the security features of their products along with the market fit. Conducting regular reviews of the security outlook of their products and industry is essential. 

How Agile Can You Be?

Agile deployment is here to stay, and security teams have to reorient themselves to this environment. The days of predefined security involvement are over, and collaboration is the future. Change needs to occur right from the top, and the role of the CISO has to evolve from being a mere gatekeeper to one that promotes product innovation.

About the Author

Asim Rahal is a Michigan-based cybersecurity consultant with a passion for supporting organizations through their digital transformation. He is obsessed with cloud security, data protection and cyber risk awareness. After two years with Cognizant as an IT consultant, Asim went independent and set up his own business offering IT and cybersecurity services to companies of all sizes and sectors.