It’s no longer enough to just make great software. Now, mobile-enabled, always-connected users demand applications capable of meeting them where they are — without sacrificing quality, performance, or protection. This means easy to use, intuitive software that’s always available, always secure, and always works, delivered at a fast cadence.
To meet these increasing expectations, 3rd party tools and solutions continue to be critical for development environments. Companies recognize the need to use a combination of in-house, open-source, and proprietary offerings to deliver competitive software on-demand.
At PreEmptive we’re continuously searching for ways to improve our development process, boost productivity, and drive best-of-breed software design. But we’re not selfish — in the spirit of the season, we’re happy to share some of our favorite tools for software development and design.
In 2017 and again in 2018, PreEmptive Solutions surveyed over 15,000 professional developers asking about their organization’s current and projected use of a broad cross-section of development languages and frameworks.
Evaluating each annual survey result on its own and again together as a whole offers insights into current practices, assumptions about future trends as well as the actual trends that played out during the time between the two survey collection points.
The white paper, Multi-Year Developer Survey Reveals Evolving Practices and Foreshadows Further Change shows a professional development community striving to reduce the number of languages and frameworks they rely upon while simultaneously increasing their commitment and investments in the technologies they retain. As this maturation occurs, overall clarity and confidence in their architecture and mission improves.
All apps are vulnerable. That’s the takeaway from a recent Trustwave report, which found that 100 percent of web applications could be compromised in a cyberattack. Combined with the uptick in mobile malware, account takeover fraud and blockchain-based attacks, companies spend most of their time fending off new attacks while trying to keep current apps up and running.
The result? It’s easy to assume that when applications aren’t directly under attack, they’re effectively safe. The truth? More code handling more data increases the risk of “leaky apps” — applications which unwittingly expose sensitive data to prying eyes.
Here’s how you plug the holes.
In its recent GitHub $7.5B acquisition announcement, Microsoft promised to “bring its developer tools and services to new audiences.” “New audiences” in this context mean, quite literally, GitHub’s 28 million developer users. As the “largest open source community in the world,” GitHub audiences will most surely also mean new requirements, new priorities, and new expectations – but these will also come with old biases. And there is no better example of open source bias than code obfuscation.
For the typical open source developer, obfuscation is “like a pearl onion on a banana split” – it simply does not belong (with thanks and apologies to Philip Marlowe in Raymond Chandler’s The Long Goodbye).
The argument is simple enough – there is no reason to prevent the reverse engineering of open source applications because the source code is already public. It’s like picking an unlocked door.
I am not a superstitious person and I don’t believe in magic, but even still – I have to confess that the way Xamarin spits out Android and iOS apps (along with all the other platforms) feels kind of magical to me. Of course, when something breaks, I am reminded all too quickly that there is no magic happening here – Xamarin has just encapsulated a lot of complex steps into a neat and tidy black box.
For me, and I bet I am not alone here, I am very happy to leave that black box alone – and I am also happy to ignore as much of the platform-specific details as I possibly can.
Unfortunately, when it comes to security, there are platform-specific issues that simply cannot be ignored.
How important is root detection?
- Rooted devices can be extremely dangerous: When running on a rooted device, an otherwise harmless App can unmount file systems, kill processes, or run any arbitrary command.
- Rooted devices are plentiful: In the annual Android Security 2017 Year in Review, Google reported that its SafetyNet service identifies over 14 million rooted devices DAILY.
- Sensitive applications must include controls to mitigate these risks: Recent PCI Security Council guidelines and NIST controls are just two notable examples where rooted device detection and response obligations are explicitly assigned to development organizations. More generally, rooted access is synonomous with unauthorized privilege escalation and is, therefore, incorporated by reference in virtually every privacy obligation developers face, e.g. GDPR, HIPAA...
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?