Security is a growing concern as the number of mobile devices such as smart phones, tablets, gaming devices and other devices which are run with embedded software
Hardening your application
Certainly, there are many tools and techniques used to address security. In Security Lesson: Beating Web application security threats, Kevin Beaver discusses tools such as vulnerability scanners and static analysis tools that can be used to protect your Web applications.
But often that’s not enough.
Bob Walder, Research Director at Gartner, says:
As security attacks become more financially motivated, and as organizations get better at securing their networks, desktops and server infrastructures, there has been a shift in attacks to the application level. To address these new risks, enterprises must modify their application development (and procurement) processes so that, ideally, application security defects are detected and remediated prior to deployment of the application.
Thus, this is not just about anti-piracy measures for developers, but also about protecting enterprises against subverted applications (inserting Trojan code, for example) -- either their own applications or those purchased from ISVs.
Application hardening and shielding products provide protection for an organization's software-based assets (especially those placed on machines, sites and locations that the organization doesn't control) from tampering, reverse engineering and attacks. They can also provide several types of application-level security without requiring developers to natively modify source code.
Application hardening tools are those tools designed to protect your code from hackers by using techniques of obfuscation, encryption or authentication. You want to look for a product that will ward against tampering, piracy, reverse-engineering, malware insertions and unauthorized use.
With these types of tools, security is injected into your code, specifically with the purpose of detecting and preventing application-level intrusions.
Defending against attacks
Obfuscation is used to hide structure and code flow within an application. By modifying the original code or inserting new code that will disguise the original code, the hacker will be unable to reverse engineer or tamper with the original source code.
Gartner’s Walder says this of hardening tools:
At their most basic level, the technologies include obfuscation tools to protect the application code as the increasing use of intermediate language representations (such as Java and .NET) enables hackers to easily reverse-engineer intellectual property (IP) embedded in software.
More advanced capabilities include the ability to inject security protection directly into the application without requiring developers to modify the source code. This can be applied proactively (for example, obfuscating the application to protect against and alert for tampering, or implementing the type of input filtering that the developers should have written to protect against exploits) or reactively (injecting protection as a result of a vulnerability discovered in production, or performing some predetermined action based on exploitation attempts).
This set of technologies captures two diverse needs. Code obfuscation is the more widely adopted and more mature method of protecting applications, but estimated adoption rates are still in the high single digits, because most organizations are unaware of its benefits until they directly experience the theft of IP or an attack from an application compromise. Furthermore, for application protection techniques that rely on the insertion of code, development organizations may be reluctant to allow the injection of new code into an application from a source other than a developer.
Authentication and attack detection
Checksum is used as a way of detecting the integrity of an application and its data. A procedure is used that will yield a “checksum” from data. Then when that data is transmitted, the checksum algorithm can be run again to ensure the data was not altered, either accidentally or intentionally. Variants to checksum functions are hash functions, fingerprints, randomization functions, cryptographic hash functions and digital signatures. Though related, each of these has its distinct uses and priorities.
This is a technique of detecting tools used that might be used by hackers to compromise data. Security schemes that use anti-debug may block the application from executing if tools such as a kernel-mode debugger are present.
Though this may prove somewhat beneficial, in his post, Anti-debugger techniques are overrated, Nate Lawson warns not to depend simply on anti-debug techniques in your protection scheme.
The reality is that they are either too simple and thus easy to bypass or too specific to a particular type or version of debugger. When designing software protection, it’s best to build a core that is resistant to reverse-engineering of all kinds and not rely on anti-debugger techniques.
Alert and react to attacks
You need tools to defend from attacks and detect when code has been attacked. A third area you want to look for in your protection tool is how it reacts when an attack is discovered. Is it able to repair the tampered code with the original code? What errors are produced when attacks are detected? Is there capability to send alerts to the appropriate people?
Mobile and embedded software
With the vast number of mobile devices and applications, downloads number in the billions and unprotected code is a prime target for hackers intent on stealing intellectual property.
According to Charles Kolodgy, Research Vice President of Secure Products at IDC:
I don't see much difference in the protection profile required for standard web applications and those of mobile applications. The key is what kind of manipulation of the software can occur that will result in attackers being able to use an application as an avenue to collect information that they can then use for monetary gain. The real problem with mobile applications is that there are so many of various quality levels that it is difficult to know what is a good application and what might have been created to gain a foothold on your device.
Though embedded software running on specialized devices is not at as high of a risk, due to less consumer exposure, it still can be very important to protect the intellectual property. Biometric devices and military devices are two examples of embedded software which require a high level of protection.
Kolodgy notes the growing concern for increased security throughout the SDLC:
There is a growing appreciation that applications need to be developed in a secure manner. There are beginning to be requirements, from the government but also from industry (see PCI/DSS) that are requiring that software be tested against a minimum level of security. Security testing is being integrated into the SDLC.
This was first published in January 2011