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.
Application security as subset of software security
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.
Software security (pre-deployment) activities include:
- Secure software design
- Development of secure coding guidelines for developers to follow
- Development of secure configuration procedures and standards for the deployment phase
- Secure coding that follows established guidelines
- Validation of user input and implementation of a suitable encoding strategy
- User authentication
- User session management
- Function level access control
- Use of strong cryptography to secure data at rest and in transit
- Validation of third-party components
- Arrest of any flaws in software design/architecture
Application security (post-deployment) activities include:
- Post deployment security tests
- Capture of flaws in software environment configuration
- Malicious code detection (implemented by the developer to create backdoor, time bomb)
- Patch/upgrade
- IP filtering
- Lock down executables
- Monitoring of programs at runtime to enforce the software use policy
Solution
Building Security In Maturity Model (BSIMM)
Review the Building Security In Maturity Model (BSIMM) activities for more guidance..
Scenario #1: Web application security
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.
Client-side issues are more difficult to fix unless precautions are thought of while designing the user interface. One example is DOM-based cross-site scripting in which a DOM object value is set from another DOM object that can be modified using JavaScript. Modern browsers are more protective of applications, but many applications still support backward compatibility to include a wider range of users, older versions of browsers, and insecure client computers. Therefore, client-side components need to implement security in the design phase when considering these issues.
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.
Other common infrastructure security vulnerabilities include:
- Verbose server banner
- Caching of pages allowed to store data locally and in transit
- Weak cipher suites supported by server
- Internal network addresses exposed by the cookies
- Cookie security
Scenario #2: Mobile application security
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.
Risks factors in mobile-based software include:
- Application coding
- Application distribution
- Application configuration
- Device configuration
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.
Types of application testing
Testing is intended to detect implementation bugs, design and architectural flaws, and insecure configurations. Here are some effective types of application security testing:
- Static application security testing (SAST) focuses on source code.
- Dynamic application security testing (DAST) focuses on the detection of vulnerabilities present in the application and infrastructure.
- Interactive application security testing (IAST) uses combination of both DAST and SAST, and performs behavioral analysis to detect data flow, input/output, etc.
- Runtime application self-protection (RASP) enables applications to protect themselves using application runtime engine security features such as session termination, application termination, failure notification, etc.
That being said, it’s important to note that application security is only one of many domains in software security.
Software risks include:
- Web/non-web application/infrastructure
- Insecure design
- Misconfigurations
- Limitations of technology
- Transmission encryption
- Back-end database 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.
Where does network security fit into all of this?
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).
Other common countermeasures include:
- Conventional firewalls
- Encryption/decryption programs
- Anti-virus programs
- Spyware detection/removal programs
- Biometric authentication systems
- Data analysis and data loss prevention tools
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.
Application security vs. software security: Summing it up
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.
Continue Reading
