The Norwegian Data Protection Authority (DPA) recently announced a €200,000 fine against Oslo's municipal education agency for several security flaws associated with an app the agency developed for communications between school employees, parents and pupils. At first, this may seem like an obscure case of only local importance, but the DPA's rationale for the fine carries three important takeaways for all app developers about app security and privacy by design.
Design apps to discourage collection of unneeded sensitive data
The agency's app was designed so parents could send messages to the school about their children's absences. It included a free-text field for the communication, and the DPA found this design was likely to cause parents to input information about children's illnesses, which is special-category personal data under Article 9 of the EU's General Data Protection Regulation (GDPR). The DPA faulted the agency for failing to implement technical measures to prevent entry of this information or to include a warning in the app to not include this information. The DPA suggested that the app could have been designed with drop-down lists and tick boxes to prevent entry of sensitive data in free-form text fields.
Key takeaways: The DPA's concern is well founded. In the breach investigations we conduct, we routinely find sensitive and unexpected data in free-form text fields. These unstructured data are not only difficult to search and catalog in a breach investigation, but may contain some of the most sensitive and problematic data that triggers breach notifications. The Norwegian DPA identified the unnecessary use of free-form fields in this app's context as violating data-protection-by-design-and-default (DPbDD) principles. To avoid these issues, app developers should:
- Avoid free-form fields when possible – and especially when context increases the likelihood that users will input sensitive data. Opt instead for drop-down lists, check boxes or other technical measures that limit a user's ability to input unwanted and unexpected sensitive data.
- Where free-form fields must be used, include a warning to discourage users from entering sensitive data in these fields. As a backstop, use a tool to regularly search databases for unexpected and unwanted sensitive data. Scrub unwanted data from the database and, if the searches reveal ongoing collection of unwanted data, consider new technical controls to limit the collection.
- Apply these controls to both internal and customer-facing applications. Internal systems, like public-facing applications, should limit employees' ability to capture unwanted sensitive data in free-form fields, especially for internal apps designed to capture information on interactions with customers and consumers.
Design apps to detect and prevent unauthorized logins
The DPA alleged that the agency's app was designed with poor login security, which allowed unauthorized actors to access and alter personal data of more than 63,000 students.
Attacks against public-facing web applications are a well-known and significant problem, fueled by the public release of billions of username and password combinations stolen during breaches at many organizations over the years and by users' propensity to share passwords across many sites. Armies of automated "bot" networks or, sometimes, human actors in low-income nations use these stolen credentials to obtain unauthorized access to applications around the globe.
Key takeaways: Although unauthorized account access is often caused by users' poor password hygiene, these attacks are frequent enough that many global DPAs (including in the U.S.) believe organizations bear some responsibility to detect and prevent them. As part of their DPbDD process, organizations should assess the risk of their applications for unauthorized access and, based on risk, consider implementing authentication and other controls, including these:
- Implement multifactor authentication (MFA) for user access. Depending on the assessed risk, the MFA control may be mandatory, optional or risk-based (that is, MFA is required when suspicious login activity crosses a certain risk threshold).
- Protect applications with a web application firewall to mitigate bot traffic. Use secure coding practices for the app, and assess the app using standards like the OWASP (Open Web Application Security Project) Top 10 to avoid common vulnerabilities (including in authentication and application programming interface controls).
- Help users identify malicious activity in their accounts by (1) notifying users of important changes to an account (e.g., when a password or shipping address is changed or a new payment method is added) and (2) developing a protocol for notifying customers of account takeovers (e.g., prepare template notification emails).
Implement adequate security testing before releasing an app to production
The DPA also alleged that the app contained well-known security vulnerabilities because the agency failed to adequately test the app before launching it.
Security testing is a critical part of a secure software development life cycle, yet too many organizations delay testing until well after an application is launched to production.
Key takeaways: Developers should build secure coding practices into developing any new application. Consider that even an app designed to process no sensitive data can become an open door to the network it sits on if deployed with critical vulnerabilities. All apps, whether developed in-house or by third-party developers, should undergo the following testing:
- Static analysis to identify common vulnerabilities in the application's code.
- Dynamic analysis to identify vulnerabilities that reveal themselves only as the code is being executed.
- Application penetration testing to identify additional errors, including logic errors, that may allow an attacker to access data or use the application as a door to the underlying system and network.
To do this effectively, organizations must (1) build security testing time and budget into the development process and (2) support security testing from the top down. It will introduce additional – but necessary – time to the development process.
Evaluate your organization's privacy and security governance
At a strategic level, these recommendations all roll up into strong privacy and security governance. Ideally, an organization will address these issues as part of the activities of a data-protection steering committee (or equivalent body) that evaluates and monitors privacy and security risks across the organization and in new initiatives at the design phase.
The content of this article is intended to provide a general guide to the subject matter. Specialist advice should be sought about your specific circumstances.
We operate a free-to-view policy, asking only that you register in order to read all of our content. Please login or register to view the rest of this article.