Developing software coding standards for security purposes

Pat Lowe

CPSC 6125 – Information Systems Assurance, Fall 2008 Semester

Columbus State University

November 10, 2008

ABSTRACT

Software development methods have been improved tremendously over the past few decades. Improvements in testing tools have helped organizations ensure their software meets the state requirements. Yet when it comes to ensuring security in software, the methods and tools do not meet the needs. One factor is the lack of awareness among developers of software vulnerabilities. Also, the developers may not know how to avoid the vulnerabilities. In addition, most of the security specifications are not functional and therefore difficult to describe using existing modeling tools such as UML. The testing phase may not be looking for security vulnerabilities.

In the paper “Secure Software Development through Coding Conventions and Frameworks”, Okubo and Tanaka are focusing on how to use coding conventions and software frameworks to control software security. Then they apply their recommended process to decide the proper coding conventions to prevent three types of injection attacks – SQL injection, OS command injection and XSS.

This paper will discuss expanding on the ideas of Okubo and Tanaka for developing coding conventions.

1 INTRODUCTION

Coding conventions are rules for writing program source code and are aimed mainly at making software readable and maintainable. Coding conventions can be useful for security if implemented correctly. Okubo and Tanaka focus on coding conventions that help make security testing easier even if it interferes with software code readability, maintainability and flexibility. A common part of coding convention is the use of frameworks partly provided by prewritten code in libraries. Frameworks are useful for security because developers do not have to create all security functions themselves and by providing restrictions on the way software is developed. Frameworks provide code for specific languages that are secure against common vulnerabilities.

Okubo and Tanaka outline a decision process for deciding general convention options. They recommend following these steps for each security requirement[1]:

  1. Define the security requirement
  2. Define the security specification
  3. Extract the implementation patterns
  4. Select and order by precedence the convention options
  5. Choose one or more conventions for each development project/system

While this approach is effective, I feel there are some limitations to it that should be addressed. The approach recommended does not address the use of threat models in defining the security specification. Okubo and Tanaka state that secure coding standards will reduce code readability and maintainability without discussing how this can be avoided. They do not discuss getting the developers to understand the importance of secure coding standards.

In this paper, Section 2 overviews related work. Section 3 will detail proposed solutions to address the limitations of the original paper. Section 4 provides a summary conclusion.

2 RELATED WORK

The Software Engineering Institute (SEI) has a program called CERT. According to their website “CERT is an organization devoted to ensuring that appropriate technology and systems management practices are used to resist attacks on networked systems and to limiting damage and ensure continuity of critical services in spite of successful attacks, accidents, or failures.” They provide training and publications that can be helpful for organizations setting up coding standards. CERT is working on secure coding standards for specific versions of the languages C, C++, C# and Java. Their goal is to define rules that are necessary to ensure the security of software systems developed in a specific programming language. Their standards consist of rules and recommendations to reduce security vulnerabilities. The practices that are rules meet all of the following conditions:[2]

  1. Violation of the coding practice will result in a security flaw that may result in an exploitable vulnerability.
  2. There is an enumerable set of exceptional conditions (or no such conditions) where violating the coding practice is necessary to ensure the correct behavior for the program.
  3. Conformance of the coding practice can be verified. [footnote]

Recommendations are guidelines or suggestions that meet the following conditions:[3]

  1. Application of the coding practice is likely to improve system security.
  2. One or more of the requirements necessary for a coding practice to be considered a rule cannot be met.

Organizations such as Microsoft and Sun Microsytems publish documents of secure coding standards for their specific products. For example, Sun has a document “Secure Coding Guidelines for the Java Programming Language” on their website that is a detailed guide for secure coding standards in Java. Use of these documents should be part of the process for an organization setting up coding standards. There are many books and papers available that discuss coding standards. Anyone tasked with setting up coding standards for an organization should read some of these to improve their knowledge of what is needed in secure coding standards.

3 SOLUTION

Define the security requirement:The first step in creating a set of coding conventions is the definition of the security requirements. Okubo and Tanaka do not go into much detail about how the requirements should be defined. Much like defining functional requirements, security requirements need to be specific and carefully worded. Requirements must address specific threats. To say that the system must be safe from hackers is too general. The requirements need to specify the type of attacks that could happen, such as “prevent SQL injection” or “access to the system will be controlled by userids and passwords”. Templates and guidelines for writing security requirements are available from many sources. IEEE Standard 830-1998 describes a security requirement specification (SRS) template. An online search of “security requirement specifications” returns many useful sources about how to write security requirements.

