Mitiget is an integrated business risk solutions and IT assurance provider. We assist organisations in mitigating the risks associated with internal systems, business processes, projects, applications, data and third-party reliance. Our cybersecurity and data centre services are the most cost-effective in our space today. Mitiget’s ISO certification processes are tailored to embed relevant culture to business processes for continual improvement. We are experts at improving compliance postures across industries.
“Use software application security testing (SAST) and security development lifecycle (SDL) to make sure that applications are not leaking sensitive details and are processing untrusted input correctly.” – — Gartner
Businesses enable their strategies using applications that run over networks. Many are even developing their own apps, in addition to purchasing apps as well as incorporating open source codes into their apps. Whichever approach that suits the business; there are significant risks to grapple with in these days. Hence, application security is no longer optional; it has become an absolute necessity.
Application security is the use of software, hardware, processes and people to protect applications from external threats. Suffice it to say that deliberate security controls built into applications will minimize the likelihood that unauthorized code will be able to manipulate applications to access, steal, modify, or delete sensitive data.
According to Verizon’s 2014 Data Breach Investigations Report, web applications “remain the proverbial punching bag of the internet,” with about 80% of attacks in the application layer, as Gartner stated. The 2015 Verizon Data Breach Report also 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. In 2013, the Ponemon Institute’s ‘Cost of a Data Breach Report’ found that security incidents in the U.S. averaged a total cost of $5.4 million. Preventing just one similar security incident would more than cover the cost of application security and prove your security programs value. Application Security is built around the concept of ensuring that the code written for an application does what it was built to do, and keeps the contained data secure. According to Gartner, application security puts a primary focus on three elements:
- Reducing security vulnerabilities and risks
- Improving security features and functions such as authentication, encryption or auditing
- Integrating with the enterprise security infrastructure
While we consider applications are considered a piece in the production environment, software is considered a test and development environment piece. 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. Software development life cycle (SDLC) should be adopted to ensure that any software is built securely.
Securing Application Components
Most business application are linked to data, other applications, services and even users. For instance, 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. A user sometimes, initiate such transitions. Since software doesn’t recognize sensitivity or confidentiality of data that it is processing or transmitting over the Internet, it ought 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. 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)
- IP filtering
- Lock down executables
- Monitoring of programs at runtime to enforce the software use policy
Building Security In Maturity Model (BSIMM) – A Guide
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.
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 behavioural 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
- 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.
Network Security – A second level for apps
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
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.