background

Agile Security as a powerful selling point of your product!

Jun 2020

Audience

Agile software teams, Product Owners, Security Officers, Marketeers

Companies are very aware of the headaches of insecure applications. Meanwhile, customers are rightly more critical about security. This offers excellent opportunities for software companies to distinguish themselves when it comes to security!

How can you use Agile Security as a proud selling point of your product and company? How can you create a fresh sound between empty terms like "military-grade encryption" and "GDPR-proof"?

Reading time 7 minutes

No time now, but very curious?


Read the summary

From side-business to pen testing

When I started in the world of cybersecurity more than 15 years ago, buyers weren't really (or rather, really not!) critical of security.

Not many questions were asked about it, so why should you as a supplier? Fortunately, times have changed. Customers are more critical than ever and pen tests are well established.

Do you build or use online portals with privacy-sensitive data? In that case, a whitebox pen test is the minimum you can expect as a thorough snapshot of the security quality.

Recommendation: The NCSC (National Cyber ​​Security Center) recently published the Securitytesting Whitepaper to support companies with this process. This white paper has been developed in close collaboration with various (security) companies, including Securify.

Snapshots afterwards

The classic periodic pen test has been the norm for years. But if you develop Agile, with multiple releases per month/week/day, this traditional waterfall approach doesn't work well.

Within Agile development, there's a need for a faster test and feedback loop. This to make sure security problems are found early in the development process. So security reviews are ideally done continuously as part of the sprints.

Conscious buyers also understand their portals are almost permanently under construction with a continuous barrage of beautiful new features released in rapid succession. That's cool, but it also creates a different risk landscape. One where a periodic security snapshot may no longer be sufficient, but a continuous "security video recording" is needed to match the process better.

Not only because of the enormous security gain but also to increase efficiency and speed. Last-minute surprises are not only punishing for security but also your speed and manoeuvrability.

Responsibility

Fortunately, we notice that more and more application developers are putting security higher on the priority list than not so long ago. We gradually encounter fewer instances of the oh-lets-do-a-last-minute-pentest-now mindset.

More and more organisations are eager to get to the bottom of the security quality of their applications and keep that quality high. We notice an increase in people who want to go beyond the classic after-the-fact checkmark at their request.

And not only because of stricter requirements and more critical customers, but simply out of their sense of responsibility. Security is increasingly seen as an essential quality aspect. Rightly so!

Mass-producing features

But... unfortunately, we aren't there yet. We still find many teams that are dealing with the following:

  • Building under high pressure with full focus on new features! Technical and security dept dangles far below in the backlog if it's there at all.
  • Developers have their hands full just trying to keep up (new frameworks, techniques, building blocks etc. etc.) and to support less experienced colleagues.
  • Too little in-depth knowledge in the field of security and too little time is made available to dive into it properly.
  • No one available who can quickly and substantively answer appsec questions and assist the team.
  • The critical security feedback loop and knowledge transfer are missing to recognise and prevent problems early.
  • Problems that are only discovered late or, even worse, completely missed.
  • Teams are busy delivering and - at the same time - there are all kinds of unanswered security questions. Something that's paralysing and inefficient.

Agile Security

An Agile Security approach offers a solution. By making security part of your development flow, your product becomes safe at the core, you avoid surprises afterwards and you immediately have a convincing story to your customers!

That sounds nice, but how do you do approach this in practice? My most important lesson: if you don't tackle security in a practical and non-blocking way, it won't get done. Promise.

Using a risk-based approach is key. Focus on the things that really matter and are useful. I am extremely allergic to the testing-for-the-sake-of-testing. mindset or mandatory pen-test hoops.

That takes a load of unnecessary amount of time, breaks the Agile flow, has a frustrating effect and does NOT necessarily result in safer products.

The security sweet spot!

The search for a practical approach to security within Agile projects has been my focus for years. Something that started a long time ago during my time at Dutch bank Rabobank when there was a massive landslide from waterfall to Agile.

The biggest challenge has always been to find the security sweet spot. Where is the perfect balance between quality, speed, scalability and costs?

And then also - how do you develop an approach/platform that makes security experts, development teams, security officers and the business happy?

Agile security on a napkin

I am convinced that if you want to deliver safe products at agile speed, you should look for the following:

  • Work risk-based. Focus only on the things that are needed/useful.
  • Fast and early security feedback during development.
  • Prevent, identify and fix security vulnerabilities the minute they're introduced.
  • Find an ideal balance between manual and automated checks.
  • Smooth, easy accessibility of technical security expertise (secure coding).
  • Keeping security top-of-mind by dosing the amount of relevant security awareness.
  • Security must be visible, verifiable and measurable!

