Four application security tips for your software development lifecycle

Software development lifecycles typically don't factor in application security. These four application security tips for should prove handy on this front.

Application security is an integral part of software development projects, which directly impacts corporate and customer confidence. Security needs to be integrated throughout the software lifecycle — right from requirement analysis and release, all the way to retirement of the application. In this context, these four tips should be kept in mind on the application security front.

Tip 1: Define application security standards

Your organization must establish clearly defined application security standards, which incorporate the fundamental concepts of confidentiality, integrity and availability (CIA). These standards should be complemented by suitable procedures and patterns, since development teams rarely get the time to read policies.

Tip 2: Address the fundamental information security concepts

Besides addressing CIA, there are other equally important application security fundamentals that you need to keep in mind. These six application security basics are: authentication, authorization, auditing, session, exception, and configuration management. Auditing is particularly significant on these fronts, since it works as a deterrent and a detection control.

Tip 3: Inculcate security across the SDLC

The retirement of legacy applications is an oft ignored aspect of application security. After identifying vulnerabilities, you may need to re-architect legacy applications. Companies usually don't have enough subject matter knowledge and documentation related to a legacy application. In such cases, you must reverse-engineer the compiled codebase to arrive at software design. If there is no possibility of re-architecting, you may have to fall back on patching the software. As far as possible, it's best to avoid the patch and release cycle.

Companies usually don't have enough subject matter knowledge and documentation related to a legacy application. In such cases, reverse-engineer the compiled codebase to arrive at software design.
,

Tip 4: Write defensive code

Keep the acronym "INSECURE" framework in mind when trying to write defensive code. INSECURE spells out to the following aspects.

Inject-able code: Different kinds of injection attacks like SQL, LDAP, OS command or XML attacks have one thing in common — that data is not validated before it's accepted by the system. Data validation is crucial to prevent injection attacks.

Non-repudiation: This ensures that a system or a user cannot deny an action. Auditing can ensure that non-repudiation is not exercised, due to logging of all actions.

Spoofing of code: While writing a code, the developer needs to keep in mind that it should not be vulnerable to application security threats like spoofing, tempering, repudiation, information disclosure, denial of service and elevated privilege (STRIDE).

Exception error handling: Input validation helps you to mitigate almost 70% of application security attacks. Integration of error handling with the process of sending data back to the client also ensures that there is no disclosure of the software makeup. You should ensure that errors sent to the client are laconic and non-verbose.

Cryptographically weak code: Don't try to write your own crypto algorithms. Use industry-standard tested algorithms and the advanced encryption standard (AES).

Unsafe, unused functions in code: Ensure that developers don't use banned application programming interfaces (APIs). These are unsafe and prone to buffer overflow attacks and memory issues. Banned APIs are usually published on various vendor Websites. Through code review it's possible to determine headers and libraries used by the banned APIs. In unavoidable cases, you should ensure that you at least re-architect those portions of the code.

Reversible code: Obfuscation can be used to prevent reversibility of code, as it makes the code more difficult to read. Make sure that you obfuscate the complied code at the least, before it is deployed in the production environment. You must also ensure the availability of a de-obfuscator to avoid denial of service.

Elevated privileges: While writing code, ensure that it does not have to run with elevated privileges. The development environment often lacks security controls. Hence such code usually goes into production, which is more of a restricted environment. In the haste of going live, you usually don't get time to rectify mistakes, and often end up running codes with elevated privileges.

About the author: Manoranjan (Mano) Paul is the Software Assurance Advisor for (ISC)2. His experience includes designing and developing security programs from compliance-to-coding, security in the SDLC, writing secure code, risk management, security strategy, and security awareness training and education.

(As told to Dhwani Pandya.)

Next Steps

Keep personality in mind when developoing software processes

This was last published in November 2009

CW+

Features

Enjoy the benefits of CW+ membership, learn more and join.

Read more on Application security and coding requirements

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

-ADS BY GOOGLE

SearchCIO

SearchSecurity

SearchNetworking

SearchDataCenter

SearchDataManagement

Close