Climbing digital Peaks – Approaches to sustainable Application Security

The digital transformation is stressing the IT domain more than ever. How can we ensure a good level of security under such pressure? As so often, there is no hidden miracle and we need to climb the peak step by step.

The entire IT world is undergoing a transformation towards more digitalization, more dynamic IT infrastructure and more service-oriented architectures. With terms like DevOps, Agile and such, it is especially the Software Development domain that gets much more into a focus than what we were used to. That’s actually nothing new if you have been following the domain over the last couple of months (or even years).

However, this also changes our mode of collaboration inside companies, between companies and of course between customers and vendors. Software Development has become a team sport more than ever. And increasingly teams grow towards more diverse groups, squads or tribes composed by people taking different roles.

Being a Security person, I am particularly wondering about what “the Security” can do. What can I do to facilitate the change towards a shiny digitalized and – most importantly – secure world.

“Security? Bah…”

From experience, I know that Security people are not the people that are welcomed to projects with open arms. Of course, this has several reasons. The most important one may be, that the job of a Security collaborator is all about risks and requirements, which help to avoid risks. Admittedly, I know this is not the most constructive mindset ever. However, on the other hand, there is a s#!t-load of stuff that can go wrong with regards to the growing number of cyber threats. But also, regulatory or even legal aspects that companies need to comply with play an important role. In the end, both parties, the project teams and Security people, want the best for the company: sell products on the market and avoid getting hacked (and consequently keeping customers’ trust).

In the digitalized future, things will change

Since we have the possibility to be much more dynamic, new products will be brought into the market much quicker. So quickly, that there won’t be time for the classical infamous security review two weeks before release date. Eventually, products will take those two weeks of time or less to be created from their idea and conception to the point before hitting the market.

So, what we can be sure of, is that the difference between Dev-teams and Security people will fade. There’s not the one Security person to be blamed when something goes wrong. Rather, security needs to be built in from the very beginning at every step of the Development Lifecycle. There’s a collective responsibility to create secure products.

But how does that affect the security department? What will “they” do, if not securing products and reviewing them for security?

Same challenges…

Well, of course regulations and laws will not disappear. This means that the usual requirements will always be present. And, let’s be honest, there IS a good reason, why we need to handle personal identifiable data and sensitive customer data in different ways than the current marketing campaign.

So, will Security people just continue like always?

Certainly not – basically, the same level of security is requested in a fraction of the time. By this, I mean that customers expect their data to be secure – even for a Minimum Viable Product.

…new approaches

How can we address this major game-changer in a thorough and sustainable manner? There is quite a lot that can be done – but two points predominate:

First – Ensure development teams make the right decisions when it comes to security. This includes that required knowledge to make security decisions is present, where it is required. Which is in the heads of the development team members. So, Security team members will need to share their knowledge in a well-structured and sustainable way with everyone who needs it.

…and second – Make it easy to create secure products. It’s easiest to create new things if we can stick together already existing blocks. Security team members need to provide easy-to-understand and easy-to-use components that make it simple to create products, which are innovative and secure at the same time. Components may come in the form of an API, a best practice knowledge base article, entire code libraries, self-service scanning tools and so on. Plus: all of them need to be easily retrievable – a good solution doesn’t help anyone if it cannot be found.

These two points represent a huge challenge, since they represent a big change in how typical Security departments currently collaborate with development teams. In my opinion, it is also not feasible to tackle this challenge as a security department alone. Particularly to offer ready-to-use solutions, the help of the actual target audience is required.

Share, contribute and absorb

We won’t get to where we want to go without sharing experiences, code and services. Here, we can borrow from the global “techie-sharing” movement, better known as the free and open source software community.

What works in the open source domain can also work in the so called “inner source” domain. Many problems that appear on a daily basis have already been solved at least once before. If we manage to share our own solutions using a well-established channel, we enable a certain level of modularity allowing to come up with further solutions even quicker.

Ready for the future

At Swisscom Security, we’ve done a step towards the future by setting up a gamified Application Security certification programme, called AppSec Peaks. Its purpose is mainly to:

  • raise awareness on already existing solutions allowing to improve a product’s security
  • encourage to share own solutions
  • elaborate on suitable security activities during each of the phases in waterfall and agile development lifecycles (according to good practice SDLCs)
  • provide an understanding of common vulnerability classes
  • allow people to actually hack by going through a hands-on AppSec boot camp

Looking at the feedback we get from inside and outside the company, it seems like this was a step in the right direction. However, many more steps will be required to continue the journey towards our vision of Security being the fundamental enabler that teams ask for and that we want to be.

So, let me summarize the major insights that I realized, while helping to bring our AppSec programme up to speed:

Security/Agility is not your enemy: this one goes both ways. Communication is the key since collaboration will be much tighter in the future – let’s talk to each other;
Share experiences, code and good practices: you are not the only one with this problem;
Be open for new things: keep your mind open for new solution approaches.