Micro Focus is now part of OpenText. Learn more >

You are here

You are here

DevSecOps and GDPR: How to go from requirements to deployment

public://pictures/johanna.jpeg
Johanna Curiel Co-founder, Ossecsoft
 

Embedding security within the development lifecycle is already challenging, and with the introduction of the General Data Protection Regulation (GDPR) law in May, it has become even more arduous.

This is particularly true for companies that handle a lot of personal data about European citizens and are developing applications that must take into account how to protect it.

Here's a practical guide to practicing DevSecOps in the age of GDPR.

Understand personal data assets

The software development lifecycle (SDLC) starts with gathering requirements. But gathering security requirements that apply to GDPR might be confusing if you do not first understand what you need to protect. According to the official GDPR website, this applies to the personal data of European citizens such as:

  • Name and surname
  • Home address
  • Email addresses such as name.surname@company.com
  • Identification card numbers, including passport number
  • Location data (for example the location data function on a mobile phone)
  • IP address
  • Cookie IDs
  • The advertising identifier of a person's phone
  • Data held by a hospital or doctor, which could include a symbol that uniquely identifies a person

This isn't the complete list. Some other personal data might include sexual orientation or activities that can be linked to a specific person and that should remain private.

Create a personal-data-flow diagram 

Once you have made an inventory of all the personal data that your application is or will be collecting, a data-flow analysis is necessary. You need to know where this personal data is going. 

For this exercise, you need:

  • A software architecture diagram of the application with all the components
  • A complete inventory of the personal data
  • The Lego pieces representing personal data

Each Lego piece represents one part of the personal data (name, surname, identification number, IP address, etc.). 

Example: Registration form

Many applications start the collection of personal data through a registration form. Imagine the data as pieces that are submitted through it, and then data is transported through the communication channels. Data eventually reaches an AWS Lambda API, which executes a REST command to create a record in a MongoDB database.

Whichever specific systems you use, the point is that personal data flows through different channels, which requires the proper level of protection.

Define security requirements, OWASP-style

The risk that personal data could be intercepted or compromised at each step of the application architecture requires that you apply security requirements that match the expected risk. You can do this with the OWASP ASVS Guideline. The Application Security Verification Standard is a list of requirements or tests that can be used to define what a secure application is.

ASVS Level 2 helps you set the baseline without having to think about it from scratch. However, some of these standards might be a little ambiguous. Before trying to apply ASVS, it is essential to understand some security principles and concepts and how they apply to your specific technology stack.

Some of the confusion incudes the following:

Section 2.4: Verify that all authentication controls are enforced on the server side

Authentication controls require a user to authenticate first—in other words, to verify that the user is who he or she claims to be. But in the case of a registration form, a person is not required to authenticate, since he/she is in the process of registration. Therefore, this requirement does not apply for part of the application (registration form).

But the following is a different ballgame.

Section 5.5: Verify that input validation routines are enforced on the server side

Imagine that the interface of the web form is built using AngularJS and that, once the form is submitted to the API, the SpringBoot Java Framework processes the request. Server-side input validation is a must, but you need to analyze which data from this request requires validation and which vulnerabilities you are trying to protect the application against.

Examples of where Section 5.5 applies

Name and surname are strings and should not contain numbers or other types of non-alphabetic characters

  • Not encoding or sanitizing improper input in a web form can lead to vulnerabilities such as XSS attacks.
  • Not sanitizing the input-strings parameters from a request (POST/GET) to the REST API can lead to issues such as JSON injections, bypassing access controls, direct transversal vulnerabilities, and other problems.

In other words, you need to analyze very carefully the attack surface at each step where data is flowing from one part or component to another. This is the hardest part to get right, because it requires analysis and controls at each step.

Apply secure coding

Now that you know what should be done at a high level, it's time to get your hands dirty with applying those controls. In the previous example, we have two web form fields that require validation, such as allowing only strings of alphabetic characters. Names must not contain any characters that aren't alphabetic. 

Front-end developers have many different AngularJS functions they can apply, for example. Choosing the correct one is the challenge, and you need to verify through testing that the developer applied the correct control. 

For the back-end validation, Springboot Framework contains different functions that you can utilize for this purpose. 

Static analysis: Catch low-hanging issues during development

Static analysis is an important piece. The earlier problems are discovered during this phase, the faster you can fix those issues. During the static analysis, you can uncover two major types of problems:

  • Vulnerabilities related to components and libraries used in the project
  • Vulnerabilities created by the way a developer has implemented the code, such as hard-coded passwords and unencrypted OAuth 2 tokens in configuration files

In the case of AngularJS, imagine the developer has implemented a library version that contains a common vulnerability. Tools such as the OWASP dependency check can uncover this quickly. Problems caused by the way the developer has programmed features can be found with static code analysis tools, which also find problems related to common vulnerabilities.

Fixing these issues at this stage of the SDLC is a lot cheaper and faster than waiting for a penetration test. Vulnerabilities found at this stage put the personal data at risk of being compromised.

Secure deployment

With the example of an application that gathers personal data through a registration form, consider also how to protect the data based on the configurations that are done server-side and via proper secure communications. The OWASP ASVS contains entire sections dedicated to requirements for both general communications and HTTP security configurations.

Both are essential for a secure deployment. Data must be protected during submission through the use of HTTPS and proper deployment of TLS certificates. These and other important requirements are contained in the section for protecting data in transition but also to apply secure server-side configurations.

Last but not least: Final assessment

Once the cycle has been completed—and during each phase, you have carefully analyzed how to apply the OWASP ASVS Level 2 requirements for each component of the application or while in transmission—you need a final review in the form of security tests.

Based on the requirements already defined and the technology or type of applications used, you can use the OWASP Testing Guide (for web and APIs) or the OWASP Mobile Project (for Android/iOS) to create specific test cases or stories during the sprint and systematically test at the end of it. You will find out if the protection levels are working correctly.

With this guide, you can go from security requirements to deployment with your DevSecOps.

Any comments or questions? I am happy to discuss in the comments section below. Plus: Share your team's best practices. 

Keep learning

Read more articles about: SecurityApplication Security