Risk-based approach

What does this look like in practice?

With a baseline assessment, we determine the security score (including OWASP ASVS) of your product, we map the security hotspots and we create the scope/threat model.

For example, we uncover all vulnerabilities and points of attention, record what the high-risk areas are and assess which attacks apply to the product.

All this is recorded in the security dashboard and creates the blueprint for the risk-based security validation, support and awareness.

Next, the Agile phase follows. Via the right integrations (such as Git, Jira, Slack etc.) all new changes are verified in a highly optimised workflow and the team gets full time remote supported by a team of experienced appsec specialists. All in a very practical way.

Test less, secure more!

Direct testing is done with efficient diff-reviews with a full focus on the security-relevant changes. Support for technology is crucial here.

Super-efficient and targeted reviews, continuity, collaboration and the frictionless submission and exchange of findings and feedback have proved to be a key success factor.

So, are there any errors or concerns? Immediately identify and submit them to the security backlog so product owners and the team can get started.

Knowledge is actively transferred on the job to make the team increasingly aware of security and to reduce the chance of new errors. All in a positive and focused way. No major training is needed and everything is communicated in relevant and applicable security snacks.

Automated security checks are set up gradually and the defensiveness of the product is strengthened. This reduces the security hotspots and with it the (manual) validation effort, saving time and money.

This way, a snowball effect is created. You prevent new issues, ensure increasingly robust code, a security-conscious team, effective automation, fewer security hotspots and therefore a decrease in manual work. Test less, secure more.

Insight

A wise lesson I learned over the years - if security is not visible, it will not happen. Visibility must be high and transparent at all times to always be able to serve internal and external stakeholders smoothly.

For example, product owners are continually working on getting their priorities right. How risky is a security issue really, what's the business impact? Urgent? Or can it just wait for 2, 3 sprints? Support and timely information are essential to the balance between speed and good security practices.

Risk acceptance is part of the game! But make sure that exceptions are transparent for all stakeholders. Who accepted what for what reason? Stop doing this informally next to the office coffee machine. Capture every decision.

A development manager or CISO also benefits from this. A single, central security overview of all critical projects. Which risks and types of errors occur where? Do they need to focus their attention to a specific area and what does/doesn't go well? Essential input to shape your security programs.

A central place where all stakeholders can view current information about the security status, (business) risks and the security progress is essential to focus on resources and activities. An impression of our interpretation of this:

Dashboard

Tell your audience!

And now the juicy part! With this Agile approach, the security quality of your product is visible and demonstrably guaranteed, and security remains continuously top-of-mind. And you can proudly let your audience know it!

Nowadays, the average marketing about security is quite... basic. We use the same security techniques as 'the banks', our security is military-grade, GDPR-proof and is extremely important!

Provide a fresh sound and distinguish yourself from this empty marketing speak by showing with pride and confidence...

  • that security is ingrained within the Agile development process.
  • that all changes are immediately checked by (independent) experts.
  • that there's full-time support and awareness is continuously receiving attention.
  • that there's continuous reporting on security quality.
  • that security is transparent and evident at all times.

By doing this, you stand head and shoulders above the rest and you have a resoundingly ready answer to the critical questions that will arise sooner or later.

Summary

Security is essential, customers are more critical. This offers excellent opportunities to distinguish yourself security-wise and to anticipate critical questions!

The classic after-the-fact pen test is no longer sufficient for Agile projects with multiple releases per month/week/day! Customers also know that their portals are always under construction. Great, but it also changes the security game a lot.

Tackling security in an agile manner has many advantages in terms of security and speed. But be sure to keep it practical, fast and scalable for all stakeholders.

And that's easier than you may think! With a combination of quick and flexible access to security expertise, a direct security feedback loop and smart use of technology. Something that benefits developers, product owners (determining priorities) and CISOs (insight into security).

This way, security receives the attention it requires to continue to innovate quickly and demonstrably safely. And that makes your customers happy!

Do you also want...

  • to start with Agile Security?
  • to innovate safely at speed?
  • for a fixed price per month?

Then meet Securify Inline.


Get in touch

When you..

  • wonder if we’re a right fit..
  • are interested in a demo..
  • would like a quote..

David Vaartjes

Tel: 06-22746291
david.vaartjes@securify.nl
Connect on LinkedIn

I have a strong background in application security. Before launching Securify I worked as a software security specialist within the internet banking teams of a large Dutch bank. It is my passion to help Agile teams to ship quality secure products efficiently, without compromising on innovation, power and speed.

Call me for anything you want to know about Securify Inline!