Securing Your Code: GDPR Best Practices for Application Security

Your age, gender, what you buy or sell, where you go, who you see, what you post on social media, what you study, what you believe, what you wear, what kind and how much exercise you do, how healthy you are, your relationships, where you work, what you earn, and more — it’s all online, creating a staggering trail of “digital breadcrumbs” that can assemble a more detailed and intimate profile of a person than ever before possible in human history.

You are your data. And if your data isn’t private, you have no privacy. That’s the reason for National Data Privacy Day, on January 28 every year.

Get NordVPN

The event was launched in Europe in 2007 as Data Protection Day, and in the U.S. with its current title two years later. In the decade-plus since it raised awareness about how vast and intrusive data collection can be, it’s been a catalyst for the passage of nearly 130 data privacy laws worldwide.

It has also spurred an ongoing debate about the state of personal privacy. Some argue that there are reasonable privacy protections in place, while others say privacy has never been as dead as it is now, and point to the “golden age of surveillance” by both the private and public sectors.

To keep data private, it has to be kept secure

But there isn’t much debate over the fact that for data to be private, it has to be secure. It doesn’t really matter if a law restrains what organisations can do with the data they collect if it’s vulnerable to theft by criminals.

So one of the primary goals of any initiative to stay in compliance with privacy laws should be to push for use of the best tools, techniques, and practices to keep data secure. And that requires a focus on securing the data itself and also securing the environments where data is stored, which are powered and controlled by software.

When it comes to securing data, the most familiar requirements come from the most famous data privacy law on the books so far: the European Union’s General Data Protection Regulation (GDPR), which took effect May 25, 2018, and has served as a template for many that followed. While it technically applies only to the EU, as a practical matter it’s global, because it applies to any organisation that does business with the EU.

But the GDPR’s most specific focus is on restricting the use of data — its collection, processing, sharing, selling, storage, retention, deletion, and so on. Security requirements are also included but they tend to be more general.

The law says data must be “processed in a manner that ensures appropriate security of the personal data, including protection against unauthorised or unlawful processing and against accidental loss, destruction, or damage, using appropriate technical or organisational measures.”

That mandates a specific result but doesn’t spell out what an organisation needs to do to “ensure appropriate security” of data or what “appropriate technical or organisational measures” are.

Most experts say that’s a good thing — that government should require a result (in this case, data security) but not dictate to the private sector how to achieve that result. Expecting government legislation to keep up with the evolution of technology is like expecting a horse and buggy to keep up with a high-performance sports car.

GDPR best practices for data management

But although most companies collect and use data, they aren’t directly in the data security business. Which means they could use a set of best practices.

Ian Ashworth, senior sales engineer with the Synopsys Software Integrity Group, offers a short list of fundamentals:

1. Classify your data

All data isn’t the same, nor is it equally valuable to an organization, to its competitors, or to attackers. “The first step to keeping data safe is to classify it,” Ashworth said. “This is a fundamental element of any information security program. Keeping data safe can be costly, so classifying it ensures that the right proportion of any spend is efficient and justified.”

Classification is also directly focused on the confidentiality component of the CIA triad (confidentiality, integrity, availability) for data.

A good tool to help classify data is metadata (data about data), which can help find personally identifiable information (PII). Ashworth said a good way to start is with high-level classifications like restricted, confidential, or sensitive.

“From there you can look within and classify individual attributes or fields such as payment cards, which have very distinctive data patterns, or rely on the metadata, which might aptly and accurately name a field and lead to it being classified as PII,” he said.

2. Establish a data use policy

This sets conditions for who can access certain data and for what purposes. These should be granted on a least-privilege basis. If you don’t need it to do your job, then you don’t need access to it.

“A website may require read-only access to data for the purposes of displaying it,” Ashworth said. “To edit or modify it, you would need to have a reason, such as an owner wishing to change their registered phone number on an account. That higher level of edit control might only be available to the account owner and system administrator.”

Those controls could be contractual or enforced through authorization based on a person’s electronic identity.

