Setting up static analysis correctly with the right tools and the right rules will help you protect software security, prove that you are doing the right thing for your organization, and show that you are following the principles of design security and design privacy.

GDPR is huge and frightening. If you’re not sure what GDPR is or is important to you, take a look at my last post. In a nutshell, this means you have to let users know what data you’re collecting, how to use it, protect it as best you can, be transparent when violations occur, and completely delete any user data when they request it. Of course, there are huge fines if you don’t comply.

In theory, the GDPR applies only to EU citizens, but today, most businesses around the world try to comply with global regulations. That way, you can choose between treating all users in a secure, private way, or having a fully segmtioned data stream for EU and non-EU customers (for example, the more expensive way). In this article, I’ll show you how static code analysis can be leveraged to help improve data protection and privacy.

Design security and design privacy

When considering GDPR, data protection, and other relevant data regulations (such as PCI-DSS (Payment card industry Data Security Standard) or HIPAA (Health Insurance Portability and Accountability Act)), the need for additional testing, dynamic analysis, and penetration testing immediately come to mind. While these testing techniques are necessary and important, they reduce the opportunity to release insecure software without actually making the software more secure or ensuring privacy in the first place. However, in addition to quality or performance, neither security nor privacy can be “tested” into software. GDPR therefore requires concepts called “design security” and “design privacy” (PbD), which means building software better in the first place.

“The design privacy approach is characterized by taking active rather than passive measures. It can anticipate and prevent privacy intrusion events before they happen. PbD does not wait for privacy risks to arise, nor does it provide remedies to address privacy violations — the goal is to prevent such incidents from occurring. In short, “privacy by design” is something that happens before, not after.”

A. Cavoukian, Designing Privacy — The Seven Cardinal Principles, January 2011.

I bring up these two concepts because they are the next step after normal application security activities (firewalls, penetration testing, red teams, DAST, and so on). The “by design” section can also be understood as “built in.” This is the idea, rather than poking your app and determining where the bugs are, to build an app without bugs in the first place… It’s by design. For example, SQL injection (SQLi) remains one of the most common exploits.

There are a number of tools that can try to force injection through the UI (penetration testing), or simulate the flow of data in a program without running it to see if tainted data can make it into a database query (flow analysis). The “by design” approach means wrapping any input (from the database, the user, or anywhere) inside the validation facility as input is taken. This reduces the number of possible paths the data can take around zero. You still need to run penetration tests to make sure you’ve built the software correctly, but the difference is that if Pentest succeeds, you can not only address a weakness you’ve found. Instead, you go back and figure out why you tested it successfully and build your software so it doesn’t work.

If Pentest finds a lot of security holes in your software, you’re not building security software “as designed.” Similar to Design privacy, we monitor shared objects/shared objects/shared objects and assume that all data is important unless otherwise stated. Again, programmers often assume that data ISN’t important unless specifically flagged. You can see this in decisions about whether to store data in a pure format or whether to encrypt it. Encrypting everything is a way to protect privacy by design. One of many, but that’s the basic idea. If you encrypt everything, you don’t have to worry about not encrypting what you should have.

What role does static analysis play here?

The role of static analysis is not to tell us that our software is vulnerable (that’s the job of testing). The role of static analysis is to help ensure that the software is robust initially… By design. Flow analysis has become popular as a security testing technique over the past decade, but it is still a way to test software, not a way to enforce software, build in security, or “by design” security.

When used correctly, static analysis can be positioned as a true prevention technique. In addition to process analysis safety rules (that is, finding contaminated data), we have enabled rules to ensure that software is built in a safe manner. Considering the above two cases, when the design for privacy protection, I can use static analysis rules to remember when storing data without first encrypt, can solve or when to use the old improper encryption methods rather than strong encryption, or when users try to access the appropriate data to obtain the expected permissions.

This is a brief description of an example rule that enforces logging when sensitive methods are called. This static analysis rule will not find errors, but will help you make software that records what is happening, making it safer in production. This rule is well suited for PCI-DSS and GDPR.

