2018’s RSA Conference is in the books; IT professionals and C-suite executives are heading back to work, ready to leverage what they’ve learned and put it into practice. This year’s stand-out? The changing role of data privacy and protection regulations. Attendees made it clear that these topics were top-of-mind — hackers are finding new ways to compromise app security, even as emerging legislation puts more pressure on companies to keep data safe.The result? A sea-change for application security. Here’s what it means for your organization.
Development’s Journey to Effectively Implementing App Protection
Because data is created, accessed, and changed through applications, hardening and shielding your applications is a key component to protecting your data. Adding application protection to your secure software development lifecycle will make it more difficult for people and machines to exploit them. But, what are the factors to consider when thinking about application risk? Effective application risk management is a sustained, consistent practice and technology selection and implementation is a specialized discipline within that practice. The initial steps below offer a roadmap to selecting and implementing application hardening and shielding as a part of a broader application risk management program.
The full Infographic in pdf form is available here.
- Does app have intellectual property?
- Does app gate access to value?
- Does app access private information?
- Is the app subject to regulation?
- Does app run in an untrusted environment?
“Software is eating the world.” The now-famous quote by technology expert Marc Andreessen was relevant in 2011 but seems downright prophetic in 2018 — the rise of web-based, mobile and IoT applications have created a market both massive and ever-changing. Companies know that simply staying competitive requires cutting-edge apps that both streamline the user experience and provide a steady flow of actionable data. But malicious actors also recognize the value of applications — and will do anything they can to compromise, infiltrate or damage business app networks.
It gets worse: According to the Center for Internet Security, “malspam” threats — unsolicited emails that contain malicious links or attachments — remain the number one attack vector for cybercriminals. Why? Because despite their simplicity, these attacks succeed. As noted by SC Magazine, meanwhile, 80 percent of IoT applications still aren’t tested for security vulnerabilities.
I just read the Forrester Wave™: Governance, Risk, And Compliance Platforms, Q1 2018.
Forrester reminds us all that “Risk and compliance management is more important than ever, thanks to the increasingly intangible nature of business value and the growing risk of violating customer trust.”
IT security is a hot topic, and no wonder — major healthcare, finance and government breaches have all made headlines in recent months prompting both federal agencies and compliance organizations to draft new security standards. As noted by Tech Target, regulations under Sarbanes-Oxley, PCI-DSS and HIPAA all lay out clear expectations for companies when it comes to protecting network assets, personal data and critical infrastructure.
Software, meanwhile, has historically escaped the reach of these regulations, largely thanks to the rapid uptake of mobile and web-based applications: The sheer number and type of cloud-enabled offerings and now IoT-connected software made it difficult for governing bodies and compliance agencies to define meaningful standards that improved overall security. But, just as cloud computing went through a “wild west” period of rapid expansion followed by increasing scrutiny and regulation, software and application development is now on the receiving end of emerging security regulations.
Preventing Privilege Escalation in mobile payment apps (PCI Mobile Payment Acceptance Security Guidelines Section 4.3)
Regulators, standards bodies and IT auditors have become increasingly likely to recommend an absolute prohibition of rooted Android devices in production environments. As the 2017 PCI Mobile Payment Acceptance Security Guidelines state, “Bypassing permissions can allow untrusted security decisions to be made, thus increasing the number of possible attack vectors.”
It is only natural that the apps themselves rise up to act as a ubiquitous governance, risk, and compliance management layer – preventing, detecting, responding, and reporting on threats - including those posed by unauthorized rooted devices.
When perimeters are breached, identities stolen and malware launched, encryption stands as information’s last line of defense. Without effective encryption policies, you will first be victimized and then held liable (punished) by every information stakeholder (customers, partners, investors, regulators, the courts, etc.).
Just this week, Wired led with the headline Tinder’s Lack of Encryption Lets Strangers Spy on your Swipes where they wrote in part:
“In 2018, You'd be forgiven for assuming that any sensitive app encrypts its connection from your phone to the cloud, … But if you assumed that basic privacy protection for the world's most popular dating app, you'd be mistaken.”
Java 9 is an unusually-complex Java release. It comes with deep changes to some long-held norms, compatibility-breaking changes at build time and run time, and a new release cadence. There's a lot of great stuff, but development teams face tough decisions about what to migrate, how to migrate it, and when to do so.
Here at PreEmptive, we have an especially-complex problem because our flagship Java application, DashO, runs on the Java platform, integrates deeply with the Java platform, and supports apps developed with nearly all versions and implementations of the Java platform. DashO's migration to Java 9 requires deep understanding and extensive care to ensure that DashO continues to be able to inspect, obfuscate, and inject code into apps across all those platforms, while preserving behavior, performance, stability, and portability.
So we've been hard at work on our own migration plans, and we want to share what we've learned. Hopefully this article will make your Java 9 migration planning a little easier.