Category: Risk Management

If you don’t follow application security closely, you might think of application obfuscation and symbol renaming as being synonymous – and with good reason. Many platforms and languages, like .NET, Java, and JavaScript have popular obfuscators that do little else–our own Dotfuscator Community Edition for .NET and ProGuard for Java are good examples. However, obfuscation is far more than symbol renaming – and in-app protection is far more than obfuscation. Much of this expansion has been driven by new security requirements, shifting attack vectors, the rise of mobile and IoT computing and, lastly, the growing recognition inside regulations and legislation of the exposure that can result from inadequately protected software. 

Can you tell the difference? Exception or the norm?

Of course, everyone is “for security” in principle. The hard question that each organization has to answer for themselves is “how much is enough?” Over-engineering is (by definition) excessive, and over-engineering application security can, in fact, be devastating as overly-complex algorithms, architectures and processes can compromise user experience, degrade performance and slow development velocity. On the other hand, punishment is swift for organizations that cut corners and do not effectively secure their applications, their data and, most importantly their users and business stakeholders. Finding and maintaining that balance can be time consuming and, because you can never be sure you’ve gotten it exactly right, it can also be a thankless job.

JavaScript is everywhere. It’s currently the world’s most popular programming language; as noted by GitHub, JavaScript has the highest number of contributors and repositories, handily outpacing other alternatives such as Python, PHP and Ruby.

Organizations can’t afford to leave apps unprotected. Attackers are growing more sophisticated, leveraging targeted malware campaigns and advanced evasion tactics to compromise applications and cause long-term damage.

Earlier this month, I had come across Scott Hanselman’s excellent blog post, What’s better than ILDasm? ILSpy and dnSpy are tools to Decompile .NET Code where he had shared his insights on the strengths and limitations of a laundry list of reverse engineering and debugging tools. In the comments that followed, someone had asked for an obfuscation recommendation for those times when a developer wants to protect their code against reverse-engineering (a reasonable question to be sure).

On June 11, NIST released Mitigating the Risk of Software Vulnerabilities by Adopting a Secure Software Development Framework.

Untrusted Environments, Valuable Apps? Put the Protection in the App.

IT environments are evolving. Disappearing are the days of in-house, fixed-endpoint, limited access server stacks — replaced instead by a combination of private and public cloud solutions, mobile applications and IoT devices.

As noted by research firm IDC, public cloud spending now outpaces all other IT infrastructure with a growth rate topping 10 percent year-over-year, while Statista reports that users downloaded more than 178 billion apps in 2017 alone — and are on track to break 250 billion over the next few years.

I recently had the opportunity to sit down with Sebastian Holst, PreEmptive’s Chief Strategy Officer, to talk about his most recent trip to Capitol Hill where the topic of the day was copyright protection for small businesses – and for development shops in particular.

The life of a security architect is rarely simple. Assessing, defending and improving corporate networks requires thorough knowledge of industry best practices designed to secure critical data, combined with real-world understanding of hacker tricks and tactics meant to undermine this purpose.

PreEmptive had the opportunity to send a couple of representatives to Google IO this year. IO 2019 didn’t tell us what dessert starts with a Q, but it did showcase some great tools and frameworks as well as provide insight into the direction of Android: