Secure SDLC: Integrating security into your software development life cycle

Integrating security into the SDLC is essential for developing quality software. While there are no standard practices, these guidelines can help you develop a custom process for a secure software development life cycle.

Increasingly you hear about the need to integrate security into the software development life cycle (SDLC). A few techniques, including threat modeling, logging and penetration testing, address different parts of the SDLC, but we still lack a standard process for addressing the entire life cycle.

Yes, some companies have developed their own processes:

  1. The ASAP process: This is a process followed by Microsoft internally, but it has not been released for other companies to review or follow.
  2. ISECOM process: This is a more mature model and does addresses a lot of security practices in a development process but somehow has not gained popularity amongst the companies. Further details can be found at www.isecom.org.

For the most part, however, companies lack guidance or even information from which they can learn or use as a guideline. In time, the increasing need for a standard for secure design methodology will be addressed by the proper standards authority. Until then, a company can build a custom process based on the following guidelines.

 

  1. Requirements gathering
    1. Identify regulatory and compliance assumptions: A business security executive helps assess legal or compliance (Sarbanes-Oxley (SOX) HIPAA, GLBA, etc.) risks involved and provide alternatives.

     

  2. Functional design
    1. Update regulatory and compliance assumptions: Update the regulatory and compliance assumptions and document them in the functional design document.
    2.  

    3. Identify functional assumptions: All the functional assumptions need to be identified and documented in the functional design document.
    4.  

    5. Data classification: Data classification is a crucial step. Based on the sensitivity of data being collected, stored and transmitted, the data should be classified. The results determine to what extent the data needs to be secured.
    6.  

    7. Prepare system boundary document: This document identifies the boundary where the control is transferred to or from the external system. This document helps identify areas where extra security controls need to be put in place. It can also serve as an input to the threat modeling document.
    8.  

    9. Review by business security executive: The functional document should be reviewed and signed off by the business security executive after ensuring adherence to regulatory and compliance policies.

     

  3. Technical design
    1. Identify and document technical assumptions: All the technical assumptions should be identified and documented. For example: An e-mail address will serve as a user ID or only the last four digits of Social Security number will be displayed.
    2.  

    3. Prepare misuse cases: A misuse case is the opposite of use case. Its sole purpose is to identify how a use case should not behave. A misuse case should capture the type of attacks that can be made on the system and how the system should behave in such situations. This is a relatively new approach, but it will go a long way in addressing the security requirements of an application. A misuse case can also help prepare test cases purely to test the security strength of the system.
    4.  

    5. Prepare a threat model: This is another newer approach, initiated by Microsoft. With this, a threat model document (threat profile) captures the security strength of a system. It identifies threats and vulnerabilities and helps in providing a more accurate sense of security of the system.
    6.  

    7. Security patterns: Security patterns are like design patterns that are applied toward information security. These patterns encapsulate security expertise in the form of identified solutions and present issues and trade-offs in the usage of the pattern. Architects might want to look at these patterns to see if they can use some of the existing solutions, saving time and effort.
    8.  

    9. Data backup strategies: It is important to capture the data backup strategies in the design phase. For example, frequency of data backup, details of backup media, access privileges to the backup and whether the backup be encrypted. These points will help maintain the confidentiality, availability and integrity of the data.
    10.  

    11. Data transmission strategies: This is where we capture details around the data transmission. Depending on the data classification, should the data be encrypted during transmission? Is the data being decrypted and re-encrypted at any point? If yes, then what kinds of security controls are in place at that point? Is the customer information like Social Security number or credit card number partially masked? This will prevent the data from being stolen in most kinds of attacks.
    12.  

    13. Data storage security requirements: These are influenced by the type of data. Names and addresses can be stored in clear text, but sensitive data such as Social Security numbers, driver's license numbers and credit card numbers should be encrypted in the database. Data required for authentication should be given more thought, such as applying one-way encryption.
    14.  

    15. Authentication strategy: This is a critical step, as this is the entry point of the system. If this is compromised, the attacker will have unauthorized entry into the system and can do a lot of harm. Some of the things to consider are strong password policy, two-factor authentication for critical features such as funds transfers, input validation strategies, account inactivity period, account locking, password retrieval mechanism, and a username/password storage strategy.
    16.  

    17. Session management strategy: Some of the things that need to be identified are details around the session creation:
      • Session ID should be stored in a secure cookie
      • Session ID should be encrypted Cookie should expire when the session is invalidated or the browser is closed
      • Application should force the browser to be closed when the user logs out or session is invalidated.

      These details should be captured in the design phase and should be documented in the design document.

    18.  

    19. Error handling: In most cases, a standard error page should be displayed in any error situation. The application should trap all the system errors (such as missing configuration file, ODBC error, database not working, etc.) or application errors (such as invalid username/password) and redirect them to one standard error page. Ideally, the list of possible error situations and the corresponding error messages should be identified, and a generic error message for unknown or unidentified errors with no technical information should be displayed to the user. Also, an entry in the logs should be created with the time stamp and other relevant information.
    20.  

    21. Identify trust boundaries, trust levels, entitlements, encryption requirements: This is crucial and should be identified during the design phase. Extra security controls should be put in place where trust level is low. Trust levels and trust boundaries are also identified in the threat modeling document. Similarly, entitlements are important in identifying who has what level of access to what resources in the system. Data classification will help determine what should be encrypted. Encryption details such as encryption algorithm, hashing algorithm, and key length should be identified and documented in the design document.
    22.  

    23. Design audit logs: You must identify in the design phase what kind of information needs to be captured should there be an error. You should also consider the log retention strategy. The focus on designing audit log should be not only to identify error situations but also to establish a pattern in case someone is trying to hack into the application.
    24.  

    25. Prepare infrastructure security best practices document addressing operating system, Web server, application server, database, FTP, e-mail: This document will help strengthen the security of the infrastructure and should be prepared during the design phase.

     

  4. Coding/construction
    1. OWASP Top 10: The OWASP guidelines go a long way in helping developers write secure code.
    2. Secure coding guidelines: Apart from the OWASP guidelines, companies should have secure coding guidelines for the technology (Java, .NET, PHP, etc.) that they use.

     

  5. Integration & QA testing
    1. Infrastructure security best practices need to be reviewed before pen testing: The document prepared during the design phase should be enforced in the QA environment before penetration testing. Pen testing should be done on the system that will simulate the production environment.
    2.  

    3. Code review for secure coding guidelines: Whereas most organizations already conduct code review, reviewing the code for secure coding guidelines is not always adequately emphasized. This can lead to vulnerabilities in the code that can be exploited by attackers. There are some automated tools available in the market to do a security code review.
    4.  

    5. Vulnerability assessment/pen testing/ethical hack: This is slowly becoming a practice in the financial industry. It helps identify a lot of security vulnerabilities applications before putting them into production. Companies can leverage this testing to strengthen their application.
    6.  

    7. Encryption testing: There is no point using encryption if it is not secure enough. With tools such as rainbow tables, it is becoming relatively easier to break encryption. Hence, the companies should test for the strength of the encryption being used. Secure key management is equally important.
    8.  

    9. Test cases targeting security: This can be derived from misuse cases, as these test cases will test how a system should not behave. These test cases should be run against the application in QA environment to ensure the implementation of misuse cases.
    10.  

    11. Establishing patterns in logs and audit trail review: Some attack testing should be done in order to test if a pattern can be established from the logs in the QA environment. This will help determine and capture information on attacks in your production environment.

     

  6. Production deployment
    1. Enforce infrastructure security best practices are properly deployed on production environment: The document prepared during the design phase should be enforced in the production environment.

       

    2. Prepare a threats and vulnerability document and sign off from business: If there are any existing threats or vulnerabilities in the system during the time of production deployment, they should be captured in a document and business should sign off on them. In the end, it is their application and they own any risk to the application.