“There is a common acronym, AAA (authentication, authorization, and accounting), in cybersecurity parlance that refers to measured access controls to certain digital resources,” he said.

3. Encrypt your data

“Layers of security do play a part in defending against unauthorized prying eyes, but the most critical measure is encryption,” Ashworth said.

And for encryption to be effective, it has to be both rigorous and comprehensive, applying to data both when it’s at rest and in transit. That means organisations need to map their data — both where it’s stored and how it flows from one place to another. You can’t protect assets if you don’t know where they are.

Encryption can also ensure the second element of the CIA triad — the integrity of the data. Hash algorithms, which are very difficult to reverse or attack, can let an organisation that has been breached know if its data has been modified.

“If data is passed through such a hashing algorithm and the hash is stored independently, then if the original text is changed, a different hash would result, confirming it is no longer the original stored text,” Ashworth said.

Done correctly, encryption means that even if an organization is breached and data is compromised, it’s useless to attackers.

GDPR best practices for application security

Then there’s the software security component. Software is embedded into every digital component of a company, and is therefore a major piece of what protects, or doesn’t protect, the data.

There are thousands of examples of what can happen if unsecure software is exploited, but one of the most notorious is the 2017 breach of credit-reporting giant Equifax, which compromised the social security numbers and other personal data of more than 147 million customers. It happened because the company failed to apply a patch to the popular open-source web application framework Apache Struts — a software patch that had been available for several months.

There are a number of fundamentals to help organizations avoid becoming the next Equifax.

1. Build secure software

This requires the use of multiple tools and processes throughout the software development life cycle.

  • Architecture risk analysis and threat modeling can help eliminate design flaws before a team starts to build an application or any other software product.
  • While software is being written and assembled, static, dynamic, and interactive analysis security testing can find bugs or other defects when code is at rest, running, and interacting with external input.
  • Software composition analysis can help developers find and fix known vulnerabilities and potential licensing conflicts in open source software components.
  • Fuzz testing can reveal how software responds when it’s hit with malformed input.
  • Penetration testing, or “red teaming,” can mimic hackers to find weaknesses that remain before software products are deployed.

Once software is up and running, an ongoing requirement is to keep it secure. Those measures include:

  • Keep it up to date. This includes keeping track of it. One of the mantras in security is “you can’t protect what you don’t know you have.” So maintain a software Bill of Materials and apply security patches and updates as soon as they’re available.
  • Protect its environment. One of the best templates to help organizations reach that goal is “Building Security In Maturity Model” (BSIMM) by Synopsys, an annual report that tracks the software security initiatives (SSIs) of dozens of companies (the latest had 130), primarily in nine verticals. In the section on the “software environment,” the BSIMM found that the SSIs of companies with maturing levels of security included:
    • Monitoring application input. This helps an organization spot attacks. For web code, a web application firewall can do this job, while other kinds of software likely require other approaches, including runtime instrumentation.
    • Ensuring host and network security basics are in place. As the report puts it, “Doing software security before getting host and network security in place is like putting on shoes before putting on socks.”
    • Protecting code integrity. This means attesting to the provenance, integrity, and authorization of important code before allowing it to execute. Don’t start the car until you know it’s safe to drive, so to speak.
    • Using application containers. Containers provide a convenient place for security controls to be applied and updated consistently.
    • Using application behavior monitoring and diagnostics. This means looking for misbehavior or signs of attack that indicate software-specific problems such as malicious behavior, fraud, and related issues. “Intrusion detection and anomaly detection systems at the application level might focus on an application’s interaction with the operating system (through system calls) or with the kinds of data that an application consumes, originates, and manipulates,” according to the BSIMM.

Secure your code to ensure GDPR compliance

Doing all this won’t guarantee perfect security. Nothing will. But an organization that invests in best practices to secure both its data and its software will have a pretty good chance of never hearing from the enforcement division of the GDPR or any other privacy law. It will also develop much happier and trusting customers.

All of which is good for the bottom line.

Note: Taylor Armerding is a Software Security Expert at Synopsys Software integrity Group

Leave a Comment