Secure Coding Practices

Secure Coding is the practice of developing computer software in a way that guards against the accidental introduction of security vulnerabilities. By identifying the insecure coding practices that lead to these errors and educating developers on secure alternatives, organizations can take proactive steps to help significantly reduce or eliminate vulnerabilities in software before deployment. Defects, bugs and logic flaws are consistently the primary cause of commonly exploited software vulnerabilities.  Through the analysis of thousands of reported vulnerabilities, security professionals have discovered that most vulnerabilities stem from a relatively small number of common software programming errors.

Generally, it is much less expensive to build secure software than to correct security issues after the software package has been completed, not to mention the costs that may be associated with a security breach. Securing critical software resources is more important than ever as the focus of attackers has steadily moved toward the application layer.

Secure coding practices must be incorporated into all life cycle stages of an application development process. The following minimum set of secure coding practices should be implemented when developing and deploying covered applications:

Formalize and document the software development life cycle (SDLC) processes to incorporate major component of a development process:

—>>Architecture and Design

While there is no campus standard or prescriptive model for SDLC methodologies, the resource proprietor and resource custodian should ensure the above major components of a development process are defined in respect to the adopted development methodology, which could be traditional waterfall model, agile or other model.

1. Perform automated application security testing as part of the overall application testing process. See Relevant Campus Services for details of automated application security testing service offered by ISP.
2. Integrate secure coding principles into SDLC components by providing a general description of how the secure coding principles are addressed in Architecture and Design documents.
3. If a secure coding principle is not applicable to the project, this should be explicitly documented along with brief explanation.
4. Development and testing environments should redact all sensitive data or use de-identified data.

Top 10 Secure Coding Practices

1. Architect and design for security policies. Create a software architecture and design your software to implement and enforce security policies. For example, if your system requires different privileges at different times, consider dividing the system into distinct intercommunicating subsystems, each with an appropriate privilege set.

2. Heed compiler warnings. Compile code using the highest warning level available for your compiler and eliminate warnings by modifying the code. Use static and dynamic analysis tools to detect and eliminate additional security flaws.

3. Validate input. Validate input from all untrusted data sources. Proper input validation can eliminate the vast majority of software vulnerabilities. Be suspicious of most external data sources, including command line arguments, network interfaces, environmental variables, and user controlled files.

4. Default deny. Base access decisions on permission rather than exclusion. This means that, by default, access is denied and the protection scheme identifies conditions under which access is permitted.

5. Sanitize data sent to other systems. Sanitize all data passed to complex subsystems  such as command shells, relational databases, and commercial off-the-shelf (COTS) components. Attackers may be able to invoke unused functionality in these components through the use of SQL, command, or other injection attacks. This is not necessarily an input validation problem because the complex subsystem being invoked does not

6. Keep it simple. Keep the design as simple and small as possible. Complex designs increase the likelihood that errors will be made in their implementation, configuration, and use. Additionally, the effort required to achieve an appropriate level of assurance increases dramatically as security mechanisms become more complex.

7. Adhere to the principle of least privilege. Every process should execute with the the least set of privileges necessary to complete the job. Any elevated permission should be held for a minimum time. This approach reduces the opportunities an attacker has to execute arbitrary code with elevated privileges.understand the context in which the call is made. Because the calling process understands the context, it is responsible for sanitizing the data before invoking the subsystem.

8. Practice defense in depth. Manage risk with multiple defensive strategies, so that if one layer of defense turns out to be inadequate, another layer of defense can prevent a security flaw from becoming an exploitable vulnerability and/or limit the consequences of a successful exploit. For example, combining secure programming techniques with secure runtime environments should reduce the likelihood that vulnerabilities remaining in the code at deployment time can be exploited in the operational environment.

9. Adopt a secure coding standard. Develop and/or apply a secure coding standard for your target development language and platform.

10. Use effective quality assurance techniques. Good quality assurance techniques can be effective in identifying and eliminating vulnerabilities. Fuzz testing, penetration testing, and source code audits should all be incorporated as part of an effective quality assurance program. Independent security reviews can lead to more secure systems. External reviewers bring an independent perspective; for example, in identifying and correcting invalid assumptions.

 Here are some of the companies that provides guidelines for secure coding :

SecureLayer7 Core-Security-logo-190 strativia logo_websec