Application Security: Under the Hood

Let’s talk about application security

Realistically, you cannot personally check each application’s security posture and maintain up-to-date knowledge of all potential threats. You need to trust that app providers know how to build security and data protection into their apps. As application security experts, the best way for us to build that trust is to explain our processes.

This article will share some important details about the work and challenges of developing and maintaining application security. You’ll come to understand how complex this operation is, and how much time and effort we invest in app security before any new functionality reaches users.

Let’s look at the three stages of secure app development and maintenance.

Stage 1: Preparations

Even before the first line of code is written, a lot of work has already been done, often with active security team involvement.

When should an app security team get involved?

First, new features and major changes demand an architectural redesign that needs to be reviewed.

Not every modification has a security impact, of course. For example, new icon design or additional language support won’t require much extra time from the security team. However, many areas do need close inspection by security experts, and this raises two hard questions. How can we track all the new features and changes?

From the technical perspective, keeping track of new features and changes is not a difficult task as long as there is at least some form of ongoing documentation. The problem is the sheer amount of changes happening constantly to most apps, which makes manual security team assessment of each item a very inefficient approach.

Communication and assessment

That is why close cooperation and communication between development and security teams is invaluable. Multiple channels should be created between teams to raise awareness of app changes and potential security issues. Maintaining a dedicated application security channel helps to facilitate valuable discussions.

Constant consultations at any stage of the software development life cycle (SDLC) are very important to the process. At Nord Security, our application security team actively promotes these consultations by all means possible, as this helps all parties assess what areas need to be prioritized for security assessment.

As a default, however, we treat any change as security related and only reclassify it after initial evaluation, if there is really no value in further security input.

Threat modeling

For substantial or more sensitive planned changes the application security team uses a threat modeling exercise. Threat modeling is a process by which potential threats or the absence of appropriate safeguards can be identified and enumerated, and countermeasures prioritized.

This process is quite complex and requires time and effort. However, if done comprehensively and with relevant stakeholder involvement, it really adds a lot of value in the later stages of the development, as a “security by default” approach is applied from the first architectural discussions.

Stage 2: Development

As we progress to the development stage, it’s vital that everyone involved has a baseline understanding of software security best practices.

Training and knowledge sharing

In order to have great software you need skilled developers and quality assurance specialists, but these individuals also have to be trained in software security.

That’s why, at Nord Security, we are building an all-inclusive company-wide security training program. This will ensure that all our technical colleagues have a strong understanding of secure software development topics.

This isn’t the only way to provide security training, of course. We can also provide ad hoc training sessions for specific topics or technology, monthly infosec meetings, or security workshops tailored to certain job functions. We believe that knowledge sharing is a vital element in any successful application security program.

Code security review

As soon as we have some source code, we can initiate a code security review. Usually, this is done in two stages.

First, source code is tested via various automated tests and tools. Static application security testing (SAST), dynamic application security testing (DAST), and software composition analysis (SCA) tools are essential parts of secure SDLC.

It’s important to note that, while these tools work well, it’s best to combine them with human interventions. Manual review doesn’t scale with a larger code base, but it still plays a key role. From our experience, some serious vulnerabilities can still be found manually after automated tools are implemented.

Manual application security testing

Before releasing any product to our customers, we have to go through manual application security testing. This is done by experienced professionals who specialize in specific security topics, operating systems, and platforms.

How this part of the process plays out is very dynamic and depends on the functionality being tested. It can take hours, days, or even weeks to explore all potential attack vectors and abuse cases practically.

Any issues found during this stage are immediately evaluated from a severity perspective and all required information is passed to the development team. No known security issues are allowed to continue into the production stage.

Stage 3: Production

Application security is a continuous process, so even when the product is shipped to the end user there are still some tasks for the security team.

Ongoing security tracking

One important task at this stage is the continuous tracking of new vulnerabilities and attack vectors. At Nord Security, the application security team closely monitors product performance and watches for any issues with third party components.

If a problem arises, we can provide a hotfix with the updated solution or a completely new version release if major changes are needed.

External services

Multiple services are also delivered by external actors. At Nord Security we have a bug bounty program running with all the B2C consumer products in scope. This helps us rapidly identify any new weaknesses or bugs and quickly resolve them.

Another service used by application security teams like ours is pentesting. Pentesting helps us uncover new weak spots and areas of improvement, and brings fresh perspective to the team for future internal security tests.

In order to get the best outcome from external security audits, it’s vital that we work closely with the service providers and clearly define the scope of our needs.

Pro tip: Always plan dedicated development time for after pentest results are delivered. This gives you the flexibility to respond to bugs and weaknesses effectively.

In conclusion

Application security assurance is a complex process that goes hand in hand with development during all SDLC stages.

From architectural reviews and threat modeling to automated tests, manual reviews, and external services, every part of this cycle is necessary to produce a secure product. Without taking these essential steps, you cannot build trust with your users and ensure their safety.