In the Application Security team, at The Workshop, we perform many interesting activities. One of these is conducting Security Assessments for existing projects and defining Security Requirements for new features. In this post, I will share our approach and guidelines that can help you to address Security aspects in your product, without having to involve a specialist consultant.

First Security Assessment

I joined the AppSec team about ten months ago from Product Development, bringing with me a large amount of experience in software engineering. After a couple of months of intensive on-boarding in AppSec, the day finally came when we were asked to perform our first Security Assessment.

I have to say, starting the process from scratch felt totally unclear and confusing to me. Where to start? How to understand the project? Where to look first? How to not miss something important?

One additional factor further complicating this task, was that the project team was located in another office. We were given a large bunch of documentation and access to code repos, here you are – go! I remember sitting at my desk and looking at my team mate with my eyes wide open while feeling total confusion…

Fortunately, our experienced team lead had the plan. The key to kick it off was in ASVS.

OWASP ASVS

 ASVS stands for Application Security Verification Standard. It is a 68 pages long document collating together the best practices and recommendations for designing, building and testing Web applications.

ASVS is maintained by OWASP: a community-driven non-profit foundation that works to improve the security of software. Quoting the document: “ASVS v4.0 is the culmination of community effort and industry feedback over the last decade”.

ASVS consists of 14 chapters, covering various aspects of web application security. Representatives of various roles involved in the development lifecycle can find highly useful information in ASVS:

• “Architecture, Design and Threat Modelling Requirements” is a must-read for Architects
• The “Authentication Verification Requirements” chapter includes non-technical recommendations that Product Managers and Business Analysts can benefit from when shaping projects that include Login functionality
• Every self-respecting Developer cannot be missing the points listed in “Error Handling and Logging Verification Requirements” when writing code
• Looking at “Configuration Architectural Requirements” is definitely a worthy read for DevOps
• Lastly, an AppSec Engineer like me has to aim for, at least, awareness in each and every area and aspect of them all.

Lessons Learned

Using ASVS as a guideline we managed to successfully complete the first security assessment. Based on the checks performed, we came up with a set of recommendations many of which were taken into account by the project team in further product enhancements.

Main lessons learned from a couple of initial projects:

• Understanding the project and exploring the large codebase at the end of development is a hard and very time-consuming exercise
• In the limited time allocated for the Security Assessment, only limited review coverage can be provided, leaving certain important areas un-inspected
• Sometimes design flaws discovered by a late Security Review can be hard to fix, since the change in the architecture implies significant rework
• Having a long list of security findings produced just a couple of weeks before launching the project in production is putting additional extra stress on all the people involved
• A lot of security findings across different projects are similar.

Taking into account such observations, we decided to change the strategy and treat our next project differently.

Start with Security Requirements

The main advice to take out from this article is: Start with Security Requirements as early as possible instead of leaving it to the end!

ASVS can be applied as an Application Security Verification check list, but it can also be used as a source of inspiration when defining both functional and non-functional requirements for a product. Building the foundations for a secure codebase from the beginning of development is crucial to achieve a risk-free software product with the minimal cost. Making AppSec expertise a part of the project team from the start is the approach we tried and it proved to be successful.

New Project

In a big brand-new project, where we decided to apply the new approach, I was participating in all phases and almost full-time. Starting from early collaborations with the Product team, to contributing into shaping the Architecture; from participating in task refinements with engineering teams and performing code reviews, to producing some POCs and production code with my own hands.

As a result, the level of compliance with security best practices achieved in the project was high. Usual penetration testing, at the end, discovered much fewer issues than we were used to see. Not having a “Big Bang” security bomb discovered in the last stages of the project means not putting additional stress on the team, giving more time to focus on finalising the project according to the plan.

While the total effort dedicated to Security aspects in this approach was relatively large (part to full-time involvement of one person for duration of 3-4 months), the value provided and ASVS compliance coverage achieved was way higher than when following the usual approach.

Takeaways

• OWASP Application Security Verification Standard provides a way to quickly start with Security Requirements for your project, so give it a read
• Starting to dedicate time to Security from the beginning of the project is the way to achieve more secure results for lower cost.