Define the security specification:When defining the security requirement and specification, security modeling should be used to describe the vulnerabilities and threats. The paper “How can the developer benefit from security modeling” by Ardi, Byers, Meland, Tondel, and Shahmehri discusses the benefits of security modeling to the developer. The use of attack trees, threat models, use and abuse cases, and vulnerability cause graphs improve the understanding of the specific security issues and assist in developing coding standards to prevent attacks and vulnerability. Attack trees model attacks and threats against a system in a tree structure using the goal of a successful attack as the root node and the different ways that goal can be reached as the leaf nodes. Threat modeling assist in understanding the threats software faces and the ways that may it may be attacked. Abuse and misuse cases can be used in determining the ways to prevent an attack and how the security functions will be tested. Misuse cases show specific undesirable behavior of a system. Normally designers and developers think about what a system should do and not what it should not do. The misuse cases document the security concerns that need to be built into the system. This can later be extended to test cases to ensure the software is secure. Vulnerability cause graphs (VCG) are graphs representing the causes of a vulnerability and their relationships. The VCG is useful in identifying which causes need to be mitigated in order to prevent the vulnerability. The use of models helps designers and developers discover the best way to mitigate security issues. The modeling techniques use may vary by organization, project, and vulnerability. [4]

Extract the implementation patterns:Okubo and Tanaka seem to believe that coding conventions for security will often reduce readability and maintainability of the code. I propose that this can be avoided by ensuring developers include adequate documentation in their code. The first step to do this is to make sure the developers understand the importance of security. Many experienced developers are still adjusting to the need for secure coding and may need formal training on the security risks that exist for an organization. Even recent graduates may not be accustomed to making sure software is secure since most school assignments focus on “what a system can do” not “what it can not do”. Security is normally viewed as something that is added on after the software is developed.[5] Training is key to secure software development since developers usually start with little security knowledge.[6]When developers understand the importance of security and think of security being as important as functional requirements they will be more willing to write readable and documented code. Also, code that is readable and documented helps in the prevention of internal security problems because it is easier to peer review and maintain. Code that is hard to understand and maintain may be inadvertently introducing other security risks.

Employees are more like to comply with security policies if they believe the policy have a purpose. Pahnila, Siponen, and Mahmood, presented a paper called “Employees’ Behavior towards IS Security Policy Compliance” in 2007. According to the paper “attitude, normative beliefs and habits have significant effect on intention to comply with IS security policies.” [7] The programming team should be involved in all steps of the development of coding conventions so they have a better understanding of the actual security threats. They also can provide invaluable assistance in developing standards that do not compromise code readability and maintainability.

Select and order by precedence the convention options:Okubo and Tanaka recommend including the following in the evaluation of proposed implementation patterns: ability to test compliance to the convention, accuracy of the testing, and possibility of conflict with other software functions.[8] In addition, I suggest that the implementation patterns be analyzed for impact on code maintainability and readability. If the implementation pattern makes the code very difficult to read and maintain, then the developers can more easily hide vulnerable code or viruses. During this step, accurate documentation needs to be kept explaining how the conventions were analyzed and ordered.

Choose one or more conventions for each development project/system: Software developers should be included in this step to verify that recommended patterns can be implemented and to analyze the impact on time needed to adhere to each standard. In this step each convention should be examined to determine the cost of testing, possibility of conflict with other software functions, and cost of implementation.

4 CONCLUSION

In conclusion, my proposed expansion on the steps in developing a coding convention are as follows:

  1. Define the security requirement being as specific as possible
  2. Define the security specification include the use of threat models in the description of the specification.
  3. Extract the implementation patterns , documenting risks and benefits of each convention in regards to impact on:
  4. Readability and maintainability
  5. Software functionality
  6. Testing ability
  7. Software performance
  8. Security improvement
  9. Select and order by precedence the convention options, documenting how the choices were made
  10. Choose one or more conventions for each development project/system

Also, developers need to be trained on the importance of secure code and involved in all the steps of developing the coding convention. People are more likely to follow the conventions if they understand the importance of them and have been involved in the process from the beginning.

[1] T. Okubo and H. Tanaka. Secure Software Development through Coding Conventions and Frameworks. IEEE Computer Society. Second International Conference on Availability, Reliability and Security (ARES’07) 10-13 April 2007, pp. 1042 – 1051.

[2] R. Seacord and J. Rafail. Secure Coding Standards. . 2007.

[3] R. Seacord and J. Rafail. Secure Coding Standards. . 2007.

[4] S. Ardi, D. Byers, P. Meland, I. Tondel, N. Shahmehri. How can the developer benefit from security modeling?. IEEE Computer Society. Second International Conference on Availability, Reliability and Security (ARES’07) 10-13 April 2007, pp. 1017 – 1025.

[5] M. Damodaran. Secure Software Development Using Use Cases and Misuse Cases. Issues in Information Systems, IACIS. Volume VII, No. 1, 2006, pp 150 -154.

[6]G. McGraw and B. Chess. Software [In]security: A Software Security Framework: Working Towards a Realistic Maturity Model. 15 October, 2008.

[7] S. Pahnila, M. Siponen, and A. Mahmood. Employees’ Behavior towards IS Security Policy Compliance. IEEE Computer Security. Proceedings of the 40th Annual Hawaii International Conference on System Sciences (HICSS’07) Jan 2007, p. 156b

[8] T. Okubo and H. Tanaka. Secure Software Development through Coding Conventions and Frameworks. IEEE Computer Society. Second International Conference on Availability, Reliability and Security (ARES’07) 10-13 April 2007, pp. 1042 – 1051.