Part II of a 2-part series to inform the AppSec community regarding the upcoming GDPR regulations.

If you missed my first 3 tips, check out Part I here.

1.    Default to “Secure”

When looking at any modern application, one will find a myriad of components, frameworks, APIs and code snippets written by various developers inside and outside your organization. Not all of them are as secure as they should be, and not all of them default to the most secure protocol, design pattern or follow best practices for the type of data your application is processing. While it may be easy and save time to simply pull a code snippet from Stack Overflow or download an npm module, the security implications skimping on critical components could be catastrophic.  

When checking if your application does everything securely by default, keep in mind some common application design issues, like not hashing and salting passwords; trusting user input too much; or using a poorly implemented encryption cypher.  Consider insecure defaults that might come down as business requirements, such as exposing sensitive map data without properly threat modeling the implications. At the same time, consider if all the security-related business logic requirements are specified, for example, not checking a blocklist for sanctioned counterparties in a business transaction.

Ultimately, your organization needs to establish a set of companywide security design guidelines, which developers can follow. For example, establish secure design principles like: defense in depth; simple design; and secure failure of components. Establish secure architecture patterns like an authorization and authentication subsystem, centralized logging, and hardened interface design. Consider creating centralized security services and components that application scan “plug-in” to and standardize on secure and vetted libraries and components that can be re-used. 

All of this will establish a set of secure defaults that are followed for all of your software development activities and ultimately help you meet the GDPR requirement.

2.    Trust, But Verify

It is always good to trust your developers and architects to follow established security patterns, yet verifying and validating is an essential part of the software development cycle. Just like Quality Assurance validates functional requirements, security of the application needs to be validated as well. GDPR requires regularly testing and validating the security of data processing.

Good verification program starts by validating Security Architecture and Design reviews. This is where you will check that design issues did not creep-in to your application; that things like authentication and authorization properly in place; that everything that should be encrypted is encrypted using adequate encryption technologies; and that user input is properly verified before using it for business logic decisions.

Implementing static and dynamic scanning tools will help you catch low hanging fruit and all the coding mistakes that might lead to easily discoverable vulnerabilities. Build the use of these tools into your nightly builds, as well as your QA or your development process. Configure these tools specifically for your app and get an even better false positive rate.

Because tools will only go so far, have developers review each other’s code and consider hiring a security firm to code review and perform a penetration test on your important apps and services. Penetration tests will take into account your business requirements and your threat model. They will dig deep into the application to see what an attacker can really do and how effective your controls and counter measures are.

BONUS TIP: Training

I know we said top 5, but developers do count from zero! While GDPR does not mandate any specific training, it is an integral component of any application security program. How do your developers know how to write secure code? How do they know what components are critical and where they should ask for security guidance? Equally important is how do you build a culture that takes security seriously, especially when no one is really incentivized to write secure code or produce secure architecture? This is where training comes into play. Adequate training and awareness programs will allow your organization to meet GDPR requirements by having your developers and testers know what to do and when. How to design a secure architecture; how to build an authentication routine that is secure; how to properly protect your database connection strings and what encryption technologies to use. All of this knowledge requires training.

THINK APPS – Following these activities will help you prove compliance with GDPR requirements. Remember GDPR is huge, but if you are following the spirit of this regulation your company will be in good shape, even if Data Protection Authority has questions.

For even more insight into how application security fits into GDPR, check out our on-demand webinar: GDPR: The AppSec Twist.