Securing Your Code For GDPR Compliance

Building a  long-term program

By Jeannie Warner, Security Manager, WhiteHat Security

Introduction:

The deadline for GDPR initial compliance was May 25, 2018, but the directives enforcing Privacy by Design are not a  “once and done” project; The methodology used to create public-facing GDPR-compliant websites and applications demand a change in development and engineering practices. GDPR requirements are not bounded by network or application in scope; they are dedicated to the security and privacy of the citizens of the EU. Future lawsuits will likely focus on how well organizations are designing secure systems which allow for assessing, preventing and monitoring data privacy.

Every year, Verizon releases a Data Breach Investigation Report. In 2018 again, Web Applications top the list as the biggest vector for data breaches. It is not a trivial task to change the mindset of Developers and Architects and to make major changes toward a secured Software Development Lifecycle (SDLC). The truth is, many Developers and Architects focus entirely on the functional requirements of a system or application as handed to them by product management.  Non-functional requirements (NFRs)  within the user experience are often considered architectural choices rather than mandates. The overall security of the application has, outside of PCI DSS, been relegated to short paragraphs here and there within security and privacy regulations.

Complicating this lack of specifics is a push toward cloud services and third-party plugins, distributed data storage, microservice via distributed development teams, and insufficient architecture awareness of security threats, from both applications and the APIs that connect them with databases and services.

We need to bridge that gap by helping Developers understand that adding security as an essential NFR to every application will reduce churn, rework, and a large backlog of bug tickets. Management, both Engineering, Product, and Security need to speak the language of the developer to offer up support for their daily tasks using Developer’s language.

Mandates for scoping your secure SDLC for GDPR

The following are the mandates for scoping the GDPR Secured SDLC in terms of data privacy:

• Encryption and pseudonymization of personal data.
• The ability to restore personal data available in the event of a security incident or technical issue in a timely manner.
• Ensuring ongoing confidentiality, integrity, and availability of applications which touch EU Customer data.

• Establishing a process for regular security testing and assessment of the effectiveness of security practices and solutions in place.

Nothing successful can be done without executive support, budget, and buy-in. In support of these mandates, the following are high-level steps supporting your DevOps group both through management support and continuing communications plans and documentation:

1. Presumably your organization has created your GDPR Risk Register as you performed Gap analysis – you already determined which applications or vulnerabilities could not be scoped or addressed by May 25, 2018, but still may need review that the deadline has passed.
2. You need to set up a continual improvement and awareness program for long- term compliance.
3. Compliance/Data Privacy Officers need transparency into the newly compliant SDLC as part of their documentation on constant This includes process documentation and artifact creation such as:
   1. PCI DSS or other compliance-style formatted reports are always recommended
   2. Vulnerability detail reports which track age/longevity of vulnerability/risk
   3. SOC reports or other monitoring reports of threat activity for incident management
   4. Ticketing reports for status on remediation – the best KPI for process improvement is showing internal vulnerability remediation times dropping as Developers patch applications.

Security as an essential non-functional requirement

What is meant by essential and yet non-functional in the same sentence, one may ask? In Agile development terms, functional requirements include items such as Epics, Capabilities, Features, and Stories, all of which are dedicated to user, business, and market needs. Non-functional requirements define application attributes such as Security, Reliability, Performance, Maintainability, Scalability, and are handed to the developer by Solution Architects and Engineering. These are the constraints and restrictions on the application across the various product backlogs.

Application Security is an important part of GDPR compliance and needs to be addressed with exactly the same rigor and disciplines as Network Security. However, because GDPR has vague directives on the topic of applications as opposed to network assets, we can use the GDPR checklist for how to secure Databases combined with best practices in AppSec Security from PCI DSS and expand those ideas, checks, and balances into a full application checklist for Developers.

Privacy by design – sections of GDPR that mention apps

Privacy by design

The GDPR states that organizations need to “Develop a strategy and playbook for “privacy by design” to incorporate privacy controls and impact assessments  throughout the data lifecycle for new and changing data use initiatives”; That’s extremely vague as pertains to applications – how does one set boundaries on what defines controls and impact assessments?

Application Security or AppSec needs to be bounded and defined so that every aspect can be weighed and examined. Each of the elements of the application needs to be examined, both in UAT and production, as there can be vulnerabilities which are not  made manifest until examined for business logic as well as pure data intake evaluation:

