Archive for May 2011

Security Development

May 24, 2011

Abstract

Risk management process is an essential component in any successful product where the security development is the main goal of such process to manage risks, and protect the organization or vendor from any threat that might interrupt the business lifecycle because of a product’s vulnerabilities. The purpose of the risk management process is to identify risk, assess risk, and take the required steps to reduce such risk to an acceptable level. Also, the ultimate goal for such process is to help the organization to handle IT risks, and also create the product with high risk assurance. Risk management consists of three important processes: risk assessment process, risk mitigation process, and risk evaluation and assurance process (Stoneburner and Feringa, 2002). 

Risk analysis is a component of risk management that identifies the possible risk of a product. Risk assessment is the component of risk analysis where it identifies, evaluates and estimates the level of risk for any product. Such assessment can be achieved through conducting a comparison against benchmarks or standards to determine the level of risk, and create the initial threat assessment for such risk. Also, during the threat assessment, the nature of the threat should be identified, vulnerabilities to such threat are estimated, and the consequences of such threat should be determined (McGraw, 2004).

It’s imperative for any organization to implement the security development lifecycle that can be implemented and integrated with the risk management process that is designed to manage risks and create the right plan to eliminate risks. Also, it’s important that such security consideration to be integrated with the system development lifecycle. Microsoft took the initiative approach to create the security development lifecycle that enables developers to create better software products that can  follow certain security standards where it can be used to provide the right system evaluation and assurance (Swafford, 2010).

Building the Security within the SDLC

Today’s software security vulnerabilities are common issues that need to be part of the software development lifecycle (SDLC). Such integration wasn’t exist in the past since most of the software vendors thought that such vulnerabilities can be fixed during the regular support process in the same way the bug fixes were done. However, it became clear for the software vendors that such vulnerabilities are not an easy fix, are not triggered by the user events, and don’t have a timeline to be initiated. With the motivation of the attackers to exploit the software vulnerabilities, software vendors can’t benefit anymore from the fast imperfect software releases, and the fast profits from these releases. Vendors started to ask the question; “What should be done to reduce security bugs during the software engineering?” and always trying to follow the software security best practices to eliminate such security bugs. Eliminating security bugs should be part of the software development, the techniques that create fewer security bugs must be implemented, and the defects that arise during the development phase must be corrected (Wysopal, 2008).

Wysopal (2008) explained that the cost of the software development is a big concern, and in integrating the security enhancement process within the software development lifecycle, it is imperative to implement the security processes in most cost-effective way, and part of the factors that can affect the cost of the software development is the security prevention, and the detection techniques. It’s always cheaper for any software vendor to early detect the defects and correct such defects. For example, choosing a poor authorization scheme in the design phase, and not detecting such defects in the testing phase will cost later the software vendors a hundreds of lines of code that will add more cost that required for early detection and fixing such flaws. That said, the major processes that can reduce security defects are:

  • Secure Design – where the implementation of the application security principles is required to minimize and harden the attack surface during the software design phase.
  • Threat modeling – The threat modeling is used to determine if the implementation of the security principles in the design phase were able to mitigate the risks posed by the functionality implemented in the software.
  • Static code analysis – In the past secure code review were done manually, and today such review is done via analysis tools that expose the security errors and code vulnerability issues within the software. 
  • Security testing – It uses dynamic techniques where the software is used much like an attacker would do when trying to attack the software (Penetration testing). Where the tester will attempt to get the software to perform functions that wasn’t designed to be active, and can be used. In such phase a threat model is used to rank the areas of the software where it was easy for the tester to exploit, and it represents the closest area of the attack surface.

To achieve the highest assurance level for any application; it requires dedicated efforts to create the assurance level required for any application (e.g. designing operating system, banking and trading applications) where security process has to be achieved during the development lifecycle (Wysopal, 2008). 

Risk Assessment and Threat Identification

Once the risk data were gathered during the development lifecycle (Design and coding phase) it’s important that such data to be analyzed and the probability of the risk occurring to be determined. Another important piece of information that is required during the risk assessment process is the evaluation of the cost involved for each risk to be eliminated (Shimonski, 2004).

Before any risk assessment conducted, it is imperative that the undertaking processes to be comprehensive through different questions that explain the purpose of such process, one of these questions is: what is the end result of such process? Which can be anything from ensuring that security is maintained up to the required standard to being compliance with government mandated policies? It’s also important to that various functions and components of the application potential risks are identified, and the threat of such risks is ranked based on the built-in threat model recognized by the organization or the vendor of such product (Valentin, 2010).

 Bayne (2002) explained that most of the tools that are used to identify threats, and perform the risk assessment are trying to answer the following questions:

  • What needs to be protected?
  • What type of threats and vulnerabilities that is required to be identified?
  • What are the implications of such threat if loss or damage of data occurs?
  • What is the value of such damage to the vendor or the organization?
  • What is required to eliminate or minimize such threat and the exposure to such threat?

