The terms ‘application security’ and ‘software security’ are often used interchangeably. However, there is in fact a difference between the two. Information security pioneer, Gary McGraw, maintains that application security is a reactive approach, taking place once software has been deployed. Software security, on the other hand, involves a proactive approach, taking place within the pre-deployment phase.
To ensure that a piece of software is secure, security must be built into all phases of the software development life cycle (SDLC). Thus, software security isn’t application security—it’s much bigger.
As you may know, applications are links between the data and the user (or another application).
When a user wants to conduct a complex analysis on a patient’s medical information, for example, it can be performed easily by an application to avoid complex, time-consuming manual calculations. Similarly, an online bank transaction is performed through web-based applications or mobile apps, and non-public financial data is processed, transmitted, and stored in this process.
Software doesn’t recognize sensitivity or confidentiality of data that it is processing or transmitting over the Internet. Thus, software needs to be designed and developed based on the sensitivity of the data it is processing. If data is classified as ‘public,’ then it can be accessed without requiring the user to authenticate. One example is information found within a website’s contact page or policy page. However, if the software performs user administration, then a multi-factor authentication method is expected to be in place to access this information. Based on classification of the data being processed by the application, suitable authentication, authorization, and protection of data in storage or transit should be designed for the application in addition to carrying out secure coding.
To protect the software and related sensitive data, a measurement should be taken during each phase of the SDLC. This measurement broadly divides issues into pre and post-deployment phases of development. Again, software security deals with the pre-deployment issues, and application security takes care of post-deployment issues.
Web applications are most often client-server based applications in which the browser acts as client, sending requests and receiving responses from the server to present the information to the user. Therefore, web application security concerns are about client-side issues, server-side protections, and the protection of data at rest and in transit.
Server-side components can be protected by implementing countermeasures during the design and coding phases of application development. This requires that secure system/server software is installed. An obsolete server software such as Apache Tomcat (3.1 and prior) are no longer officially supported and there may be unreported vulnerabilities for these versions. These should be immediately upgraded to the latest version.
Mobile systems such as smart phones and tablets that use varied operating systems and security designs are more prevalent than web applications these days. These devices, and the applications running on these devices, may pose tremendous risks for the sensitive data they store. Business emails and personal contacts may be exposed to untrusted networks. These applications also interact with many supporting services. Devices can be stolen. Malware can be installed. Mobile apps can be reverse engineered to access sensitive corporate data. These are just a few of the possibilities. Additionally, some marketing applications running on mobile devices can collect personal or professionally sensitive information like text messages, phone call history, and contacts.
Mobile applications should be designed with built-in capabilities of Root/Jailbreak detection, tamper resistance against reverse engineering, multilayer authentication leveraging voice, fingerprinting, image, and geolocation. Not to mention that they should follow secure coding guidelines.
Application stores for different mobile device vendors use different security vetting processes. It’s important to make sure applications aren’t corrupted during the distribution process. Tamper resistance is particularly important at this phase.
Devices on which these applications run use their own systems’ software and may be configured in an insecure way. Device configurations related to application code protection, root/malware detection, authentication, and channel verification should be performed following mobile device configuration standards. It is not only the application that’s important to note here; the mobile software also needs to be designed considering all these possibilities and configured in a secure manner.
Implementing security measures in mobile applications are more difficult when compared to web applications. Measures such as code obfuscation and tamper detection (to avoid tampering of code) are required in mobile applications more than in web applications.
Testing is intended to detect implementation bugs, design and architectural flaws, and insecure configurations. Here are some effective types of application security testing:
That being said, it’s important to note that application security is only one of many domains in software security.
As seen within the two scenarios presented above, application testing in the post-deployment phase of web and mobile applications are different in many ways. Mobile applications are more prone to tampering than web applications. Additionally, the security of mobile device hardware is a major factor in mobile application security.
There is common misconception about software security that peripheral countermeasures such as firewalls are good enough to limit the execution of an application or the handling of data by specific apps. Businesses are spending a great deal to have network security countermeasures implemented (such as routers that can prevent the IP address of an individual computer from being directly visible on the Internet).
The 2015 Verizon Data Breach Report shows only 9.4% of web app attacks among different kinds of incidents. An organization’s software security initiative (SSI) should look beyond application security and take holistic approach—looping in all types of software.
[tweetthis remove_hidden_hashtags=”true”]#Appsec and #Swsec are often used interchangeably. However, there’s a BIG difference. Here’s why:[/tweetthis]
Designing and coding an application securely is not the only way to secure an application. The infrastructure on which an application is running, along with servers and network components, must be configured securely. For an application to be as secure as possible, the application and server configurations, transmission encryption, storage of authentication credentials, and access control to the database where credentials and encryption keys are stored should all be taken into account.
Software, and the infrastructure on which software is running, both need to be protected to maintain the highest level of software security. This involves both software security (in design, coding, and testing phases) and application security (post deployment testing, monitoring, patching, upgrading, etc.). Software security involves a holistic approach in an organization to improve its information security posture, safeguard assets, and enforce privacy of non-public information; whereas application security is only one domain within the whole process.