Whitepaper: Using Static Analysis for “Secure-by-Design” GDPR Data Security and Privacy

GDPR calls for better privacy and security practices, but testing and dynamic analysis aren’t enough. Static analysis builds security into your software, preventing vulnerabilities and complying with GDPR.

Get the facts on using static analysis to comply with GDPR and improve quality, security and data privacy of your software.

Parasoft_Security_Solutions_Automated_Software_Testing

Download the whitepaper to understand why static analysis is a solution for improving security and privacy of user data using a security by design approach.

Focus areas:
  • Impacts of GDPR
  • Understanding security and privacy by design
  • The role of static analysis
  • Getting started with static analysis for security
  • How Parasoft helps with GDPR compliance 

The inception of GDPR requires all companies doing business in the EU to inform users what data is being collected, how it will be used, protect it, exercise transparency when breaches occur and remove user data completely if requested. As with all compliance legislation, failure to comply results in considerable fines.

Today, most commerce is global, requiring diligence in complying with the regulation across the globe. Affected organizations have two choices:

  1. Treat all users in a secure, private manner
  2. Have a completely segmented data flow for EU and non-EU customers (a more expensive option)

Static analysis is a solution for improving the security and privacy of user data, ultimately supporting a security by design approach.

Increasing testing, dynamic analysis and penetration testing are generally thought of first responses to data regulations like GDPR. These testing technologies are definitely necessary and important, but they don’t make software more secure or ensure privacy—they only reduce the likelihood of shipping insecure software. You can’t test security and privacy into software, just like you can’t test quality or performance into software. Instead, you have to build software better in the first place using the concepts of “security by design” and “privacy by design,” which emphasize proactivity and anticipating and preventing privacy invasion events before they take place.

Security and privacy by design require planning, requirements, design and implementation first before application security activities happen. Instead of trying to hack your application in testing and fix the vulnerabilities, you should build an application without vulnerabilities. Consider SQL injections: they’re one of the most common exploits, but it’s easy to prevent them with the right design.

Static analysis is designed to ensure software is robust, with security and privacy built in. Though there are tools available to detect vulnerabilities, building security in is still the better approach. Thus, software teams need to more than test. They should be using static analysis as a preventive technique prior to a GDPR audit. This ensures software is built securely because static analysis rules can be applied project-wide amongst different languages and target systems.

The GDPR isn’t a coding standard, which means there’s no simple static analysis configuration to satisfy the regulation. Regardless, to make software more secure, cost effective and with low effort, a good starting point is finding static analysis rules that relate to issues found in testing, like XSS or SQL injection issues. These kinds of issues usually have associated static analysis rules that work as bug-finders, providing early detection of issues prior to testing.

Also, associated rules around input validation ensure SQL injections can’t occur in the first place. Programming so that validation always happens is much easier than relying on data flow analysis or manual code inspection to trace data from user input to storage. Plus, it’s easy to test for.

After enabling rules that align with vulnerabilities and issues found in testing, it’s time to create a configuration of static analysis rules.

GDPR requires that compliance is documented and demonstrated. Since there’s no specific coding standard, the best route is to borrow best practices from other standards that cover data privacy and protection, such as OWASP Secure Coding Practices, MITRE/CWE/CERT secure coding standards and PCI-DSS. This will go a long way in showing appropriate care for privacy for GDPR.

If a software project is already using other security requirements like the MITRE/CWE and CERT secure coding standards, it’s easy to leverage existing rules in these standards related to data privacy, data protection and encryption.

Parasoft automated software testing tools allow software teams to increase quality, security and data privacy using detection, prevention enforcement and compliance reporting. Advanced static analysis is ideal for detecting violations, and Parasoft static analysis has built-in support for OWASP Top 10, PCI DSS, CWE-Top 25 and more. These rules prevent vulnerabilities in the first place.

In addition, Parasoft compliance dashboards offer security and privacy related reports sorted by severity, location, type and history.

About Parasoft

Parasoft’s software testing solutions support the entire software development process, from when the developer writes the first line of code all the way through unit and functional testing, to performance and security testing, leveraging simulated test environments along the way. Parasoft's unique analytics platform aggregates data from across all testing practices, providing insights up and down the testing pyramid to enable organizations to succeed in today's most strategic development initiatives, including Agile/DevOps, Continuous Testing, and the complexities of IoT. Parasoft’s automated software testing innovations fuel software development organizations, helping teams reduce the time, cost, and effort of delivering high-quality software to the market.