Unlike Y2K, 2020 was not preceded by waves of doomsday predictions, hype and frenetic IT overhauls. Developers are still under pressure to produce more, in less time, and at a lower cost, enterprises are as committed to their love/hate relationship with software as ever, and app users still expect perfection.
…but don’t let the usual crush of work and expectations lull you into a sense that it’s just the same old sprint to the next development project. Recent enforcement precedents, regulatory milestones and standards updates strongly suggest that 2020 app development and app security requirements will be anything but “business as usual.”
Enforcement Precedents
The best intentions notwithstanding, regulatory obligations only become relevant when they are enforced and backed up with meaningful penalties. 2019 included a number of “firsts” that suggest 2020 will bring new scrutiny to how software is developed, hardened, and secured once deployed in production. Here are two examples to consider.
- GDPR: Unicredit Bank was fined €130,000 (~$145K) for breaches of Article 25(1) for “failure to implement appropriate technical and organisational measures…” This is the first GDPR material fine levied against Article 25 – Art. 25 Data protection by design and by default mandates “appropriate technical measures” and, as the Unicredit Bank precedent establishes, EU Supervisory Authorities are enforcing this GDPR Article and assessing material fines. While the underlying infraction in this particular case was tied to document controls rather than poor coding practices, the precedent is clear, “failure to implement appropriate technical measures” will be punished. This raises the question: What constitutes an “appropriate technical and organizational measure?” GDPR Recital 78 Appropriate Technical and Organisational Measures provides a partial answer as follows: “When developing … applications, producers of … applications, … with due regard to the state of the art, … make sure that controllers and processors are able to fulfil their data protection obligations.” What are the 2019 GDPR Authorities telling 2020 developers? Failure to use secure coding practices, harden applications against attacks, detect hostile act and report and/or recover from attacks are fair game under Article 25 and, as we enter into 2020, there is now an enforcement precedent. It should also be noted that Recital 78 also encourages “the principles of data protection by design and by default” to “also be taken into consideration in the context of public tenders.” In other words, if your customers are subject to GDPR obligations, (even if your organization is not) you should expect these requirements to hit via sales requirements rather than regulatory obligations.
- FTC settled with InfoTrax for “unfair acts or practices in or affecting commerce in violation of Section 5(a) of the Federal Trade Commission Act, 15 U.S.C § 45(a).” The complaint specifically called out InfoTrax for “failure to provide reasonable security for the personal information of distributors and end consumers” by failing to
- adequately assess the cybersecurity risk posed to consumers … by performing adequate code review and pen testing of InfoTrax’s software,
- implement safeguards to detect anomalous activity and/or cybersecurity events. For example, integrity monitoring tools (tamper detection).
According to the FTC complaint, culpability (liability) stems in large part from the fact that InfoTrax “could have addressed each of the failures described by implementing readily available and relatively low-cost security measures.” So what messages are the FTC of 2019 sending the developers of 2020? First and foremost, you will be punished for breaches that might have been prevented (or minimized) by a “relatively low-cost security measure.” Tampering, reverse engineering, and hooking are just a sampling of attack vectors that can be either prevented (or at least detected) via established (low-cost) security measures. It is also worth noting that InfoTrax is a service provider whose clients are other businesses rather than consumers. The FTC has broadened its reach further “upstream” into the digital supply chain in much the same way that GDPR enforcement focuses on both data “controllers” and data “processors.” If your clients’ clients are protected by the FTC, you are subject to FTC regulatory obligations – and there is now an enforcement precedent.
Regulatory Milestones
There is an inevitable (and understandable) lag between the launch of new regulations and the first resulting enforcement actions (see the GDPR Unicredit Bank example above). However, regulatory and other governing bodies often telegraph where they are intending to focus. The following two regulations/frameworks are either newly implemented or undergoing significant revisions:
- 23 NYCRR 500 CYBERSECURITY REQUIREMENTS FOR FINANCIAL SERVICES COMPANIES Third Party Service Provider Security PolicyWhile the Cybersecurity Requirements for Financial Services Companies regulations came into effect in 2017, a key section, Third Party Service Provider Security Policy did NOT come into effect until mid-2019. In this section, any company providing financial services inside New York State (Covered Entity) must ensure that they have the “minimum cybersecurity practices required to be met by such Third Party Service Providers in order for them to do business with the Covered Entity.” Minimum cybersecurity practices include “written procedures, guidelines and standards designed to ensure the use of secure development practices for in-house developed applications …, and procedures for evaluating, assessing or testing the security of externally developed applications…” These requirements include tamper protection and compensating controls to prevent unauthorized data access when it is “in use.” What is the 2019 NY Department of Financial Services (DFS) (which regulates companies in the financial services industry) telling 2020 developers? If your customers offer financial services in New York State (if they are a 23 NYCRR500 Covered Entity) OR if your customers’ customers are covered – you will soon be required to comply with 23 NYCRR 500 requirements – not for regulatory – but for market – requirements.
- PCI Security Council Secure Software and Secure Software Lifecycle Frameworks and TemplatesIn January of 2019, the Payment Card Industry (PCI) Security Council released frameworks and assessment procedures (for auditors leading to enforcement) on both secure software development and secure software lifecycle management. In September of 2019, these two frameworks were supplemented by Templates to report on Validation for each – tools to standardize assessment, audit functions, and (potentially) enforcement. The templates include explicit references to tamper detection and defense as well as a variety of other controls that are effectively implemented via post-compile application hardening technologies (like Dotfuscator, DashO, and JSDefender). What is the 2019 PCI Security Council telling 2020 developers? If your applications are subject to PCI oversight, expect to have to demonstrate both the security of the applications you produce and the integrity of how you developed that software. Further, expect that PCI auditors to come trained and equipped with software templates to enforce a consistent set of requirements that will include a full suite of application hardening controls.
So, what’s new in 2020?
There is now a broad acceptance that, in order to be effective, cybersecurity regulations must include third party developers and service providers – as well as focus on not just what you build – but how you build it. This supply-chain perspective is now rooted in local, federal and international privacy and security regulations. All of which promise (or are already delivering) aggressive enforcement with material penalties.