As you can see, there are a lot of steps that can be taken to integrate security at different stages in the SDLC. The more steps we take to integrate security, the more difficult we make it for attackers to break into our application. This by no means is a complete process, but it can act as a guideline to companies that are still searching for answers on how to build a secure design methodology according to their needs. After all, every step -- however small -- is a step forward in securing your application.

Some other links to check out to find more details on some of the individual topics mentioned here:

Data classification
* http://www.yourwindow.to/information-security/gl_dataclassification.htm

Misuse case
*Threat modeling enhanced with misuse cases
*  Initial Industrial Experience of Misuse Cases in Trade-Off Analysis
* Capturing Security Requirements through Misuse Cases(PDF)

Security patterns
*Core Security Patterns: Best Practices and Strategies for J2EE, Web Services, and Identity Management -- Chapter 8
* Security Patterns for J2EE Applications, Web Services, Identity Management, and Service Provisioning

Threat modeling
* Threat Modeling (Microsoft Professional) (Book)

-------------------------------
About the author: Anurag Agarwal, CISSP, works for a leading software solutions provider where he addresses different aspects of application security. You may e-mail him at anurag.agarwal@yahoo.com.


This was first published in March 2006

Dig deeper on Building security into the SDLC (Software development life cycle)

Pro+

Features

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

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchSOA

TheServerSide

SearchCloudApplications

SearchAWS

SearchBusinessAnalytics

SearchFinancialApplications

SearchHealthIT

Close