• Testable – NFRs must be stated with objective, measurable, and testable criteria because if you can’t test it, you shouldn’t ship it.
• Independence – NFRs should be independent of each other so that they can be evaluated and tested without consideration of or impact from other system qualities.
• Negotiable – Understanding NFR business drivers can mean negotiation for what goes on a risk register vs gets fixed the very next release.

Privacy and security checks
Verify for Security early and often (See image of all SDLC stages, below)

1. Parameterize queries
2. Encode data
3. Validate all inputs
4. Implement identity and authentication controls
5. Implement appropriate access controls – authorization reviews
6. Protect data – least privilege & encryption
7. Implement logging and intrusion detection (monitoring)
8. Use secure frameworks and libraries (Software Composition Analysis)
9. Error and exception handling

For scope in this discussion, your NFRs matter most for web applications or sites where EU citizens have logins or accounts, or visit/distribute cookie information from which can be gleaned personal information, even via cookies, pursuant to GDPR scope.
Why do cookies matter in terms of data acquisition and theft?

This method of attack is not often mentioned in network security – A cookie is a token stored in a browser; however, it can be reverse engineered by the bad guys to trick a website into thinking it was the original cookie.

A secure SDLC for compliance

Once you understand the scope of your ongoing GDPR compliance program and agree that Privacy by Design is integral to your Developer tasks, you need to create design your vulnerability scan, test, and verification plan for AppSec management throughout your Software Delivery Lifecycle (SDLC). This includes both your testing and production environments because systems can behave with different values in pure code and test environments versus final staging and production.

To bake security testing into software development, you should take notice of how another testing is done. Unit and functional requirement tests are built custom for each application. In mature organizations, these may be abstracted, standardized, and even partially templated. Many organizations have entire teams dedicated to creating, running, and verifying the results of the unit and functional testing.

NFR security testing, like all other testings that takes place in the development process, must be generic (where possible) and specific (where necessary.) Ongoing risk discovery and management for the GDPR includes a need to:

• Focus on exploitable risks that exist in the application in its current released state.
• Scheduled scanning, scan points to the version of the code that is currently in release to customers or deployed in production (Master / Trunk / Released Binary).
• Findings from this concern should contribute to an organization’s top line risk metric for the application.
• Bug tracking integration or other reporting that the organization uses to track risk reduction initiatives, document future design requirements, etc.
• RD&M is typically the correct starting point.

Information security

All of this SDLC program design is pursuant to the GDPR InfoSec directive to “Identify existing security information protection controls and align security practices with GDPR considerations.”

1. Identifying assets – many organizations have 100’s applications they are not aware of, in terms of security.
2. You will need to work with architects and engineers to map the flow of EU
   citizen data through applications and databases. Use terminologies appropriate to the experience and understanding of the audience, i.e.:

For Executives or Audit officers, construct models that illustrate broad flows of customer, partner, and prospect information through your various applications and websites. High-level labels are fine here, as in this marketing-department example:

For DevOps, Engineering, IT Security, your architectural decisions are more detailed and function-oriented as you write up NFRs and consider testing.

At each API arrow in either model, consider how much of a customer record is really needed to move, transfer, or store, and how secure each of those actions the information is going to be. Remember to test for worst case scenario, like

What could someone with Super User access do? What could a regular user do? Can a stranger get at the system through tricking the authentication to allow them access?

Application security products supporting GDPR compliance

Choose your strategy for effective AppSec coverage across assets. Solutions include:

1. Static application security testing allows you to review code before it goes to production, to catch high- and critical-level vulnerabilities before risking exposure to the internet.
2. Software Composition Analysis, either built into the Static testing engine or as a second service, look at third-party libraries and frameworks which make up an estimated 75-90 percent of all web applications. Because security seldom has insight into the developer toolset, this is an important function to help blend the two into a functioning DevSecOps cooperative.
3. Dynamic application security testing looks at the functionality of a web application. Dynamic application scanning helps you stays on top of all newly- discovered vulnerabilities and exploits as they become public. In an ideal world, set up constant daily or hourly production-safe scans. Keep your security team aware of both new functionality as it is added to a website, and any subsequent security vulnerabilities created by them.
4. API scanning can be handled in various ways, but for high-risk information streams and ERP systems, you may want to do an evaluation to make sure that the information flowing between back-end systems is as airtight insecurity as the front-end systems. Usually, API checks are performed as part of Dynamic scanning, but for instances where there is no UI associated, you may want to look at a stand-alone API logic assessment/security scan.
5. Don’t forget Mobile applications Mobile App security testing is mandatory for mobile sites which touch or store EU customer data. If your app, game, or other service is offered via phone in an app store, make sure it doesn’t leak private customer info.
6. Bug Bounty programs – This is a useful add-on to your testing strategy or program; It is ad-hoc and requires internal validation of each finding by your development team and can incur higher costs in tracking and rewarding than simply operating a managed application security testing solution. Many companies maintain bug bounty programs in addition to a rigorous AppSec strategy, as it can allow for cutting-edge new vulnerability discovery if your risk tolerance is low and your IT security budget is high.

