An Organizational Framework for Building Secure Software

9 downloads 51228 Views 629KB Size Report
software requires a strong alignment of business and technological domains in ... their activities taking into account software security considerations. Examples ...
An Organizational Framework for Building Secure Software Abdelwahab Hamou-Lhadj ECE, Concordia University 1455 de Maisonneuve West Montreal, Quebec, Canada [email protected]

Abstract In this paper, we argue that building a secure software system requires more than just a good understanding of technology. It requires an organized framework for the business context in which the system is being built. Unlike existing studies that focus on security only from the technological point of view, in this paper, we present a framework for building secure software that facilitates the linkage between security requirements, software development practices, and business process management. Our framework consists of four main components: Governance, People, Process, and Technology. We believe that this framework, if implemented properly, can be a powerful tool that can be used by software companies to cope with the increasing customer demand for secure software. Keywords: Software security, software assurance, security support framework, organizational frameworks

1. Introduction In today’s world, critical decisions are made and critical actions are taken based on information stored, analyzed, or generated by software systems. As a consequence, software security is now in the forefront of public concern. Worries about computer viruses and worms, Internet browser exploits, online privacy and identity theft, and other related concerns are very common newspaper headlines. And, most governments around the world continue to worry about "cyberattacks" and "cyber-terrorism" as active concerns. For major software vendors, building secure software products is considered a top priority requirement. Failure to fulfill this requirement could seriously damage the company’s reputation and have very negative business consequences for the company in the market place. In 2002, Chief Executive Officers ranked software security as 7.5 out of 10 in importance [1]. The average firm’s information security budget in

AbdelKrim Hamou-Lhadj

Cognos Inc. 3755 Riverside Drive Ottawa, Ontario, Canada [email protected] 2002 (excluding staff) was about US$1.1 million, which represented a total of US$196 spent on security per employee per year [2]. Budgets have increased annually at a rate of nearly 20 percent since then; but the majority of the spending has focused on the software product itself (i.e., feature development and testing), and not the process of building secure software products [3]. Fortunately, research in the area of software security has been very active in recent years. The objective is to provide software practitioners with efficient techniques and tools that would allow them to design, develop, and test software products that can anticipate or detect malicious attacks, continue operating correctly in the presence of most attacks, or tolerate the errors and failure that result from such exploits [4, 5, 6, 7]. However, these techniques and tools address security only from the technological standpoint, placing less attention on the business context in which the system is built. The issue is that even the most sophisticated techniques and tools might turn to be completely ineffective if there is no clear and consistent support of security practices from the business standpoint, including commitment from senior management to security, skilled employees, efficient and effective business processes, etc. In this paper, we propose that building secure software requires a strong alignment of business and technological domains in one common organizational framework, which we refer to as the Security Support Framework. The proposed framework is based on the PPT (People, Process, and Technology) model used in project management [8]. We have enhanced the PPT model by adding a governance component to enable strategic management of security support initiatives. The remaining parts of this paper are as follows. In the next section, we present the security support framework and describe its components. In Section 3, we conclude this paper and present future work.

Figure 1. Components of a Security Support Framework

2. Proposed Framework Figure 1 illustrates the components of the security support framework presented in this paper. We describe in more detail each component of the framework in the following subsections.

2.1. Governance Component The mission of the governance component is to engage in a unified approach the integration of security support activities with software development practices at the strategic level. This can be achieved by putting a set of management processes in place to ensure proper planning, execution, monitoring, and closing of security support activities. More specifically, a software company should put forward the following governance elements: a set of performance objectives, execution policies, management internal controls, and strategic alignment mechanisms. Performance objectives represent measurable goals that the organization would target in order to fully integrate security support activities with software development practices. Examples of performance objectives are: percentage of software development projects in which specific requirements have been defined for software security, percentage of projects in which an external vulnerability assessment has been performed, etc. Execution policies define the way by which software development teams are expected to perform their activities taking into account software security considerations. Examples of execution policies are: quality assurance team responsibilities regarding

software security, inclusion of security testing in the overall software testing strategy, etc. Management internal controls are about the means that management will introduce in software development projects in order to measure how well the development team is considering software security aspects throughout the entire software development life cycle. Strategic alignment mechanisms aim to ensure that security support activities introduced in software engineering project are fully aligned with the overall business strategic goals of the organization. These mechanisms include software project reviews, lessons learned, and benchmarking. A strong governance component can effectively enable the translation of security requirements to specific revenue-generating business activities rather than a mere software requirement.

2.1. People Component The goal of the people component is to enable the effective selection, training, motivation, and retention of qualified resource talents who will operate the security support framework and deliver on its objectives. Education of an organization’s personnel is essential to operating a sound security support framework and to reducing the risk for the organization from becoming a victim of cyber crime. As such, there is need to have educational programs that provide practitioners with the necessary skills, knowledge, and expertise needed to becoming security architects capable of designing, implementing,