Make sure all sensitive method calls are logged [security.bv.enfl]

Description: This rule identifies code that does not log sensitive method calls. If you use some sensitive method invocation (for example, from “javax.mail. Security. The auth. Login. LoginContext” of the “login” and “logout”) did not record, will report an error.

Another example of privacy by design is this rule, which helps prevent your software from inadvertently revealing personal or important information if it does go wrong:

Do not pass exception messages to the output to prevent the application from leaking sensitive information [security.esd.peo]

Description: This rule identifies the code that passes the exception message to the output. An error is reported when the catch clause calls the output method and the exception caught in the catch clause appears in the parameter list or is used as the call object.

This rule covers OWASP Top 10, CWE, PCI-DSS, and GDPR — which means it’s a good idea no matter why you’re trying to secure.

An introduction to

Because GDPR is not a coding standard, there is no simple static analysis configuration that can override it. In general, the best place to start is to find static analysis rules that are directly related to the problem you are currently discovering in testing, such as XSS or SQLi problems. Such problems often have static analysis rules that act as bug spotters and allow early detection of problems before they are tested. More importantly, in this case, there will also be associated rules around input validation that will help you ensure that SQLi doesn’t happen at all as I mentioned above.

It is difficult to track data from user input through storage. It’s easy to program validation to always happen. It’s easy to program encryption to always happen, and it’s easy to test. Why is it so hard?

What are the other static analysis rules?

Once you have found and opened the rules for finding problems during testing, you will need to go further. I suggest you borrow some ideas from other coding standards that already cover data privacy and protection. OWASP, HIPAA, and PCI-DSS are some good choices. GDPR will do well if you enable any rules related to these standards in your static analysis tools. In fact, if you already qualify for PCI-DSS, you’ll find at least this part of the GDPR relatively easy to prepare for.

If you already have other security requirements, such as CWE or CERT, make sure to comply with those requirements and extend the configuration to cover the specific GDPR data protection necessary by finding any items in those standards related to data privacy, data. Protection and encryption.

What else can Parasoft do for you?

Parasoft can help you keep your code secure and private in several ways. First, all of our static analysis engines have configurations for OWASP, CWE, CERT, PCI-DSS, HIPPA, etc. You can open up a set of security rules that perfectly fit your organization and then automatically enforce them.

In addition, when you integrate Parasoft DTP with static analysis, you have full auditing capabilities that automatically document the process of running which rules in which code and at what time. You can prove that you’re testing based on the rules you choose, and you can even design for security.

Parasoft DTP also has some very special reports. If you choose to base your security efforts on CWE, the Parasoft CWE Dashboard gives you excellent SAST reports, such as problems by severity, location, type, history, etc. Technology impact data was further implemented in CWE. Technical influence (TI) is research done at Miter, part of the Common Weakness Risk Analysis Framework (CWRAF), and helps you classify SAST results based on the problems they may cause. Therefore, TI tells you that a buffer overflow can lead to denial of service, rather than a message indicating that you have a buffer overflow (which some people may not recognize as a security issue).

Each CWE discovery tells you what types of problems are likely to occur, and there are special graphics to help you navigate a static analysis of the problem based on the problem area that is most important to you, not just the severity level. This breakthrough technique can help you solve situations that often lead to a lot of bugs, especially if you’re using older code bases. Focus first on the problem that scares you the most. Of course, while I’m focusing today on static analysis as a way to do security by design, keep in mind that Parasoft also has penetration testing tools, API testing, and service virtualization, all of which are important parts of the tools. Comprehensive security software development strategy.

conclusion

GDPR can look scary, and it is, but setting up static analysis correctly with the right tools and the right rules will help you keep your software secure, validate what you’re doing for your organization and show that you’re following the principles of design security and design privacy. This is something that penetration testing itself cannot do. Beyond that, you’ll find that it’s much more effective to think about security “as designed” than to try to test ways to secure software between quality checks and release. For further discussion and research, comment on comments or private messages.