Consider Remediation vs Mitigation in risk: Backing up to the idea of Non-Functional requirements interfering with Functional requirements via legacy or third-party code, you may need to examine secondary protection for your web portal. The two best options on the market are:

WAF – Web Application Firewalls. If you have a network support team, they can often take over a WAF with minimal vendor training.

RASP – Runtime Application Self-Protection – this is an agent that is loaded onto the web application server to monitor runtime application commands and halt malicious user behavior.

Both of these options tend to cover the mandate for Logging and Monitoring – an important part of GDPR Incident Management. In organizations with no application- level logging and monitoring, it can be hard to find the actual vector of attack against an application.

Developer tools & integrations

As you move toward the Privacy by Design model of securing your SDLC, it’s best to integrate all your security checks into your Developers’ current daily tasks and tools. The easier you can make application security testing for your teams, especially if the teams are geographically distributed or spread over multiple shifts, the more likely they are to perform regular security testing. Take note which developer environments and toolsets (IDE/ALM/CI/CD, etc.) are at work, and plug into ticketing.

Privacy incident management

Build a scenario which engages DevOps on how to respond to emergencies, either identified internally or by someone outside your organization. GDPR says, “Align incident response processes with GDPR specifications and reporting requirements. Establish a triage approach to evaluating potential privacy breaches and incidents.”

As you conduct this alignment long-term, consider if your organization has sufficient AppSec expertise to execute this program, or whether you need program support or outside assistance as you create AppSec Champions.

1. Consider importing Dynamic scan results into WAF or RASP tools for your most critical applications to create virtual patches and prevent incursions rather than just report on them.
2. Import Dynamic scan results into SIEM or other VM/BI/GRC solutions to constantly assess and measure AppSec risk.
3. Finally, consider exporting Dynamic scan results into SOC monitoring infrastructure. SOC analysts love information and can always use AppSec training to understand how IDS/Network information can conflate with AppSec vulnerability data into a holistic security picture hour to hour.
4. Remember that any incidents or breaches of your web application security practices need to have a clear path leading back to your SDLC via ticketing systems and a review of your NFRs.
5. A Risk Register started during your Design and Requirements phase in development, will serve your entire SDLC by allowing full transparency as well as tracking your improvement.

Don’t forget training and awareness

GDPR says, “Define and implement a training and awareness strategy at the enterprise and individual level.”
You’ve implemented GDPR training for sales, marketing, customer service – don’t forget engineering Developers and IT Security Managers need training and education to understand the basics of risk analysis and threat modeling for applications as well as best practices in secure coding.
Close the loop of Security by Design by educating your DevOps team into avoiding bad practices from the beginning.

Resources for training and best practices on secure coding testing include:

• OWASP Secure Coding Practices –
• OWASP Application Security Verification Standard Project –
•  WhiteHat’s eLearning for Developers
• NIST – Systems Security Engineering (SSE) Project
• SANS – Security Web Application Technology

About the Author

Jeannie Warner,  Security Manager at WhiteHat Security. She currently serves security manager at WhiteHat Security. She believes application security is the Next  Big   Thing in the security space. Her path to computer security started with DellNet Technical support, then into a Unix Helpdesk, followed by Network Ops. She went to work at IBM as they were building out their Security Operations Center in 2001, and after a short while became their tech lead. She moved on to security analysis and forensics from there, and eventually product and portfolio management. After IBM Security, she left for Microsoft’s Security Research Center before returning to the Bay area to work for Symantec and Fortinet, with a brief stint off to Australia to run a global SOC operation. Jeannie can be reached online at ([email protected], @thetsmorgan, https://www.linkedin.com/in/jeannie-warner-cissp-5585851/)  and  at  her  company website https://www.whitehatsec.com/