11 application security tweaks for a secure SDLC

A software development lifecycle's role in optimal application security can never be underrated. These tips should come handy in improving SDLC security.

History holds several examples where people have switched sides, taking internal information to the other side, and resulting in kings losing wars. Today's connected environment poses greater security challenges, since information is not just restricted to the internal corporate network, but is also available to partners and affiliates through trusted networks and business applications. While securing sensitive information and application security are crucial to organizational success, business aspects win the battle when it comes to granting access vis-à-vis security concerns. There are many examples–from financial data to source code thefts. Trust is no more a trusted word, and has a new definition – insider threat.

Information security is governed by the value of data, organization's reputation, as well as numerous compliance and regulatory laws (especially in a global scenario). To adhere to these stringent regulations and protect valuable data, security has to be engineered in the system's DNA. And the best way to ensure optimal application security is to start early in the security lifecycle.

More application security related articles
Application security should be addressed in initial SDLC stages

New evaluation criteria for Web application security scanners

9 Ways to Improve Application Security After an Incident

SDLC security is not limited to the application or network, but involves the whole environment of the application or solution. Administrative and general policies are also part of the application security picture. This is more so the case when you perform risk based evaluation of threats. Some application security risks may be mitigated in such situations, whereas others would be passed or lowered to acceptable levels by passing it to other controls.

A number of processes or tweaks can be done in the SDLC to improve an application's security posture, which we will cover in these guidelines.

1.&nbsp Know your data and data flow: There are two aspects to be considered on this front. They are:

a.  Data classification: Check the kind of data that will be handled by the application. For example, does it cover health records, credit card numbers, or any other sensitive data? These checks will help you in data classification, which further ensures that appropriate application security mechanisms are built.

b.  Data flow: Check if the application requires cross border data flow—determine where data will be processed, and where it will be stored. Are you compliant with all the laws of the land? For example, the European Union does not allow organizations to send data to locations where data laws are less stringent.

2. Compliance:  Find out all the compliance requirements applicable on your data before starting application design.

3. Privacy policy: Before designing the application, ensure that a privacy policy is in place to decide data collected from user?  Why is that needed? Who will have access to the data?

4. Threat modeling: Create misuse cases, and draw a threat model to know threats to your application's security. Draw trust boundaries wherever data flows from a lower trust zone to higher trust or vice versa.

5. Secure patterns: Choose the best application security pattern based on the results of the threat model device countermeasures. This pattern should be cost effective, as well as fit the application's architecture and system requirements.

6. Developer training: Developers typically pay attention to the functional part of the application as their priority. In order to align the developers' thought process, ensure that developers are trained in security best practices and assign equal priority to application security.

7. Centralized common frameworks: While building the application framework, ensure that common Input validation, logging, authz, authn and error handling mechanisms are built. All developers should use the same. Such a practice makes maintenance and auditing easier.

8. Automating checks at build process: The software build process can be retrofitted with automatic code scanning modules. So every time software is built, a code scan can be performed. Such automation can be performed with tools like Hudson and static analysis tools.

9. Security test cases: Ensure that misuse cases built during threat modeling are tested in the QA environment along with all the functional cases.

10. Secure components: Identify secure components from the built code, and reuse these tested components in newer applications.

11. Configure deployment environment: Application security also depends on security of the deployed environment. Ensure securing and patching of servers, the underlying OS, and data connectivity.

Though these SDLC security tweaks do not make up the complete set of measures to ensure a secure end product, it can be used by developers to enhance their application's security posture to a great extent.

About the author: Plash Chowdhary has been associated with the Tata group for over five years in various roles ranging from developer to infosec consultant. Currently, he leads a team in application security domain for a client.  Chowdhary is an active volunteer member of OWASP India, and has presented his talks at various local OWASP events.

Read more on Application security and coding requirements

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.