Pushing security left with Zerocopter

Company: Aegon

Client in lead: Jeroen Prinse

Client's role: Security Officer

Pushing security left with Zerocopter

At Aegon, one of the world’s leading providers of life insurance, pensions, and asset management, securing information is motivated by more than one reason. Yearly figures, ISO-norms, regulators such as De Nederlandsche Bank and legislation like the GDPR push Aegon to develop and maintain secure applications and solutions to best support their most pressing need for security: the customer. By redefining the role of security in the SDLC, Aegon has successfully tested methods of making security a more integral part of the development stage, instead of close to production at the end.

During our event Hack Your Boardroom, Jeroen Prinse, security officer (SO) at Aegon, held a talk and explained how his employer has broken with the traditional approach of software- and application development. By pushing security to the left in the process of development and starting a bug bounty program with Zerocopter, vulnerabilities were found that were not discovered by traditional pentests.

Jeroen Prinse - Security Officer at Aegon

Jeroen Prinse
Security Officer at Aegon

Jeroen Prinse - Putting security first

Putting security first

The problem at Aegon, Jeroen explained, was a lack of timing. Security always came in last. “When you keep security at the end of the process, security teams become the embodiment of the word ‘no’ in inNOvation.” Jeroen said to a crowd of CISO’s and other security-minded attendees who came together to talk and learn about new ways of securing digital environments with a scalable method.

Heads go up and down and some smiles breakthrough, affirming Jeroen’s statement about the image of the nay-saying security department. His next question –“Who is still stuck in the timeline of the traditional approach?”– brings out even more signs of recognition among the listeners. Like Aegon, many companies and departments face security-challenges that are not easily solved with traditional resources.

A timeline of the traditional approach

Apply

In March, developers come together and state: “We have a great idea that will change the world. Let’s code it!”

Apply

One month of hard work goes by, and in April, that same team happily shares with the rest: “We’re done coding and ready to change the world tomorrow.”

Apply

The S-question pops up: what about security? Now, the security officer and his people have to examine what is put in front of them carefully.

Apply

After working tirelessly, the team gives security-verdict around July: “We have looked at the code. We’re not saying it’s ugly, but you can’t release. Your project has several security improvements.”

Apply

Insert a few more months of iterations and changes and finally: LIVE! Effectively, the world-changing, promising features developers initially promised to deliver works great and are secure, but the developers are looking at the security-team rather funny…

Criminals see your application as a castle, with multiple ways to break a window and enter. Hell, they might even set up an elaborate plan to build a wooden horse!

Pentests provide a limited sense of security

Through the traditional approach, integrating security in development-processes has become more and more a showstopper –or at least a significant cause of delay– than anyone would want. Instead, security becomes a burden to the business and only adds little to no value, if added at all and is limited by the lack of resources an IT-department has.

“The problem with DevOps without the security is that the cost and time of finding and remediating security issues multiply several times over at each step in the delivery chain, all the way to production,” Jeroen explained. “This increases technical debt, otherwise known as insecure applications, piling up issues in the process and as a result killing velocity and innovation.”

The answer for Aegon was to reposition security earlier in the development stage, instead of close to release. Of course, much thought has gone in the problem of the place of the timing of security. One widely-spread method to reposition security in DevOps is by performing penetration testing. As SO, Jeroen is not convinced of the advantages pentests claims to hold. The limiting factors far outweigh the benefits.

Jeroen clarifies those shortcomings with an example. “Let’s say your digital environment is a castle. With a pentest, a small wall on the north side of the main entrance is checked on strength, damages it has, and possible future risk of collapse. However, your enemy is not even thinking about that small section of your castle-wall. They focus on six or seven other weaknesses, maybe even the structure as a whole. Hell, they might even set up an elaborate plan to build a wooden horse!” Criminals see your application as a castle, with multiple ways to break a window and enter. A single, strongly-defined check of only one of the risks, provides only a sense of security instead of the security companies need.

8 problems with the traditional pentest

Apply

Limited budget

A pentest starts with a hypothesis and is answered in the end. Changing the focus of the research mid-way is not possible most of the time, because this will result in a parallel pentest. Budget and time do not allow that.

Apply

Limited scope

A pentest is strongly-defined research based around one question or one subject of testing. This prevents a lack of focus and result, but the consequence is that only a small part of security-challenges is taken into account. Therefore, a pentest is best compared to a snapshot.

