Contact Us Blog Register Login
PreEmptive -
  • Home
  • Products
    • Application Protection
      • Dotfuscator for .NET
        • Overview
        • Features
        • Compare Editions
        • Xamarin Protection
        • Videos & Resources
        • Pricing
        • Downloads
      • DashO for Android & Java
        • Overview
        • Features
        • Videos & Resources
        • Pricing
        • Downloads
      • JSDefender for JavaScript
        • Overview
        • Features
        • Online Demo
        • Pricing
        • Downloads
      • PreEmptive Protection for iOS
        • Overview
  • Support
    • Product Support
      • Dotfuscator for .NET
      • DashO for Android & Java
      • JSDefender for JavaScript
      • PreEmptive Protection for iOS
    • Resources
      • White Papers
      • Glossary
      • Videos
  • Solutions
    • App Protection Solutions
      • Mobile App Protection
      • Desktop & Server App Protection
      • General Data Protection Regulation (GDPR)
      • Security Development Lifecycle
      • Application Integrity Protection
      • Mobile RASP
      • PCI Mobile Payment Acceptance Security
  • Company
    • About
      • Why PreEmptive?
      • About Us
      • Careers
      • Blog
    • Contact
    • Legal

App Security: It’s a New Year! What’s New About It?

February 11, 2020 1798 Views Bill Leach


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.

  1. 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.

  2. 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:

  1. 23 NYCRR 500 CYBERSECURITY REQUIREMENTS FOR FINANCIAL SERVICES COMPANIES Third Party Service Provider Security Policy

    While 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.

  2. PCI Security Council Secure Software and Secure Software Lifecycle Frameworks and Templates

    In 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.


Start a Free Trial

Tweet
Share

Categories

  • Dotfuscator

  • Dotfuscator CE

  • DashO

  • JSDefender

  • Press Releases

  • Mobile Protection

  • Risk Management

  • Support Corner

Latest Blog Posts

Protecting Java applications that use Jackson for JSON



JSON is a standard format for sharing objects and data within an application. When working in Java, there is no built-in support for JSON processing. There are, however, several widely-used libraries and options to choose from. In this article, we will focus on Jackson, which is one of the most popular.

Read more

Protecting C# applications that use AutoMapper



AutoMapper is an object-to-object mapping system used by many of our customers. It aims to simplify and organize code responsible for sharing instance values from an object of one type to an object of a different type.

Read more

Inventa, Wireless Technology Company, Protects their Android Application with DashO



Inventa, a Wireless Technology Company, Protects their Android Application with DashO

The Beginnings of Inventa

Having worked in the wireless mobile technology domain in the US, Anand Virani, became intrigued by the growing tech and wireless trends and wanted to explore the field more for himself. He noticed a boom in the Internet of Things (IoT) and that smartphones were becoming more central to how people interacted with each other at home, in the office, and in public places. What if there was a way phones could connect with each other without the need for Internet or cloud access? Smartphones were the future and Virani was determined to make a profitable business model based on this new trend.

Read more

Surgical Theater Protects their Medical Applications with Dotfuscator



Surgical Theater Protects their Medical Applications with Dotfuscator

How It All Started

How is flying a fighter plane similar to performing neurosurgery? They have more in common than you’d think. In 2005, Monty Avisar and Alon Geri, two Israeli fighter pilots were assigned to work with Lockheed Martin to build a $50 million F-16 Flight Simulator program for the Israeli Air Force to improve hand-eye coordination skills for their pilots during combat. Avisar took on the role of project manager and Geri served as senior engineer; the project was a success.

Four years later in 2009, the two finished their military service in Israel and moved to Cleveland, Ohio. Their experience working in virtual reality applications inspired them to wonder where this technology could also be applied. With several connections to surgeons, the two came to understand the ins and outs of operation procedures; in a similar way, surgeons were also working on a battlefield. What if surgeons could also train like fighter pilots and preview their surgical procedure, much like a fighter pilot could pre-fly their mission? The surgeons could pre-plan the operation from every angle and every approach to increase their situational awareness. And a year later, Surgical Theater was born.

Read more

Integrating DashO into a Maven Build



Maven is perhaps the most widely-used project management tool for Java. Based on the Project Object Model (POM), it is used not only for compilation of source code, but also dependency management, documentation, running tests, packaging, deployment, and more. We are frequently asked if we have a Maven plugin for running DashO. Though we do not offer a specific Maven plugin, adding DashO to your Maven-based project is surprisingly easy by leveraging Ant.

Read more

preemptive logo

767 Beta Dr. Suite A
Mayfield Village, OH 44143

Tel: +1 440.443.7200

solutions@preemptive.com

Latest Blog Posts

Protecting Java applications that use Jackson for JSON

December 30, 2020
Read more

Protecting C# applications that use AutoMapper

November 18, 2020
Read more

Inventa, Wireless Technology Company, Protects their Android Application with DashO

November 10, 2020
Read more

Surgical Theater Protects their Medical Applications with Dotfuscator

October 30, 2020
Read more

GlobalMed Finds Success by Switching to JSDefender

October 21, 2020
Read more

Twitter

@baldbeardbuild @GirlsWhoCode @baldbeardbuild thanks so much for inspiring us to be BUILDERS in our own community!… https://t.co/U6AyqPDhsa Jan 14 • reply • retweet • favorite

Copyright © 2020 PreEmptive

  • Home
  • Contact Support
  • Blog
  • Contact
Scroll to Top

PreEmptive uses cookies to improve the functionality of our website. By using this site, you agree to the use of cookies.