IT applications are akin to the organization's blood vessels because they carry critical information and execute key processes. However, due to a peripheral approach to security, application security is often neglected.
Applications require strong embedded security to prevent breaches. Hence enterprises should start to address security at the software development lifecycle's (SDLC) early stages. There are several ways to go about this.
Education: Because business users or customers are often unaware about security risks, developers and the application architect should be familiar with possible security threats and application attacks. These personnel should inculcate the application security culture throughout the lifecycle.
If you estimate risk correctly from the beginning, it will also help you to save on costs. According to an industry statistic, if the cost of fixing a bug at design phase is X, post the release it would cost 60X. The cost of fixing bugs increases during each stage of application development. Developers can be trained on dummy applications to help them learn how attackers operate.
Build a threat model: A threat model for your application is essential to identify the involved risks, possible attack scenarios, controls and risk mitigation costs. To start, you should understand the application's utilization. You can categorize an application based on usage (internet or intranet), data sensitivity (sensitive or non-sensitive) and the technology used (web based or non-web based application). These parameters help you categorize the application security level as high, medium or low. Based on this classification, security controls are integrated during the application design process.
It is important to understand application priorities in terms of uptimes and security. For example, we were developing a financially sensitive application for a telecom company. It was essential to monitor the application for any kind of intrusion wherein an hour's downtime could lead to loss of millions (of British pounds). In this case, we designed a system which sends an email to the administrator even if the application went down for a minute.
Compare this to another defense application (a thick client with no HTTP data). Here, the application design was completely different because the servers had to be shut down immediately in case of an intrusion. In both cases, the applications are sensitive, but their uptime requirements are different. In the first case, uptime is more of a priority, while security is given more priority in the latter.
There are common attacks that are known to subject matter experts of security, on the basis of which the expert decomposes the application. He designs application metrics that define user access and data sensitivity at various levels. These metrics are known as create, read, update and delete (CRUD). Certain companies include the threat model as an important document while signing a contract with the third party developer.
Application's security requirements: Data validation and data security are the most common application security requirements. So the application should validate whether to process data sent by the user.
Data validation mainly defines controls for the type of data and information that can be processed by the application. It is an exercise to ensure that the attacker does not have any points where he can bypass security measures. Data security is another requirement. The data has to be encrypted based on the sensitivity level.
Secure coding: It is necessary to establish secure coding practices among developers through guidelines and awareness campaigns. Specific techniques are readily available to write secure code on different technologies. The organization can also purchase automatic code review tools to ensure security.
Although it has become fashionable among enterprises to go for automatic code review, it is not mandatory. After all, it is a cost preposition. It is foolish to spend Rs 5 on data security if the value of data is only Rs 2.
Application security testing: Security testing is basically about analyzing the use cases and misuse cases, which are identified during the threat modeling phase. Apart from this, the application can be tested against possible attack checklists that are regularly issued by consortiums like the open web application security project (OWASP) and web application security consortium.
Deployment level checks: It is observed that a production environment is quite different from the development environment. Some of the configuration checks on this front include missing patches and updates, unhardened OS, debugging and trace enabled, backup or old files present, etc.
Maintain: Once an application goes live, several changes are added to the application based on user demand. The security team must find these application changes and test them for vulnerabilities. Periodic checks also help you test the application against new security vulnerabilities.
The application's security audit can be performed based on application sensitivity. High business impact applications should be verified for security gaps every two months, while non-critical applications can be checked annually.
About the author: Dharmesh M Mehta is a technical analyst for the technology engineering and consulting group of Mastek Ltd. Mehta is involved in application security consulting and establishing application security across the SDLC. He also conducts security workshops for the developer community. Besides his interests in application security, he likes performance testing and tuning of web applications.
(As told to Dhwani Pandya.)
