Three weeks to start AppSec, the simplest plan for improving your security posture

'Shift security left' is a popular IT industry paradigm, most start-ups are eager to adopt in theory, but discover obstacles when applying it in practice. There are no common guidelines on how to start application security. Sirris now offers you a solution: 'the simplest 3-week plan for improving security posture'.

How to shift left with application security

'Shift security left' is a popular IT industry paradigm which is very easy to understand, but not so obvious to implement. The basic idea is to find security vulnerabilities as early as possible during software development, so less rework is to be done later. It is simply faster and cheaper. For this reason, knowing how to start AppSec is valuable. Adopting this statement requires more than just use of technology and tools: it is a shift in culture, integrated approach to application security and continuous learning process. Most start-ups are eager to adopt it in theory, but discover obstacles when applying it in practice.

Perhaps, the existing strategies are tailor-made for companies with a defined security posture but there are no common guidelines on how to start application security, especially if start-up has limited resources and expertise. What are the basic actions to take in order to have a clean security maturity improvement plan and be ready to answer the customers' questions about trust and security?

The simplest 3-week plan for improving security posture

Being driven by the passion to find pragmatic solution for start-ups that really works, we spent almost three months on research and brainstorming at Sirris. Here is a result: the simplest 3-week plan for improving security posture. It is inspired by DevSecOps philosophy and OWASP standards.

Read on for a brief teaser on a first week of the simplest security improvement plan!

This is our first blog out of three to help you discover what to do to improve security posture by starting with application security.

First week: formulate your security requirements and goals

Starting from goals and requirements helps to see the high-level picture and allows you to use the phrase “secure-by-design” when speaking with clients. How to? There are several tools and standards such as OWASP Application Security Verification Standard and Mobile ASVS that provide a technical basis for the requirements for any feature you need. The requirements are very well grouped by features and levels or security goals.

Short example

Suppose, a developer implements a password authentication in an application that stores clients' personal data. Such app can be immediately classified as level 2 ASVS app or the baseline security level. A set of security requirements to the password authentication feature (or a sprint) can be derived from section 2.1. of ASVS. There are 12 requirements to secure passwords:

This list of requirements looks long and detailed. However, the task of developer is to make sure that his feature complies with this list. It contains ALL up-to-date password security measures.
But how to organize it in practice? No worries, such tools as OWASP Security Knowledge Framework and OWASP Cheat sheets contain tons of examples of good practice code snippets related to each of these requirements. Additionally, SKF helps to automate the feature selection and requirements generation and is extremely useful on this stage. But probably, the best outcome of using such approach is the awareness: you know what is needed in order to comply and you do not need to do anything more than then. You are in OWASP level 2 in your password authentication.

 

What will be the outcome of the first week?

  • You will be able to answer almost all security questions of the customer.
  • You will know your security maturity level, and what is needed to implement it
  • You will conform to widely accepted standard (OWASP)
  • You will have a proof of concept (generated with the help of OWASP SKF) 

Having security requirements at hand in pre-developmental design phase helps to define the security posture for the very start or really implement the 'shift left paradigm'. Isn`t it tempting to spend just one week on requirements definition in order to know your critical points and maturity? 

Curious to know what the next steps are?

There is more to come! Follow us on our blog

Having any other practical question on application security? Contact us!