Bayne (2002) explained that the outcome of such assessment and the ability to answer the above questions is to provide recommendations that can increase the integrity, and the availability of the product, maximize the protection of the product, and the confidentiality of the data it contains while maintaining the same usability and the functionality that such product or software provides. The core areas in a risk assessment are:

  • Scope – Provide the analyst with what needs to be protected to what details and level, and what system and application included in such assessment.

 

  • Data Collection – where the collection of current procedures and policies in place should be identified in this phase (e.g. information on vulnerabilities and threats against the application should be identified and gathered).

 

  • Analysis of Policies and Procedures – Source of policy compliance that can be used to implement security within application has to be identified within this phase (e.g. Common Criteria – ISO 15504).

 

  • Threat Analysis – Threats can be described as anything that would contribute to destruction, interruption or tampering of application, product or service. The threat analysis will look at every element of the risk, and how possible will happen. Also, the threat can split into human threat and non-human threat as follows:

 

Human

Non-Human

Hackers Viruses
Theft (physically or electronically) Electrical
Accidental Hackers software

 

  • Vulnerability Analysis – This phase determines the current exposure of the risks; by testing the gathered vulnerability analysis identified against the application; and determines if the current application security represents a safe guard to maintain integrity, availability and confidentiality of such application. Also, identify if the proposed security solution is sufficient to handle the threats (e.g. using a penetration testing where it is conducted with knowledge penetration test; and zero-knowledge penetration test). The specific vulnerabilities can be graded according to the level of risk and the threat that can pose to the application. For example:

 

Rating

Description

1

Minor Severity, Minor Exposure

2

Moderate Severity, Moderate Exposure

3

High exposure, High Severity

Conclusion

Lipner and Howard (2005) explained that it’s imperative for software vendors to address the security threats that might exploit by attackers in their software products, and the software security is the core requirements that can be driven by the market forces where a widespread of trusted software is critical issue for any success. The set of high-level principle that are used for building more secure software is the result of experience of the real-world security software. The definition of these principles is as follows:

  • Secure by Design – In this phase, the software should be architected, designed and implemented in a way that can protect the information it processes, protect itself, and be able to resist the attack.
  • Secure by Default – Software designers should assume that security flaws will be always exist within any software, and attackers will exploits such flaws, and as such; efforts have to be made to minimize the harm occurs by the hackers, and security implementation should be promoted as default state of the software.
  • Secure in Deployment –the software should implement the right administration tools that can promote security approaches for the software administrator and users. Also, updates and security patches should be easy to be deployed to such software.
  • Communications – Software developers and vendors should communicate openly and responsibly with the software administrator, and users to help them be prepared for the discovery of the product vulnerabilities, and to help them to take the right protective actions toward such vulnerabilities.

Finally, The threat and the risk assessment process is a continual process to ensure that the software or the application is in a good level to stand against threats and hackers attacks, and such status should be reviewed regularly to ensure that the protection mechanisms in place still current and can meet the present and the future required objectives. The risk assessment for a product or software should address the security requirements of the vendor or organization requirements in terms of availability, integrity, and confidentiality. Also, the threat and the risk assessment should be an integral part of the overall process of the software development lifecycle, and should be realized by all the staff involved in such process (Bayne, 2002). 

References

Bayne, J. (2002) An overview of threat and Risk Assessment [Online]. Available from: http://www.sans.org/reading_room/whitepapers/auditing/overview-threat-risk-assessment_76 (Accessed: 25 December 2010).

Lipner, S. & Howard, M. (2005) The Trustworthy Computing Security Development Lifecycle [Online]. Available from: http://msdn.microsoft.com/en-us/library/ms995349.aspx (Accessed: 25 December 2010).

McGraw, G. (2004) Risk Analysis in Software Design [Online]. Available from: http://www.cigital.com/papers/download/bsi3-risk.pdf (Accessed: 25 December 2010).

Stoneburner, G. & Feringa, A. (2002) Risk Management Guide for Information Technology Systems [Online]. Available from: http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf (Accessed: 25 December 2010).

Swafford, S. (2010) Security Development Lifecycle [Online]. Available from: http://radicaldevelopment.net/2010/09/23/security-development-lifecycle-part-1/ (Accessed: 25 December 2010).

Shimonski, R. (2004) Risk Assessment and Threat Identification [Online]. Available from: http://www.windowsecurity.com/articles/Risk_Assessment_and_Threat_Identification.html (Accessed: 25 December 2010).

Valentin, J. (2010) How to conduct an Enterprise Application Risk Assessment [Online]. Available from: http://www.ehow.com/how_5694059_conduct-enterprise-application-risk-assessment.html (Accessed: 25 December 2010).

Wysopal, C. (2008) Building security into your software-development lifecycle [Online]. Available from: http://www.scmagazineus.com/building-security-into-your-software-development-lifecycle/article/104705/ (Accessed: 25 December 2010).

Advertisements