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 synonymous 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?
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.
This week, all eyes of the software community will be fixed on Microsoft's Build conference. Microsoft and its partners are set to announce new technologies and lay out their vision for the future of software development. Recent years have seen the narrative take a decidedly cross-platform approach. Visual Studio Code gives developers tools to create what they want no matter their OS of choice. .NET Core extends the reach of the popular .NET Framework to Mac and Linux. Finally, Xamarin, which was acquired by Microsoft in 2016, lets app developers write their app once, then publish it for Android, iOS, and Windows devices.
As a Visual Studio 2017 Premier Launch Partner, PreEmptive Solutions is pleased to announce, as part of Microsoft Build 2017, a new way to integrate Dotfuscator's protection into Xamarin apps.
Beginning with Dotfuscator Professional Edition version 4.25, you've been able to add anti-debug protections to your .NET applications, and now that Visual Studio 2017 has shipped, Dotfuscator Community Edition (CE) users have access to those protections as well.
Let's take this occasion to talk more about these new capabilities and walk through an example using both Pro and CE. Along the way, we will outline some patterns for implementation.
My earlier post, (RE) INTRODUCING DOTFUSCATOR COMMUNITY EDITION, introduced new functionality (command line interface) and updated our vision for how we hoped Dotfuscator CE adoption would evolve.
This update looks back at Dotfuscator CE adoption in 2016 and introduces the latest functionality included with the Visual Studio 2017 version.
Most of our previous blogging about Dotfuscator Community Edition (CE) assumes you are doing local builds, or have a dedicated build server—but what if you want to use Dotfuscator CE within a distributed build system such as Visual Studio Team Services (VSTS) or Team Foundation Server (TFS) on-premises? Until now, you've had to do extra work to install and provision Dotfuscator CE on each build agent host in your pool. Now, we're pleased to announce a VSTS build extension for Dotfuscator CE, available in the VSTS Marketplace. It does the extra work for you, making it easy to get Dotfuscator CE into your distributed build.