analyzing, and managing the security of large and complex systems. Major educational institutions in North-America provide good training and qualifications in many areas of information security and assurance. There exist today many university programs that cover a wide range of software security topics including secure wireless and wired data networks, computer system security, cryptography, secure database systems, secure software engineering, secure e-Commerce, enterprise security, secure operating systems and networks, etc. In addition, there is a need to provide training with respect to the various laws, regulations, and standards related to security. These authoritative rules should be part of the compliance landscape of the organization since they have a direct impact on the way security is handled and implemented in software. Security authoritative rules cover all pertinent regulations and standards focusing on the security, integrity, and availability of physical assets, financial assets, human capital, intellectual property, and information system networks of a corporation or government organization. An example of authoritative rules in the area of software security include the ISO/IEC 270001 series of standards, which aims at providing recommendations and guidelines on how information security management systems should be implemented, operated, monitored, reviewed, and maintained. Another example would be the Payment Card Industry Data Security Standards2, which include best-practice guidelines for all major credit card issuers and organizations that store, process and transmit credit card data. The standards were developed by a group of credit card companies including Visa, Master Card, American Express and Discover. The standards cover 12 sets of rules which govern the secure handling of credit card information. They require that all applicable organizations pass quarterly vulnerability scans and annual security assessments. Furthermore, companies need to take an active part in defining training needs in the area of software security. One of the objectives is to work towards a body of knowledge for software security, from which training institutions can extend their programs and professional certifications, and create new ones.

1 2

http://www.iso27001security.com http://www.pcisecuritystandards.org

Finally, the motivation and retention of qualified personnel is important to ensure the successful operation of the framework.

2.3. Process Component The focus of the process component is to define and implement the operational practices that need to take place for the development and delivery of security support activities. This component is also focused on the improvement of these practices through measurements and assessments. From the development and delivery standpoints, these processes should include the necessary information about how to perform software development activities that take into consideration the security aspect of the intended software product. Examples of these processes are: how to define security-related requirements, how to design for secure software, how to test for security, etc. From the improvement viewpoint, these processes should provide a practical framework for identifying issues and areas of improvement, allow software development project team members to not just focus on getting the software product produced, but introducing efficiency practices in the software development process as well. Examples of these efficiency practices are: identifying the impact of potential security issues earlier in the project lifecycle, developing a more efficient model for regression testing, etc. These processes will help the organization set a consistent and structured framework for security processes and controls throughout the organization. To be operational and sustainable, defined security practices need to be effective, efficient, and ethical. To achieve these objectives, adherence to external standards (e.g., ISO 27001 – Information Security Management Systems) could be a good starting point.

2.4. Technology Component The technology component of the security support framework encompasses a set of techniques and tools that can be used by software engineers to design secure software systems. Software security has progressed over the years to become a well established discipline. There exists a panoply of algorithms and techniques that can be used depending on what needs to be secured and the degree of security needed [4, 5, 6, 7].

There is also an increasing interest in techniques that address security throughout the entire software development life cycle. The focus is to examine the concept of “design for security” and to incorporate technical security issues related to the development of software from the very beginning in the development process. Examples of such techniques include the concepts of abuse cases [9] and threat modeling [10]. Abuse cases are used to create scenarios by simulating the way the system can be attacked. Building abuse cases has been shown to be an excellent way to get into the mind of the attackers and design counter-attack strategies. In addition to capturing and describing relevant attacks, abuse cases allow an analyst to think carefully through what happens when these functional security mechanisms fail or are otherwise compromised [9]. Threat modeling is another security-analysis methodology that can be used to assess and document the security risks associated with an application during the design phase [10]. It is also known as risk analysis and risk assessment. It has become a popular technique to help system designers think about the security threats that their systems might face. It enables them to develop mitigation strategies for potential vulnerabilities. The threat modeling process consists of the following steps: decompose the application, determine threats to the system, rank the threats, choose how to respond to the threats, and choose how to mitigate the threats.

3. Conclusion and Future Work In this paper, we proposed a security support framework that aims to align software security practices with effective business considerations. The framework consists of four main components: Governance, People, Process, and Technology. The government component ensures the commitment of senior management to security by integrating security requirements at the strategic level. The people component focuses on selecting, training, and retaining, qualified personal that would operate the framework. The process component puts the emphasis on the organizational processes in support of security. Finally, the technology component consists of a set of tools and techniques that are needed to design and implement secure software. Future direction is to continue investigating the concepts presented in this paper. We also need to assess the effectiveness of the framework by testing it in an industrial setting.

Disclaimer The opinions expressed in this paper are exclusively of the authors and do not necessarily reflect official support or endorsement by Cognos Incorporated.

References [1] M. Gerencser and D. Aguirre, “Security Concerns Prominent on CEO Agenda,” Strategy + Business Press, 2002. URL: http://www.strategybusiness.com/press/enewsarticle/22197 [2] A. Carey, “Worldwide Information Security Services Forecast, 2001–2006,” IDC Report No. 26899, 2002 [3] A. Schneier, Secrets & Lies (John Wiley & Sons, 2000). [4] J. Viega, G. McGraw, Building Secure Software: How to Avoid Security Problems the Right Way (Addison-Wesley, 2002). [5] N. Davis, “Developing Software Tech News: Engineering, 8(2), 2005.

Secure Software”, Secure Software

[6] M. Bishop, Computer Security: Art and Science, Addison-Wesley, 2002. [7] G. McGraw, Software Security: Building Security In (Addison-Wesley, 2006). [8] S. Berkun, The art of project management (O' Reilly Media, 2005). [9] G. Sindre & A. L. Opdahl, “Eliciting Security Requirement by Misuse Cases”, Journal of Requirements Engineering, Springer London, 10(1), 2005, 34 – 44. [10] F. Swiderski, W. Snyder, Threat Modeling (Microsoft Press, 2004).