Apply

Limited time

Pentests are timeboxed with a limited scope, criminals have all the time in the world to look at your digital environment.

Apply

Limited expertise

Typically, one or two people perform a pentest. As experienced as they are, two people have a limited amount of knowledge and expertise as opposed to a whole team of security experts.

Apply

Limited learning by DevOps

Most of the time, DevOps are not involved in the result a pentest brings forth. This limits the possibility of learning precisely in the area where it is needed.

Apply

Limited flexibility

Pentests do not allow the scope to be changed, since the time frame is set and the budget is fixed. You can't add testers with specific knowledge mid assessment.

Apply

Limited possibilities to scale

Calling one of the big four every two weeks to pentest a new release is not sustainable.

Apply

Slow feedback loop

Pentesting takes up much time, slowed down even more by waiting on a report. Also, when that report is finally written, your DevOps-team is already in the next sprint.

Criminals attack your castle without the limits traditional pentests for companies have. They move faster than any pentest can any day of the week. New methods of security-testing have to be explored and tested. For this reason, Aegon decided a short time ago to invest in a more flexible, scalable, and cost-efficient method of securing their customers’ data. By investing in a bug bounty program from Zerocopter, Aegon wants to enable their development teams in new ways as well as contribute to their velocity with fast feedback loops. The goal is to grow a renewed security culture and stimulate everybody involved in application development to work with security in mind. Preventing the growth of security (i.e., technical) debt follows suit.

Aegon sourced information about DIY (do it yourself) bug bounty programs but quickly concluded that the lack of triage would result in a multitude of false positives and minor issues, as well as low-quality findings and reports. Integrate a self-made bug bounty program, required processes to be thought out and implemented, which requires investing in more people with relevant knowledge and experience. Above all, a DIY bug bounty program makes it hard to put a cap on the budget. Jeroen: “We expect that it is tough to define the height of a certain type of bounty in talks with security researchers without an independent third party involved. Who keeps it all in check?”

Also, a DIY bug Bounty program requires convincing the board, legal, compliance, and procurement all stating something along the lines of: ‘Working with hackers? Are you nuts?”They’re right. How do you screen hackers that work for you? How do you start without a Non-Disclosure Agreement, a Data Processor Agreement, and a Liability Agreement? How do you keep a hold of findings without ‘official’ reports? Preventing disgruntled hackers from harming is a challenge as well, and the chances that the board is not to keen on transferring money to possible criminals might be an obstacle your team never clears.

Aegon Vulnerability Testing

The results of the proof of concept made us decide to look for ways to integrate programs by Zerocopter permanently in our development process.

Not the expected start

That is why Aegon decided to bring in continuous security testing capability with Zerocopter. Jeroen: “We chose to work with Zerocopter to take away the need for investing in more fte, bringing in knowledge or redefining processes we already use. The screening of hackers and Triage over findings Zerocopter provides ensures us with findings presented in high-quality and well-written reports. The payment of bounties happens through their platform, and bugs have a predefined price, so there’s no haggling about rewards after the work is done. Because multiple services such as scanners are included in the services Zerocopter offers, we do not have to look at other parties saving us costs and time.

Put lightly; the start did not go as expected. Jeroen laughed as he recounts that some overlooked walls were discovered quickly. “I had to endure a tough conference call with some cross Americans who tried to convince me to end the program. We explained that this is exactly the reason why we started the program and that a change was needed to improve the infra to prevent it from happening immediately. These findings exemplified what normal, traditional testing can miss."

Within two hours, 25% of the budget Aegon reserved was gone. “One researcher found two bugs and made 2500 euros before calling it quits and probably opened Netflix straight after that,” Jeroen said. After ten days, the interest of the 35 initial security researchers had ceased to exist. “In total,” summarizes Jeroen, “vulnerabilities that the Zerocopter researchers found were not discovered by traditional pentests. It had never been part of the scope of our periodic pentests. That result made us decide to look for ways to integrate programs by Zerocopter permanently in our development process.”

“Interestingly, the talks I’ve had with the people of legal and the board no longer address the former concerns they had, but rather involved contract details, for example. That shows me that the prior hesitation of working with Zerocopter and hackers is gone. I am pleased to be part of that change, and I do not doubt Aegon will profit from the experience so far shortly as we remain a partner.”

Read more about integrating security in your development process

Download our brochure
Want to know everything about Zerocopter?