A Six Sigma Approach to Assure IT Security

A Six Sigma Approach to Assure IT Security A Six Sigma Approach to Assure IT Security By Ubaid Hayee 820811-7070 Department of Computer and System Science (DSV) The Royal Institute of Technology (KTH) Stockholm, Sweden January 2008 i A Six Sigma Approach to Assure IT Security Table of Content Table of Content ................................................................................................................. ii Tables:................................................................................................................................ iv Figures: ............................................................................................................................... v Figures: ............................................................................................................................... v Chapter 1 .................................................................................................................................. 1 Introduction......................................................................................................................... 1 1.1 Introduction................................................................................................................... 2 1.2 Background ................................................................................................................... 2 1.3 Objective ....................................................................................................................... 3 1.4 Scope............................................................................................................................. 3 1.6 Limitation...................................................................................................................... 4 1.7 Audience ....................................................................................................................... 4 1.8 Research methodology.................................................................................................. 4 1.9 Structure of thesis ......................................................................................................... 5 Chapter 2 .................................................................................................................................. 6 Research Methodology ....................................................................................................... 6 2.1 Scientific method: ......................................................................................................... 7 2.2 Research Process:.......................................................................................................... 7 2.2.1 Problem Identification: .......................................................................................... 8 2.2.2 Literature Selection:............................................................................................... 8 2.2.3 Result Finding:....................................................................................................... 8 2.3 Method Discussion: ...................................................................................................... 9 Chapter 3 ................................................................................................................................ 10 Common Criteria (CC) ..................................................................................................... 10 3.1 Literature Source:.................................................................................................. 11 3.2 Definitions: ........................................................................................................... 12 3.2.1 Stakeholders:................................................................................................. 12 3.2.2 Target of Evaluation ..................................................................................... 12 3.2.3 Package: ........................................................................................................ 12 3.2.3.1 Functional Package: .................................................................................. 13 3.2.3.2 Assurance Package: .................................................................................. 13 3.2.4 Protection Profile: ......................................................................................... 13 3.2.5 Security Target:............................................................................................. 13 3.2.6 Class Structure: ............................................................................................. 14 3.3 Functional Classes: ..................................................................................................... 14 3.4 Assurance Classes:...................................................................................................... 15 3.5 Evaluation Assurance Levels:..................................................................................... 17 Chapter 4 ................................................................................................................................ 19 Six Sigma (SS).................................................................................................................. 19 4.1 Methodologies: ..................................................................................................... 20 4.1.1 DMADV Frame Work: ................................................................................. 20 4.1.2 DMAIC Frame Work:................................................................................... 21 4.2 Metrics: ................................................................................................................. 23 4.3 Philosophy: ........................................................................................................... 23 ii A Six Sigma Approach to Assure IT Security Chapter 5 ................................................................................................................................ 25 Protocols ........................................................................................................................... 25 5.1 Comparison Criterion............................................................................................ 26 5.1.1 Six Sigma:..................................................................................................... 26 Abstraction level: ...................................................................................................... 27 Audience: .................................................................................................................. 27 Objective:.................................................................................................................. 27 Formal Methods:....................................................................................................... 27 Customer focus: ........................................................................................................ 28 Philosophy: ............................................................................................................... 28 5.1.2 Common Criteria: ......................................................................................... 28 Abstraction level: ...................................................................................................... 28 Audience: .................................................................................................................. 28 Objective:.................................................................................................................. 29 Formal Methods:....................................................................................................... 29 Customer Focus: ....................................................................................................... 29 Philosophy: ............................................................................................................... 29 5.2 Protocols: .............................................................................................................. 30 5.2.1 Methodology:................................................................................................ 30 5.2.1.1 Implementation Exemplification: ............................................................. 34 5.2.2 Metrics .......................................................................................................... 36 5.2.3 Philosophy: ................................................................................................... 38 ................................................................................................................................ 39 Chapter 6 Analysis & Conclusion ..................................................................................................... 39 6.1 Analysis: ............................................................................................................... 40 6.1.1 Future work:.................................................................................................. 41 6.2 Conclusion: ........................................................................................................... 41 Appendix A................................................................................................................... 43 Assurance classes families and components................................................................. 43 EAL and Assurance components .................................................................................. 48 References:........................................................................................................................ 49 Book and Article:.......................................................................................................... 49 Electronic Reference:.................................................................................................... 51 iii A Six Sigma Approach to Assure IT Security Tables: Table 1: SSDL................................................................................................................... 32 Table 2: DMAIC implementation..................................................................................... 34 Table 3: Prioritizing Security Modules............................................................................. 36 Table 4 DPO derivation .................................................................................................... 37 Table 5 CC Roles .............................................................................................................. 38 Table 6 Assurance classes families and components........................................................ 47 Table 7 EAL and Assurance components......................................................................... 48 iv A Six Sigma Approach to Assure IT Security Figures: Figure 1: Research Methodology Steps. ............................................................................. 4 Figure 2: Mapping of Research methodology with research steps ..................................... 7 Figure 3 Class Structure.................................................................................................... 14 Figure 4 Cause and Effect Diagram.................................................................................. 22 Figure 5: Vulnerable Authentication CED ....................................................................... 35 v A Six Sigma Approach to Assure IT Security Chapter 1 Introduction 1 A Six Sigma Approach to Assure IT Security 1.1 Introduction Today information is considered as an asset just like capital either it is related to a personal or corporate (Christopher & Audrey, Managing Information Security).Global sharing and information losses enforce organizations to think about their information security management. Increasing security needs of military industry, defense associated organizations, Telecommunication and personal credential privacy requirements call for standardization. Common Criteria (CC) is one of the well know IT security assurance standard that is serving for this purpose and setting assurance levels (Mike & Fiona, IT Security Assurance, 2006). CC not only emphasizes the customer IT security requirements and security functional needs but also establishes criteria for categorizing products at different security levels. However; organizations still need some qualitative improvements in order to attain high assurance for the security of their IT product (Wade H baker & Linda, Is information security under control, 2007). Well established practices, advance protocols and authentic tools can be a real contribution to these standards. Six Sigma (SS) is one of the mature statistical and data driven quality management systems that is serving from last two decades in various organization. This thesis will try to analyze six sigma practices, tools, templates and extract some use full conclusions to overcome the needs of IT industry. 1.2 Background Initially, various countries had different IT security assurance standards. Information Technology Security Evaluation Criteria (ITSEC) of European Union, Trusted Computer Security Evaluation Criteria (TCSEC) of U.S. government, Canadian Trusted Computer Product Evaluation Criteria (CTCPEC) of Canada and US Federal Criteria (FC), all these criterions were serving for the same purpose in different countries. (Matt Bishop, Computer Security Art and Science, 2002). Then these nations agreed to set a common set of criteria for the corporate users of assured IT products and as a result, CC came in to existence. CC standardized documentation is CC V3.1 (Defence Signal Directorate et al, Common Criteria, 2006) and its ISO equivalent is ISO/IEC 15408 (ISO, Information Security Evaluation, 2005). CC understanding and successful implementation became evident for IT security products after the publication of NSTISSP No.11. According to this National Security Telecommunication and Information Systems Security Policy, form 1st of July 2002 all government acquisitions and information security product of U.S. must be evaluated and assured according to CC or equivalent. (CNSS, National Information Assurance Acquisition Policy, 2003). Common Criteria, introduced for covering military security requirements, is now being used in IT products as a guideline for security needs. Firewalls, network servers, operating systems and many other IT products are acquiring CC certifications. Although CC is remarkable in identifying security requirements but it does not give answers to many questions. CC does not provide details of mapping security requirements in software development life cycle (SDLC). It is silent to mention any methodology for security implementation and it requires formal methods for implementation and testing but does not refer any tools and techniques to achieve formal implementation. 2 A Six Sigma Approach to Assure IT Security On another hand Six Sigma is one of the successful quality frameworks that gave extra ordinary benefits to companies like General Electronics (GE) and Motorola. SS have no standardized documentation like common criteria has CC V3.1 or ISO/IEC 15408. There are number of books by quality gurus about SS which are considered as source of six sigma principles, Further more; companies like GE and Motorola has launched there successful practices of six sigma that serve as guideline for others. SS experts who adopted and launched SS in companies are often green belt, black belt or master black belt Certified (Motorola, 2007). SS strength lies in its powerful quality methodologies and stable quality tools. These methodologies are supportive in elaborating implementation details. These tools are used to formally test and verify the accuracy of implementation. SS quality philosophy changes the attitudes and behaviors of people and organizations in order to achieve better results. These SS methodologies, tools and philosophies can be a source of spiraling CC. Its methodologies can be used in CC requirement implementation and Tools can be used to achieve formally tested and verified CC requirements. Six sigma metric of 3.4 defect per million opportunities (DPMO) can be adopted in CC assurance classes for measuring confidence level. 1.3 Objective The main objective of this thesis is to give alternative and standard ways of implementing CC requirements. In order to achieve this goal we will focus on some of the critical areas of CC. CC is remarkable in identifying Security Functional Requirements (SFR), Security Assurance Requirements (SAR) and security objectives but it is unable to stipulate any defined methodologies to accomplish all these requirements. We will find methodologies or recommend changes in existing approaches for reliable implementation of these requirements. CC imposes evaluation of security functional requirements on developers and security assurance requirements on evaluators but it does not specify any tools and techniques to asses the level of trust. We will find evaluation tools that will help both developers and evaluators to effectively and efficiently assure implementation of these requirements. CC demands specification of security requirements for the IT environment and security objectives for the environment. We will suggest if any cultural or environmental changes can help in achieving these requirements and objectives. Such changes can be recommendation for team structure, organizational polices, threat identification techniques and risk assessment approaches. 1.4 Scope This thesis will define methodologies for implementing SFR and SAR. It will suggest tools to evaluate test results, level of confidence and conformance of security component with security requirements. It will cover IT Governance requirements like security policies and risk assessment to support SFR and SAR. It will focus on developer and evaluator both for recommendation of tools and techniques to assure their functional and assurance requirements respectively. Six Sigma general practices, methodologies, tools, templates and artifacts will serve as a prime source. 3 A Six Sigma Approach to Assure IT Security 1.6 Limitation SS has no standard documentation that’s why it is difficult to point out any specific knowledge source. The main focus of the thesis will only be on Six Sigma tools and methodologies. Due to time and resource limitations it will be difficult to look and analyze industrial implementation of SS. Thesis will not address all weaknesses of CC like “mess” of documentation, time taking and costly accreditations. Cryptographic algorithms, administrative and legal framework, and physical aspects like electromagnetic emanation will not be covered in the scope of security. 1.7 Audience Security consultants, software quality experts, software engineers, process engineers, security auditors, configuration managers, security certification authorities, defense organizations and Common Criteria Testing Laboratories (CCTL) (NIAP-CCEVS, 1999), all of them are the audience of this thesis. This thesis will not only be useful for people related to CC but also for the stakeholders of other IT security standards, and organizations working on IT security products and services. 1.8 Research methodology This thesis will follow research methodology of hermeneutic philosophy. Hermeneutic is defined as the study of methods of interpretation. It involves the ability to understand and comprehend the text of others in appropriate way according to context. This approach will be used to describe both standards. CC and SS will be construed in a simple and understandable way to establish a common awareness of their requirements. Both the standards will be presented in two ways: an individual representation of their requirements and the way to interrelate their commonalities. Qualitative research methodology will also be followed based on the standards, available research material and existing practices. The analytical study of all these will produce bridge protocols between two standards. This qualitative analysis upshot will lead to suggest new practices for IT Experts. Figure 1 shows the steps followed in the methodology. Elaborating Practical implementation of Protocol Standard Explanation CC, Six Sigma Identifying Common Requirements Define mapping protocols Figure 1: Research Methodology Steps. SS will be the source of finding solutions in our research. After finding the gaps in existing CC methodologies, we will explore SS methodologies to overcome the gaps. In 4 A Six Sigma Approach to Assure IT Security order to find evaluation assurance tools, we will find ways to adopt SS statistical tools for gaining confidence in CC requirement conformance. SS templates and variation reduction techniques will also be analyzed to give support to these tools. Six sigma cultural evolution and success stories will be a source of identifying and fixing of environmental factors necessary for security requirements. If SS remained unable to provide resolution of our needs, this thesis will present reasons of differences in both standards. A detailed analysis will be explained, elaborating what are the deficiencies of CC that make it hard to adopt mature SS methodologies or tools. 1.9 Structure of thesis We would like to take start form basics so as to make this thesis beneficial even for beginners. Therefore; step by step approach will be adopted here. After explaining the complete research methodology, thesis will explain both the standards CC and Six Sigma in detail. Purpose of elucidating the standards will not be to write standards but to elaborate focused areas, their requirements and implementations. This explanation will set up the basis for understanding the similarities and finding symmetric areas of these two different standards. Main research area of thesis will be to define protocols between two standards and revealing their practical implementation. This section of thesis may require mathematical and statistical knowledge of reader. In the end a complete analysis of protocol and areas of future work will be summarized. Last chapter will be comprised of conclusions of the whole thesis. 5 A Six Sigma Approach to Assure IT Security Chapter 2 Research Methodology 6 A Six Sigma Approach to Assure IT Security This chapter will explain scientific methods used in conducting research. In this way reader can judge the authenticity of research. Firstly the chapter will explain the research methodologies mapped on research process then complete research process will be enlightened. Data source, literature authenticity and discussion details will confirm accuracy of the results. In the end a critical analysis of methodologies will be discussed. 2.1 Scientific method: Research is defined as a scientific way of investigation. In essence it is a technical and systematic search of finding facts (C R Kothari, Research Methodology: Methods and Techniques, 1985). In specific case of this report a step by step approach will be used to proceed with the research. Initially both standards Common Criteria and Six Sigma will be explained for the reader, to make a clear understanding of requirements. Hermeneutic approach will be used to interpret the technicalities of standards. Hermeneutic insists upon the insuperability of fact and value, detailed and context, and observation and theory (Paul Saettler, The Evolution of American Educational Technology, 1990). Qualitative analysis of explained standards will be done to find similarities of both standards. Content analysis is a type of qualitative research methodology used to analyze the content of text. Here this technique will be used to map pre-requisites, requirements and possible outcomes of both standards. New protocols will be defined based on the result of analysis and commonalities. These protocols will be an outcome of SS tools and methodologies and will serve for IT security. Most of six sigma tools are statistical in nature and they use quantitative and numeric data. In order to verify the successfulness of these tools and methodologies in IT security, a combination of qualitative and quantitative analysis will be used. Figure 2 shows the mapping of scientific method upon research steps. Standard Explanation CC, Six Sigma Identifying Common Requirements Define mapping protocols Elaborating Practical implementation of Protocol Hermeneutic Approach Content Analysis Qualitative Approach Qualitative / Quantitative Approach Figure 2: Mapping of Research methodology with research steps 2.2 Research Process: Research process is made up of series of steps. These steps start from identifying the problem and lead us to finding its solution. Explaining each step in detail, specifying data 7 A Six Sigma Approach to Assure IT Security source and discussion on research process clarifies the strong and weak areas of research. So this section of report will explain all steps of research process and in the end critical discussion of method will be presented for the reader. 2.2.1 Problem Identification: During study of CC in our course work, I observed organizations faced complications in implementing CC. Wesley Higaki, Director of Symantec, said Defense customers are not satisfied with common criteria (Joab Jackson, Symantec: Common Criteria is bad for you, 2007). Besides, a lot of other reasons one of the problems was that different organizations follow different methodologies to fulfill CC requirements. There was no standard way of implementing security constraints enforced by CC. These personal efforts by companies cause wasteful duplication of efforts and time. With initial understanding of SS as a successful quality improvement frame work I adopted deductive approach in which researcher first develops theory and than collects data. The idea was to use SS tools and methodologies for strengthening CC. After discussion with my supervisor, security experts, CC consultants and SS experts (master black belts, black belts) I came to know it can be a unique way of supporting CC. Without any prior work and lack of SS specialist it was hard to proceed. However some efforts of using SS in SDLC and specifically in IT security encouraged me to work. 2.2.2 Literature Selection: Authenticity of literature adds confidence to research process. Reason of mentioning literature source is to let reader analyze himself/herself assurance of the source. In this report research material for CC is based on standard document, Common Criteria and Common Evaluation Methodology Version 3.1 (CC/CEM). (Defence Signal Directorate et al, Common Criteria, 2006). The ISO equivalent of this documentation is International Organization for Standardization/ International Electronic Commission 15408 (ISO/IEC). (ISO, Information Security Evaluation, 2005). For SS, books are the knowledge source. Selection of books is done keeping in consideration to use worldly accepted and authentic books. In order to conduct research university article database, internet portals, research articles, white papers and online discussion with professionals also became source of information. 2.2.3 Result Finding: This report will interpret both standards CC and SS in a simple way using hermeneutic approach. Finding commonalities of two standards will be based on content analysis. Methodologies or tools used for these common requirements in SS will be defined as a protocol to be utilized for the assurance of IT security requirements in CC. In order to visualize the practical implementation of these protocols, a scenario based practical 8 A Six Sigma Approach to Assure IT Security demonstration will be given. In the end usefulness of these protocols will be discussed with the help of logical and statistical measures. This is a new way of approaching CC problem so if we are not able to present a useful contribution of Six Sigma for CC the report will give an analysis of differences and constraints of both standards. Again this analysis will be based on content analysis of standards. 2.3 Method Discussion: Validity and reliability in qualitative research differs from quantitative research. Validity is more inclined towards quantitative approach. Reliability in qualitative approach does not only mean the authenticity of literature but also the validity of whole research process. Here by explaining the research process, its steps, research methodologies and literature source this report would prove its credibility. Discussions with supervisor on each chapter before finalizing the chapter will make it certain that the interpretation of text in the report is in according with the context and is headed in the right direction. There are some issues that may have pessimistic effect on research process. • • • This is the first attempt to map these two standards, so it remained difficult to find any contradictory source or any opposition of research area that could help us in revealing the draw backs of the approach. Both CC and Six Sigma are very complex frameworks in implementation and we don’t have much practical experience in both of them, so the report might be in lack of explaining core practical issues. Both standards have extensive technical material which may not be easily interpretable in report for those who have limited knowledge of IT security. 9 A Six Sigma Approach to Assure IT Security Chapter 3 Common Criteria (CC) 10 A Six Sigma Approach to Assure IT Security This chapter will give a brief description of CC. It will explain the basic definitions, terminologies and concepts used in CC documentation. Security audit requirements, security management requirements, identification and authentication requirements and data protection requirements of IT security product will be explained for giving an understanding of CC functional requirements. Security assurance level marked by CC for evaluating conformance of security components will be given. Security assurance requirements for accrediting appropriate level will be explained. The philosophy of CC is to carefully articulate the threats to organizational security policy commitments and product security requirements and propose sufficiently demonstrable security mitigations for their intended purpose. These security requirements can be implemented in software, hardware and in farm ware. Security evaluation process not only considers software for vulnerability assessment but also the hardware, the networking environment and third party services to accomplish the required task. The name given to IT product and its environment is Target of Evaluation (TOE). Consumer is the entity who has security requirements according to its need. The documents written to state consumer’s requirements is a standard CC document named as Protection Profile (PP). Developer is the entity responsible for implementing the security requirements of PP. Developer defines security components to meets the IT security requirements of PP and provides details of Security Functional Requirements (SFR) in document named as Security Target (ST). CC has thoroughly identified common IT security requirements and grouped them into categories formally known as Functional Classes. Both consumer and developers take guidance from these classes to specify security requirements and security components respectively. Evaluator is the entity, basically a third part, responsible for assuring the accurate implementation of security components and mapping of SRF in accordance with PP. Degree of formality in evaluation of the TOE is based on CC defined criteria named as Evaluation Assurance Levels (EALs). Products are being evaluated at predefined EAL. CC has comprehensively marked the Security Assurance Requirements (SAR) that work as guidelines for both developers and evaluators. Now the report will define some of the key terminologies of CC after that SFR, SAR and EAL will give an overview of CC. 3.1 Literature Source: Main source of this chapter is Common Evaluation Methodology Version 3.1 (CC/CEM). (Defence Signal Directorate et al, Common Criteria, 2006). CC V3.1 has three parts. Its part 1 is related to introduction and general model, part 2 is about security functional requirements and part 3 is concerning to security assurance requirements. All definitions, concepts and terminologies are borrowed from this CC standard document. I did content analysis of the documentation and extracted information, terms, classes and examples. I restructured the requirement and wrote technicalities in simple and understandable way. So if reader wants to find any reference of this chapter he/she can directly look in to CC documentation. 11 A Six Sigma Approach to Assure IT Security 3.2 Definitions: This section will explain some of the basic definition of CC and these definitions will help in understanding of upcoming technical details. 3.2.1 Stakeholders: CC has three stakeholder consumers, developers and Evaluators. Consumer is the entity interested in achieving CC certification. These are companies owning IT products like Microsoft or users who like to operate IT product securely. Developer is the entity responsible for building IT products and defining controls for security threats. Here whole software project team is entitled as developer. Evaluator is the entity that accredits the work done by developers to full fill security requirements of consumers according to CC recommendations. Common Criteria Testing Laboratories (CCTL) are the evaluator (NIAP-CCEVS, 1999). These laboratories are authorized under the contract of Common Criteria Recognition Arrangement (CCRA), an agreement to accept mutually certified products. (Mike & Fiona, IT Security Assurance, 2006). CSEC (pronounced as see-sec) is the certification laboratory in Sweden, which is a member of CCRA. (FMV, CSEC – The Swedish Certification Body for IT Security). 3.2.2 Target of Evaluation Previously the term used for Target of Evaluation was “IT Product”. But according to CC the product to be evaluated may be software, hard ware and firmware. It can be an IT product, a part of IT product and a set of IT products. There may be different mode of IT product as for evaluation. Different configurations of a product can change the security claim made by vendors. Target of evaluation is a generic name give by CC, which covers all these aspects. Microsoft Operating system, Windows Server 2003 is evaluated at EAL level 4. (NIAP-CCEVS, Validation Report Microsoft Windows 2003 Server, 2005). The TOE in this case was a stand alone Personal computer with Windows Server 2003 installed on it. Open Solaris 10 is evaluated at EAL level 4. The TOE in this case includes Open Solaris installed on Personal Computers in local network environment. Its configurations include a small local area network with two servers and two workstations (Sun Microsystems, Solaris 10 03/05 Security Target, 2006). So the TOE in this case is networking environment with servers and workstations. 3.2.3 Package: CC communities of interest express their security needs in the form of security requirements. These security requirements are grouped on the basis of common objectives. These groups are named as packages. All CC stakeholders use these packages as guidance documents to find security requirements, security objectives and assurance 12 A Six Sigma Approach to Assure IT Security requirements. Security requirements are further classified at granule level in Classes, Families and Components (They will be explained later in this chapter). There are two categories of packages based on functionality. 3.2.3.1 Functional Package: Functional package contain Security Functional Requirements (SFR). Consumer uses these packages to write Protection Profile (PP) and Developer uses them to identify security components and writing of Security Targets (ST). Functional requirements cover need of identifying security audit events, user data security, identification and authentication requirements, security management requirements, privacy requirements and some of user specific requirements. 3.2.3.2 Assurance Package: Similar to functional package, assurance package consist of Security Assurance Requirements (SAR). These requirements are useful to both developers and evaluators. Developers get the guidance of their line of actions, component presentation and evidence collection. All these developer actions are in the end auditable events. Evaluator action elements focus on two aspects one is the assurance of PP and ST and second is verification of TOE conformance with SFR and SAR. Examples of assurance packages are EALs. 3.2.4 Protection Profile: PP is a standard CC artifact used to describe the type of TOE. Just like ST describes the TOE (For example Windows XP) PP describes the TOE type (like OS). It specifies the common security requirements of the TOE. It is a general document that can be reused for other TOEs of such types. PP is evaluated against APE (PP assurance class) to assure that it is consistence, complete, technically sound and suitable as a template for STs. PP artifact is organized in a predefined way elaborating introduction, Conformance claim, Security problems definitions, Security objectives and security requirements. 3.2.5 Security Target: ST is a standard artifact like PP to define TOE and TOE security requirements. It specifies “What is to be evaluated” or it is considered as an agreement between commonly accepted security requirements of developer and evaluator. After evaluation of ST it serves as an agreement between developers and resellers. Consumer can trust on reseller claim of security requirements mentioned in ST because ST is evaluated. 13 A Six Sigma Approach to Assure IT Security 3.2.6 Class Structure: Security requirements are grouped at different levels based on common goals, similar set of behaviors and to achieve a specific security objective. This grouping of requirements is hierarchical. Element is at the lowest level of security requirement. It is the indivisible statement for security testability. Similar elements are grouped together and form components. All elements in a components share goal of component but they may be different in rigor and emphasis. Similar components are grouped to form families. A family may contain components at linear hierarchical and individual levels. Hierarchical components in a family give sophistication in security requirement assurance and they are dependent. Similar families are grouped to form a Class. Class is an abstract level of security requirements. Class Family Compone Elemen Figure 3 Class Structure 3.3 Functional Classes: In CC documentation Part 2 there are number of functional classes mentioned to identify security requirements. Here we will discuss these classes and their area of scope. These classes cover security audit requirements, security data protection requirements, secure communication, identification and authentication requirements, security management and some of the user specific security needs. In addition to security requirements classes also state management responsibilities and audit events in given set of security requirements. Security audit class gives details of security audit requirements. It has number of families and components. It enforces the functionality of security alarm in case of security breach. Data generation activity should be completed before actual start of audit and the scope of data generation depends on the level of audit events. Based on 14 A Six Sigma Approach to Assure IT Security minimum, basic or detailed audit levels, data is generated accordingly. User generating data must have an identity association with data generation which will be used in audit activities for tracing events and responsibilities. Security audit data analysis is a critical task. All potential violation must be analyzed to find the root cause of anomaly. Audit data must be securely protected and unauthorized access to data must be avoided. Only authorized persons should be allowed to record, modify and store audit data. Audit data recovery mechanisms should be introduced in case of data loss and controls should be defined to avoid any kind of data integrity violation. Non repudiation of origin and non repudiation of receipt are communication security requirements of TOE. These requirements are explained in Communication class. Based on the nature and sophistication of application or TOE the proof of origin and receipt can be set optional or mandatory. User data is one of the critical assets in any system. User authentication policy, access control functions and data exchange rules are elaborated in User data protection class. This class requires developers to develop controls for residual information protection, information flow control protection with in TOE, maintain data integrity, and secure import and export of data from TOE. Authentication and identification requirements of TOE are addressed in separate class. Authentication class requires security functions and controls for un-forgeable authentication mechanism. User or identity is associated with security parameters or roles after careful observation of its credentials. Counter controls should be implemented in TOE for unsuccessful authentication like termination of session and such controls should return limited feed back. Subjects acting on behalf of users’ security attributes must be identifiable. Authentication mechanism should adopt multiple verification procedures. Authentication secrets should be managed individually by users for e.g. PIN Code or passwords. Single sign-on and re-authentication facilities should be put in place to support secure authentication. In order to manage security requirements and classes CC has a Security management class. This class is used to design functions for data management, attribute management and security function management. Security data management includes Banners. Access control list and roles are examples of attributes. Security attributes default initialization must be secured and new values should be audit before assigning to attributes. Security attributes may have limits and functions should be managed to control data limits. Control should be defined to make appropriate counter actions when data reaches up or exceed limit. Attribute values should be managed with respect to state of TOE. For example, a project manager in a project is allowed to access critical information of system as long as project is active. Revocation of roles, access controls, subjects, objects and revocation rules are critical security management function. Revocation of certificates and publishing of revocation list are examples of revocation management activities. 3.4 Assurance Classes: Assurance classes are useful for both developers and evaluator in a way they work as guidelines for developer actions and the course of actions for collecting and presenting evidence documents. Evaluators use assurance classes for two reasons, one is to validate PP and ST and second is to verify TOE conformance with SFR and SAR. Assurance class structure is similar to functional classes. The only difference is that assurance class 15 A Six Sigma Approach to Assure IT Security components are all hieratically dependent. That means assurance class components specify more and more assurance requirements if you keep on increasing component level in TOE assurance classes. Names of all assurance classes, families and component are given in Appendix A. PP Evaluation class (abbreviated as APE) demonstrates PP requirements. PP documentation should state PP type, PP reference that uniquely identifies PP and TOE overview that summarizes usage and security features of TOE. Developer must clearly demonstrate conformance claims, use of CC version, extensions, threats, problem statements, assets and advised actions. These requirements must be stated in a way that is canonical and un-ambiguous. Security objective rationale should be backward traceable to source of threat and all of their dependencies should be justifiable. ST Evaluation class (abbreviated as APE) helps in defining TOE security specification with architecture design. This design and specification help evaluators in evaluating how the TOE meets SFRs and how the TOE protects itself against interferences and logical tempering. When documenting security functionality of TOE, two properties are to be considered by the developer. One is the evidence that security functions work correctly and the other is the substantiation that TOE can not be used in a way it can be corrupted or bypassed. Development class defines complete security refinement process. Functional specification, design details, implementation representation and policy modeling try to assure the correct functionality of TOE. On the other hand TOE internals and TOE architecture components are responsible for soundness of the TSF (TOE Security Functionality). These requirements can be expressed at different levels from informal to semiformal and formal to achieve high degree of assurance. Informal specifications either they are functional, design, implementation or policy are presented in natural language with common notations, grammar and syntax. Semiformal are presented with glossary of terms, standard format and templates. Presentation includes data flow diagrams, state transition diagrams or entity relationship schemas. Formal representations are notations based on well defined mathematical concepts with explanatory (informal) support. Security Functional specification is helpful in identifying TOE security functional interfaces (TFSIs), integration among and across TFSIs. TOE design is dependent on SFR, detailed information provided in SFR will result a detailed design explanation. Design is further decomposed at two levels subsystems and modules. Subsystems are at higher level of abstraction while modules are at lower level. TFSIs are used when two systems or two modules interact with each other. Life Cycle Support class is essential to maintain discipline in process of refinement. It requires management of Configuration items using well defined configuration management system (CMS). Configuration items consist of TOE, evaluation requirements by SFR, the part of TOE, the implementation representation, security flaws and development tools. Configuration Management (CM) reduces the likelihood of accidental and unauthorized modification. Source code version management and modification tracking are critical problems for developers when they work in large projects or in different modules of same project. CM tools are also useful in tracking modification during development and support activities. Test class provides assurance that the TOE behaves as described in TOE design and Functional specification. Analysis of developers’ identified test cases ensures the coverage of functionality. Evaluators perform independent testing of modules and subsystems with different 16 A Six Sigma Approach to Assure IT Security configuration of TOE. Vulnerability Assessment class gives criteria for identifying vulnerabilities, analyzing vulnerabilities and assessing exploitation by performing penetration testing. 3.5 Evaluation Assurance Levels: EAL is the level of assurance that CC accredits to an IT product. In commercial market EAL certified products are considered as security trademark. The process of EAL certification is based on the EAL requirements specified in CC documentation Part 3. EAL utilize assurance families and their components requirements to gain assurance. As mentioned previously in assurance class section that assurance components are hieratical in nature and higher level component impose more and more assurance requirements so mature EAL levels use higher level components. More precisely one EAL does not include more than one components of each family. Complete chart of EAL levels and assurance families with components is mentioned in Appendix A. Among all the CC constructs only EAL is augmentable according to customer security requirements and TOE specification. An augmentation with added components in an EAL adds more reliance and it is called EAL positive. After accreditation of EAL the maintenance requirements are also accountable. There are total 7 EALs and are defined in CC. The assurance requirements and level of trust increase from lower to upper level. EAL 1: Functionally Tested. It is applicable where confidence of correct operation is required and threats are not seriously addressed. ST of EAL1 only states the SFR that TOE must meet rather than deriving the security requirements from threat analysis, organizational security policies (OSP), and through security objectives. EAL 2: Structurally tested. It is applicable where developer has limited rights on TOE. Developers are required to state design information and test results so that TOE structure can be assured. In EAL 2 assurance is achieved by SFR analysis, guidance documents reviews, TOE architecture investigation and developer testing scrutiny. Secure delivery procedures and CMS are used to get TOE integrity assurance. EAL 3: Methodically tested and checked. It is applicable where moderate level of independent security is required. It involves substantial reengineering at design stage without any modifications of existing development strategies. In addition to EAL 2 assurance requirements EAL 3 requires development environment control analysis, complete testing coverage of security methodologies and collecting evidence that TOE will not be tempered during different phases of development. EAL 4: Methodically design tested and reviewed. It is applicable where moderate to high level of assurance is required. EAL 4 is the most economical and feasible assurance level for the IT products available in market. That’s the reason it is the highest achievable level of CC by any IT security product. It is achieved by re-engineering based on already used commercial development practices. From technical point of view other than EAL 3 requirements EAL 4 requires complete interface analysis, modular level description of TOE, use of automation tools in CMS, implementation detains and developers evidence of vulnerability analysis search. 17 A Six Sigma Approach to Assure IT Security EAL 5: Semi formally design and tested. It is applicable where high level of independent assurance is required in planned development environment. Developers state semiformal specification, explained in development assurance class, to portray modular TOE design. In EAL 5 maximum assurance is achieved through security engineering based on rigorous development practices. Other than EAL 4 requirements EAL 5 requires an independent vulnerability analysis, moderate level penetration attack testing, assurance by development environment control, semiformal design description and comprehensive configuration management. EAL 6: Semi formally verified and tested. It is applicable where TOE has high risk and asset value justifies additional cost for evaluation. Assurance is achieved by engineering of techniques in rigorous development environment. In addition to EAL 5 requirements EAL 6 requires formal security model of TOE, semiformal functional specification, TOE modular or layered design, more comprehensive analysis and structured representation of implementation. EAL 7: Formally verified, design and tested. It is applicable where extreme high risk is involved and high value of asset justifies the cost. Other than EAL 6 requirements EAL 7 requires comprehensive analysis of specification using formal representation, formal correspondence and inclusive testing. 18 A Six Sigma Approach to Assure IT Security Chapter 4 Six Sigma (SS) 19 A Six Sigma Approach to Assure IT Security This chapter aims to enlighten quality practices introduced by Six Sigma. It’s a management strategy that maximizes customer satisfaction and minimizes defect rate. Six sigma methodologies provide basis to monitor, control and analyze organization and project goals. These methodologies help in classifying critical and non critical tasks, transform qualitative measures in quantitative procedures and define quality metrics. Cause and effect diagram used to identify risks and their impact, failure mode effect analysis (FEMA) to identify detective controls and statistical tools to measure performance level are included in six sigma kit to ensure best quality assurance practices. Basic principal of SS is to define quality functions and identify inputs and outputs of functions. Let suppose Y represents a process than effectiveness of this process will be dependent of some critical factors can be represented as x1, x2….xn. These are driving factors of the functions. These factors will become the inputs of quality function. Y = f (X) Y = f (x1, x2……xn) For example Y represents an audit process in a company than sampling techniques, defect sheets and auditor recommendations are some of the critical factors that can be used to measure audit process output. From an analytical point of view Six Sigma stands on three pillars (Craig Tonner & Pradeep Patra, Six Sigma, 2003). 1- Methodologies 2- Metrics 3- Philosophy 4.1 Methodologies: They are the road map of structural approaches for solving problems. Most popular six sigma methodologies include DMADV and DMAIC. 4.1.1 DMADV Frame Work: DMADV is used when a product or process is being developed first time (Kerri Simom, DMAIC Versus DEMADV). Define: It defines the high level goals of an organization. These goals represent the strategic plans, vision and corporate policies like high return on investment and cost. At project level the goals are reduction in defect count and minimizing variation. Measure: It is the process of measuring customer requirements and needs. More clear the customer requirements lesser are the chances of rework. Analyze: Identifying and analyzing the ways of fulfilling customer needs. Analysis is used to prioritizing the best options and identifying pros and cons of these options in the given scenario of customer needs. 20 A Six Sigma Approach to Assure IT Security Design: This process gives technical details of functions to fulfill customer needs. These are the operational details and give particulars of functional interdependencies. Verify: Verifying the performance of designed function in design phase and evaluate it according to customer needs and defined requirements. 4.1.2 DMAIC Frame Work: DMAIC is used when any product or process is already developed but not meeting the needs of the customers. It is helpful in identifying gaps of operational areas and recommends corrective actions. It is also considered as problem solving methodology and similar to old quality improvement practices like PDCA (Plan, Do, Check, Act) and PDSA (Plan, Do, Study, Act). People claim of adopting using six sigma in organizations are most of times pointing to using of DMAIC framework (Paul A. Keller, Six Sigma Demystified: A self teaching guide, 2005, p 50). Define: Define problems and identify internal and external customers. Internal customers are the internal departments of organization taking part in lifecycle of organizational activities. In a supply chain management system sales department is the customer of production department and production department is the customer of inventory department. Identifying quality requirements and problems of internal customers is also part of define phase. Project charter is launched at this stage that gives details of resource allocation and scope of projects. Project level managers known as Black belts and operations level managers named as Green belts are designated with there ownership and assigned responsibilities. Project starting and ending dates are critical project indicators in project charter. Measure: Processes for the resolution of problems identified at define stage are delineated at manage stage. Standard measures to appraise performances of these processes are identified and grouped together in the form of metrics. Metric can fairly represent the performance of process if standard measures are true representative of key process indicators. Metric should be specific, measurable, accountable, relevant and timely, abbreviated as SMART (Dave Trimble, How to Measure Success). SS metric is based on three factors cost, quality and schedule. Critical to Quality (CTQ) factors are those that are directly related to operational personal and they make a direct impact to functional requirements. Critical to Schedule (CTS) factors effect the delivery time of the processes (Paul A. Keller, Six Sigma Demystified: A self teaching guide, 2005, p 85). The metric is visualized as a flow down function of big ‘Y’s dependent on small ‘y’s. Y1 = function of {y1, y2… yn} Y2 = function of {y1, y2… yn} ……………………… Ym = function of {y1, y2… yn} 21 A Six Sigma Approach to Assure IT Security In above functions big Y represents the standards measures and small y are the low level factors, causes or reasons that impact on big Y. Both big Y and small y are defined at different business, operational and process level. Some SS tools are available at this stage like flow chart and histogram to evaluate process definition and to measure process baseline estimate respectively (Paul A. Keller, Six Sigma Demystified: A self teaching guide, 2005, p 86). Analyze: This stage introduces value stream analysis technique. This technique refers to identify the activities, determined by the customer, that add value to the product and service. Small ‘y’s, that drive the metric functions defined in measure stage, are identified in this stage. Analyze and reduce the non value added services like decrease difference among customers (internal and external), less departmentalization etc. One of the critical activities of analysis stage is source variation analysis. Control chart is a tool used to evaluate variation. Sources of variation may be common reasons and special reasons. Signing ones signature 10 times will give a common variation each time. Bumps in elbow during signing will cause high degree of variation. So bumps are the special reasons of variation. Identification of special reasons prior to occurrence can help in reducing variation. In some cases these special reasons may be critical like bumps in elbow of person cutting diamonds. In order to identify sources of variation 5Ms and E are used, process Method, its Materials, the Manpower, Machine, Measurement techniques and surrounding environment (Paul A. Keller, Six Sigma Demystified: A self teaching guide, 2005, p 115). Cause and effect diagram is yet another tool to analyze variation causes and helps problem solving team in brainstorming. Fish bone structure of cause and effect diagram identifies root causes. Shipment Delay High Defect Rate Production delay Transportation Delay Customer Dissatisfaction Poor Resource management Low Quality Figure 4 Cause and Effect Diagram Immature Specification SS tools that play role in effective completion of activities recommended at this stage include Failure Mode Effect Analysis (FMEA) to determine high risk analysis and SPC 22 A Six Sigma Approach to Assure IT Security (Statistical Process Control) control chart to identify common and special causes. In addition to these tools Six Sigma also recommends the generic templates to represent tools output in a comprehensive way. Improve: Problem solving team need to be innovative in finding new ways of eliminating defects and improving processes. New processes should be safer, faster and better in counter measuring defects. FMEA and cause and effect diagram from analysis stage becomes starting point for improvement processes. Improvement process should be easy to useable and easy to implement able in the existing design. Control: It enforces the implementation of processes and controls for maintaining future performance. It is a continuous process that keeps on monitoring the performance and compares it with expectations. 4.2 Metrics: One of Six sigma success factor is its way of transforming processes into performance measures. In implementing new processes, methodologies and procedures for meeting customer requirements or making improvement strategies for existing actions quality should be measurable. Identification of all possible defect opportunities is the activity done for achieving this requirement. For example if there are 10 questions than there will be 10 defect opportunities. If 1 question is of multiple choices and there are four options A, B, C and D than Defect Opportunities will be 13, 9 singles and 4 options for multiple type question (Six Sigma SPC, DO-Defect Opportunities). These defect opportunities will be used to calculate Defect per Opportunities (Six Sigma SPC, DPO-Defect per Opportunities). The formula for DPO is Defect per opportunities = No. of Defects / No. of units * No. of Opportunities Defect per Million Opportunities (DPMO) is the standard way of evaluating performance in Six Sigma (Six Sigma SPC, DPMO-Defect per Million Opportunities). The value 3.4 Defect per million opportunities is the comparable unit of measure. Any six sigma process defect count should not exceed from the value of 3.4 value based on that standard the quality of the process can be measured. DPMO can be calculated as DPMO = DPO * 106 4.3 Philosophy: The SS is not only a methodology or supportive tool but also a thought, more precisely a philosophy. It tries to find out customer requirements and reduce gaps in implementation of the requirements and minimize variation in processes. It tries to change the culture of 23 A Six Sigma Approach to Assure IT Security the organization and project team and let every one think about quality. Quality is not the responsibility of just quality department or quality engineer but it is a combined effort of all team members. Launching SS as a separate project for achieving quality and making black belts and green belts responsible of quality at different levels is the distinct way of implementing quality system. Senior management contribution, training of employees and quality evaluation at granular level are the objectives of any quality systems. The SS adds value into these objectives by giving measurable and accountable ways of evaluating performance. Data driven techniques from live projects, graphical data representation and utilization of data in generating different charts to analyze defects are strengths of SS. 24 A Six Sigma Approach to Assure IT Security Chapter 5 Protocols 25 A Six Sigma Approach to Assure IT Security This chapter is the core of the thesis in which we will try to suggest some IT security protocols. This chapter will first create a base for protocols by giving content analysis of commonalities among two standards. After identifying the joints where Six Sigma can get fit into Common Criteria, we will give details of protocols. Commonalities of both standards will be covered based on criteria like audience, abstraction level, focused objectives, formal methods, customer focus and shared philosophy. 5.1 Comparison Criterion Although SS and CC are being followed in different area but based on some business, customer and IT governance requirements we have tried to pinpoint commonalities. Comparison criteria of our commonalities identification is based on 6 pillars that are defined here. Abstraction level: This criterion will be helpful in looking at high level coverage, scope, and areas of strength and weaknesses of both standards. Audience: This criterion will give understanding of stakeholders and their interests. It will also be helpful in defining common roles and responsibilities. Objective: Objective of both standards will be explained to identify common goals and finding any similarities in procedures required to achieve the goals. Formal Methods: This criterion will focus on formal requirements of both standards and finding any possibility of using formal methods interchangeably. Customer focus: Customer is the critical actor in whole scenario to focus quality and security. This comparison criterion will be helpful in identifying roles and importance of customer in process of implementation of both standards. Philosophy: By keeping an eye into requirements, roles, methods, legalization, culture and basic concepts this criterion will compare the analogous philosophy of standards. 5.1.1 Six Sigma: Six Sigma is a frame work purely focuses on quality. These quality improvement procedures are useful in identifying root causes of quality problems independent of nature of work like management, finance or IT. If we look into SS according to our comparison criteria we can come to conclusion of SS utilization in filling gaps of CC. 26 A Six Sigma Approach to Assure IT Security Abstraction level: SS covers both quality achievements in already followed procedures and in newly developed methods. It gets start from the very start of process where businesses comes in contact with customers and keeps on building a continuous bridge till the delivery of a best quality product. Followed by natural flow of work from define, measure, analyze, improve and control SS deals with generic actors like customers and give support of standard statistical tools. Its recommended techniques like FMEA and cause and effect diagram that are independent of any precise workability. Use of SS for IT is becoming popular like Sumit Kumar Jha says “Information Technology Infrastructure Library (ITIL) and Six Sigma make a winning combination to IT.” (Sumit, ITIL and Six Sigma Make a Winning Combination for IT). Similarly Six Sigma Software metric definition (David L. Hallowell, Six Sigma Software Metric) is the evidence of six sigma abstraction and provide traces of successfulness of SS for improving CC. Audience: Six Sigma audience are the experts and organization facing low quality problem in there product and services. Project managers, functional managers, architects, quality experts and auditors are included in Six Sigma audience either they are dealing with a production improvement issue, call center service perfection or IT quality enhancement. SS has its own defined roles that are assigned in existing management structure as sponsor, leaders, champions, master black belt, black belt, green belt and process owners (Isixsigma, Six Sigma Roles and Responsibilities). These roles are the audience of SS in live projects. Objective: Objectives of SS are to achieve best quality by identifying root cause and eliminating unbeneficial activities. It minimizes the variation of work. SS methodology and tools empower the SS team for achieving the objective and gives standardization of implementation. Formal Methods: SS success is hidden in its formal tools and templates. These tools are quantitative in nature, sampling techniques and statistical methods are used to accurately measure the quality levels. SS templates are standard artifacts that are useful for result interpretation. Due to time and efforts of SS gurus these tools and templates are mature enough to 27 A Six Sigma Approach to Assure IT Security achieve formal authentication. SS metric, CTQ factor identification, mathematical transformation of functions, cause effect diagram and FMEA are SS formal tools. Customer focus: SS focuses customer at all levels of frame work. It not only identifies the external customers but also gives importance to internal customers. This concept of internal customers helps in introducing quality with in all processes and department. In order to gain competitive advantage in business and to avoid misconceptions in artistry kind of work like software development customer focus can play the role of light house. Philosophy: SS is launched as a project in parallel to ongoing project and work flow. This project aims to continuously strive for achieving best quality by identifying improvement chances. In order to gain input of individual efforts and to give a sense of responsibility for quality improvement SS launches quality training programs. It helps in minimizing the ideology that quality is the responsibility on only quality department and introduces personal contribution to achieve quality. 5.1.2 Common Criteria: Abstraction level: Common Criteria gives a very detailed analysis of security requirements. It organizes requirements in different classes and gives in depth technical details that can be helpful for security coverage. Its strength lies in its documentation and technical artifacts. According to CC V3.1 under scope heading it is mentioned that CC does not support administrative security activities and procedures. However it is also recognized that this administrative security pertaining to significant security achievement (Defence Signal Directorate et al, CC Part 1: Introduction and general model, 2006). Further neither CC has recommended any software development methodology nor has defined any mapping among existing methodologies and CC classes. Although it is accepted CC only gives requirements but for gaining any advantage of these requirements practical implementation of requirements is indispensable. Audience: CC audience, same as the audience of this thesis in heading 1.7, is the software project development team. Software developers for whom development classes exist but it is not clear in which stage of software development these requirements will be deployed. 28 A Six Sigma Approach to Assure IT Security Software quality experts for whom testing classes do exists and formal testing tools and methods are required but no formal ways are exemplified. Auditors for whom audit reviews and in-production audit testing is required but no sampling and data collection techniques are mentioned for coverage assurance. Objective: CC is aimed to fulfill security needs of Defence organizations. It is also serving as a security assurance criterion for IT products. Due to critical nature of information security different levels of functionally, structurally, methodically, semi formally and formally; verified and tested requirements are established. Formal Methods: CC requires a lot of sophistication and formalities in tools and methods. Its different levels of formalization can be observed in its EAL levels (Heading 3.4). It gets start from function evaluation, then look into methods, then tries to analyze at modular level and in the end it demands semiformal or formal methods and tools for security implementation and testing. Unfortunately there are no tools mentioned for achieving these requirements. In the field of IT which is still in the process of getting mature there are no commonly accepted formal procedures, tools and templates. Under these circumstances adaptation of mature tools and techniques from SS established framework can be a positive sign of progress. Customer Focus: CC focuses external customers and their security requirement in an ample way. However demarcation of internal customers to back tract defects and to identifying root causes of problems, CC requires some improvements. Due to different phases of software development life cycle and because of modular nature of development in which teams are working on different modules, that is in the end comes out as an integrated product, the focus on internal customers is essential for quality improvement. Philosophy: New security threats, emerging needs of security controls and lack of security awareness provide the basis to design a set of security necessities. The set that identify and categorize set of security requirement with different levels of security. CC is good in achieving this goal and its idea of giving a detailed analysis of security is fruitful. From practical point of view this philosophy is achievable with administrative support, security awareness trainings and by establishing security policies. 29 A Six Sigma Approach to Assure IT Security 5.2 Protocols: Based on above comparison criteria we are going to suggest some protocols. Objective of this thesis is to focus on at least three areas of CC for improvements. These areas are finding methodologies for CC implementation, tools for formal requirements and defining a philosophy for gaining best results. So we are going to define protocols for each of this intent. 1- Methodology 2- Metric 3- Philosophy 5.2.1 Methodology: DMAIC methodology of SS can be of use in improving CC security assessment and implementation. Before suggesting improvements in CC we have to look into standard CC implementation. From our previous study of CC we have seen CC is lacking in implementation details. Therefore recommendation of some software development methodologies, for giving technical implementation details, before suggesting improvement is necessary. There are number of SDLCs being followed like waterfall, prototype, rapid application development and common assembly model (Stylusinc, Software Development Life cycle). Some modern development methodologies like agile and pair programming are also serving for same purpose. CC sequential nature of starting with PP, ST and than follow EAL seems aligned with some of methodologies like waterfall and they are conflicting with modern methodologies like agile development because of extra documentations. Keeping these concerns in mind some organizations have developed there own security development models for successful implementation of CC. Microsoft has development Security Development Lifecycle (SDL) for their products to meet CC needs (Steven B. Lipner, Market Adoption of Common Criteria, 2005). Here we are going to suggest a Secure Software Development Lifecycle (SSDL) that will be helpful for getting implementation details of CC. Table 1 shows different phases of SSDL. 1st column shows different phases of SSDL, 2nd columns shows actions needed to be performed in that phase with CC consequences and 3rd column give details of CC classes and families that are taking part in this phase. There is a one-to-one mapping among 2nd column and 3rd column bullets. SSDL Phases Requirements • CC consequences Gather functional requirements, customer security requirements and CC security requirements. • Utilization of CC Classes Identification & authentication class, communication class, 30 A Six Sigma Approach to Assure IT Security • • • Analyze security policies and governmental legislations. Document requirements using formal description language Generate documents like PP, Functional Specification, Project Plan, Security Testing plan and base line all documents in configuration management system (CMS). Design application architecture to fulfill functional requirements and implant security requirements in the architecture. Draw High level technical design and Identify all modules, functions and internal & external interfaces. Generate security target. Document architecture, high level design specifications using formal design tools like UML and baseline all documents in CMS. Writing low level technical details of identified modules, functions and interface and Implementation of requirements. Vulnerability identification at technology level. i.e. buffer overflow. Unit testing, integration testing, and interface testing. Document low level technical detail, code, and test specification using formal languages like UML and baseline all documents in CMS. Identify functional and security testing scenarios, write test cases and generate test data. Perform threat modeling and penetration testing against identified security requirements by executing test scenarios. user data protection class. User data protection class (Access control policy & information flow control policy) Protection profile class Life cycle support class (CM capabilities, CM scope) Development Class (Design Description, Security Architecture) Security Management (Management of security attributes, management function specification) Security Target Life Cycle Support (Development Security, Life Cycle Definition) • • • • • Design • • • • • • Implementation • • • • • • • • Development Class (Implementation representation.) Vulnerability assessment class Test (Independent Testing) Life Cycle Support (Development security) Verification • • • • • Test Class(Test coverage, test depth, functional tests, independent test) Vulnerability analysis Security audit (Audit automatic response, sec. 31 A Six Sigma Approach to Assure IT Security • • Generate audit data and perform internal audit test. Document testing and auditing reports and baseline in CMS. • • audit data generation, sec. audit analysis, sec. audit review, sec. audit event selection, sec. audit event storage) Life Cycle Support Guidance document (Operational user guidance, preparative procedures) Life Cycle Support (Delivery) Support • • Application deployment and application configuration settings according to production server. Customer guidance documents. • Table 1: SSDL DMAIC as written in chapter 4 Six Sigma, a methodology for already developed processes and products can be useful in improving SSDL. Amber Gravett and David Dean Tuma did some work in fine-tuning of software development using DMAIC in article “Debunking IT Isolation in Search of Quality and Savings” (Amber Gravett and David Dean Tuma, Debunking IT Isolation). Now we are going to suggest same MAIC methodology for fixing any security bug found in application and gap found in process defined above. Table 2 gives details of using DMAIC for bug fixing and process improvement. 1st column shows DMAIC phases, 2nd column gives action to be performed at this stage and 3rd column is for SSDL phases and CC classes take part in the given phase. DMAIC Define • • • • Actions Define security breaches and identify • possible reasons. Identify infected interface, functions and modules using requirement metric. • Identify associated assumptions, guidance documents and policies. • Identify test set, regression area and coupled functions. SSDL Phases and CC Classes Support, verification and implementation phases of SSDL will be considered for initial forensic collection. Identify related security requirement class. Development, life cycle support, Test and vulnerability analysis classes will be used in define phase. Design. Implementation, verification and support phases will play part in critical factor identification. 32 Measure • • Create CTS metric for measuring administrative, implementation, testing and design factors. Perform mathematical modeling of factors by creating Big Ys and small ys. • A Six Sigma Approach to Assure IT Security • Big Ys are like non addressed policies, no built-in security support functions in technology, or missing test scenarios. Small ys may be conflicts between organizational and governmental policies, no support of sand box or buffer overflow or ripple effects of fixed bugs. Identify internal customer chain and for every joint of chain identify Supplier, Input, Process, Output and Customer (SIPOC diagram). Perform value stream analysis in which small ys are analyzed to identify gap between actual customer requirements and stated requirements, between stated requirements and understanding of business analysts and architects, between application architecture and understanding of developers and implementation, between recommended configurations and deployment settings. Perform Variation factor analysis and identify critical factors like use of language that does not support garbage collection and allow memory leakage i.e C, C++ Draw cause and effect diagram and FMEA for brainstorming. • • CC classes are useful in identifying Big Ys. CC families, elements, components and there dependencies will be effective in identifying ys. • • Analyze • • • • • • • • Improve • • • Based on cause and effect analysis • and FMEA easy, feasible and implement able solution should be recommended. • Recommendation of more than one testing cycles is the solution of avoiding ripple effect caused by last minute changes in requirements. Focus VOC in each phase of SDLC and beta testing in verification phase. • Avoid wasteful duplication of code in implementation phase. SIPOC analysis of each SSDL phase may support in reducing gaps. Mapping of ST and PP is a good source of identifying gaps between requirements and implementation. TOE analysis can identify configuration and development gaps. PP, ST, high level technical design, technical specification and test case walkthroughs among project teams are useful in critical factors identification. Suggest Improvement in the phase of SSDL that actually cause problem. Particularly verification and implementation phases will be addressed in improve phase for avoiding security breaches. Customization of CC components and dependencies of components can be 33 A Six Sigma Approach to Assure IT Security refined. Support phases of SSDL should be monitored carefully. Security audit and User guidance classes of CC are aligned with this activity. Control • • • • Continuous monitor application after deployment for any security vulnerability or new attack. Train stakeholders of application and give them security awareness. User guidance and continuous audit approach is beneficial for control. Provide live customer support and new patches for upcoming vulnerabilities. • • Table 2: DMAIC implementation 5.2.1.1 Implementation Exemplification: There are three basic categories of security requirements confidentiality, integrity and availability. Suppose the case of a Customer Support System (CSS). In application of CSS availability of system is a highest priority requirement. Similarly in online shopping systems integrity of data and customer credentials protection are essential security requirements. CC communication class has two families’ non-repudiation of origin and non-repudiation of receipt that directly address integrity requirements. Banks online services have security requirements of data integrity and authentication. After identifying the category of application and its general security needs a security analyst need to find specific customer requirements for example identify the kind of authentication mechanism suitable for application access in given customer scenario. Biometric authentication, smart card authentication, use of certificates and password protection are different authentication solutions that can be used for this purpose. Depending on application, customer requirements and feasibility of implementation best possible mechanism can be adopted. Design phase gives further design level details of these identified requirements. For example if a bank online service use certificate 1 authentication, may be a third part like VeriSign is involved in issuing certificates. Use of a certificates or biometric authentication completely changes the architecture of application so brief design description and documentation of mechanism is required at this stage. Implementation phase describes functions and code level details. For example either some built-in or user defined cryptographic functions are used. Implementation documentation is a good source of defining controls for implementation level vulnerabilities like buffer overflow. It’s a common application problem and need to be addressed with out identifying its security requirement. Some compilers like java supported compiler take care of such vulnerabilities and some times special instructions are required in code to avoid this buffer over flow. In Verification phase a test engineer designs test for all possible scenarios. Fore example in password protected CCS or online system test scenarios are defined for verification of upper and lower limit of password 1 VeriSign is a third part serve as certificate issuing authority. 34 A Six Sigma Approach to Assure IT Security digits. Test scenarios cover all functional requirements identified in requirement phase like certificate usage and non functional requirements like controls for buffer overflow and SQL injection (Microsoft, SQL injection, 2005). After launching the application in production environment if some security breach occurs above suggested DMAIC methodologies can give better recovery mechanism. Like in first phase of improvement, problem needed to be defined and its scope should be clarified. Collection of initial forensic like bug screen shorts, application configuration settings and pre conditions of application crash can be helpful in defining the problem. For example source of an unauthorized access to system be either a registered user or a non registered user. Log history is the prime source of identifying the answer. If this is a non registered user than the problem will be a vulnerable authentication mechanism if it is a registered user than problem will be in access rights management. After defining the problem, measure of possible causes and critical factor is the next step. For example in case of vulnerable authentication mechanism causes may be social factors like week passwords and technological issues like buffer overflow and SQL injection. At this stage a Cause and Effect Diagram (CED) can help in brainstorming of factors. Figure 5 shows cause and effect diagram for vulnerable authentication. Unprotected Cookies Cross Site Scripting Certificate Theft Technological Issue Buffer Overflow SQL Injection Vulnerable Authentication Plaintext Password storage Masquerading Session Hijacking Password written on computer desk Unawareness of password selection tips Password Sharing Social Factors Figure 5: Vulnerable Authentication CED 35 A Six Sigma Approach to Assure IT Security Analysis phase identify actual factors for security breaches after investigating each leaf of CED. For example at the time of vulnerable there was a query to database for employ record table, which seems an SQL injection attack and after verifying login screen code it can be analyzed that escape sequences are not properly handled. Now improvement phase will suggest proper controls and recommend these activities to be explicitly catered in implementation phase while developing the application first time. Control phase will keep on looking for new interfaces and runtime modules integration with existing application for taking care of SQL injection happening again. 5.2.2 Metrics A powerful metric to measure the strength of security implementations can be valuable contribution of SS for assuring IT security. For metric generation it is essential to fist identify security modules of the application and assign priority percentage. Then find DO, and DPO of each module. In the end implementation accuracy of requirements can be found by combining DPO of each module with respective priority percentage. This evaluation process is explained in following three steps. Step 1: Suppose there are three security modules or functions in an application, user data protection, communication security and identification & authentication. Assign weights to each module. These weights are known as Priority Percentage. Sum of priority percentage of all modules should be equal to 100. Priority percentage value of each module is based on some qualitative and quantitative factors. In general these factors may be as follow • • • Line of code of each module Number of test cases of each module Critical asset and high risk protection control module Based on above factors, suppose that three modules of application are weighted. Table 3 shows priority percentage of each module. Sr. No 1 2 3 Modules User Data Protection Communication Sec. Identification and authentication Priority Percentage 20% 20% 60% 100% Table 3: Prioritizing Security Modules 36 A Six Sigma Approach to Assure IT Security Step 2: Confidence level of application quality will be dependent on the bug report of internal testing. Internal bug report will give statistics like number of scenarios of each module, number of steps in each scenario, and total bug count of each module. Table 4 shows suppositions of these statistics and derivation of DPO. Sr. No 1 2 3 Modules No. of Scenarios 100 120 300 DO = No of Scenarios * No of steps 100 * 3 = 300 120 * 3 = 360 300 * 3 = 900 Bug count of each module 10 11 32 DPO = Bug / DO 0.0333 0.0305 0.0355 User Data Protection Communication Sec. Identification and authentication Table 4: DPO derivation Step 3: Implementation accuracy of application can be found by combing DPO of modules with priority percentage and adding the values. Formula for Implementation Accuracy (IA) is given below. (In given formula PP represents Priority Percentage don’t mix it with PP of Protection Profile) IA = 100 – (DPOM1 * PP M1 + DPOM2 * PP M2 + …+ DPOMn * PP Mn) IA = 100 – (0.0333 * 20 + 0.0305 * 20 + 0.0355 * 60) IA = 100 – (0.666 + 0.61 + 2.13) = 100 - 3.406 = 96.59 % * M = Module * PP = Priority percentage * DPO = Defect per Opportunity Implementation accuracy (IA) is the accuracy percentage means if there will be 100 possible flow paths than out of these, 96.59 will be accurate and 3.40 have bugs. We are not fixing any IA acceptance value just like in SS 3.4 defect per million opportunities is mentioned. It is up to organizations and even at project level that the acceptance criterion of percentage should be defined after analyzing the assumptions and complexity of environment. Above metric is based on internal testing report so it gives the application pre shipment assurance. In a post shipment review based on the defect reported by customers the ratio of external and internal defects is used to estimate post shipment assurance. Like if an application countered 100 defects in internal testing than 5 defects can be expected from 37 A Six Sigma Approach to Assure IT Security customer after shipment. But again this value 5 is not fixed and very from organization to organization and project to project based on expertise, assumptions and environment. 5.2.3 Philosophy: In order to address criticality of security in IT and to maintain a bug free non vulnerable production environment we need cultural changes. Unlike quality we have precarious risk of hackers and intruders in IT security. For fighting against this risk, employs training is a key factor that can change individual efforts of security administrator into a collective defense. Further it should be realized that security is not only the duty of security administrator but also the responsibility of every singe stakeholder that is playing with information assets. For achieving this goal a software development team should not only be dependent on security analyst but also on security experts in all phases of SDLC. There should be a security analyst in parallel to business analyst at the start of project to collect requirements, a security architect for the support of application architect, a security software engineer in parallel to functional software engineer and penetration tester to contribute with software quality assurance experts. Table 5 shows CC roles in different phases of SDLC. Project manager, project leads and components lead will perform they responsibilities same as before in planning activities. Security roles will work for security achievement just like black belt and other SS roles work for striving quality in SS projects. SSDL Phases Requirements Design Implementation Verification Support Through out life cycle Table 5: CC Roles SDLC Roles Business analyst Application architect Software Engineer Software Quality engineer Support engineer CM and Auditor CC Roles Security analyst Security Architect Software Security Engineers Penetration testing engineer Support engineer CM and security Auditor 38 A Six Sigma Approach to Assure IT Security Chapter 6 Analysis & Conclusion 39 A Six Sigma Approach to Assure IT Security This chapter will give the analysis of work done in previous chapters. It will give a critical analysis of method used to conduct the research, content of research, strong and week points in research, usefulness of protocols, assumption and limitations of protocols. 6.1 Analysis: Research work of the thesis gets start from chapter 3 in which Common Criteria is explained. CC documentation Version 3.1 (Defence Signal Directorate et al, CC Part 1: Introduction and general model, 2006) is purely a technical document. Its terminologies and language is not so easy to understand for every one. Further CC documentation structure just presents definitions, security requirements and assurance level classes. In this report chapter 3 gives a simple and clear interpretation of CC documentation. All important security classes and assurances classes are coved with the actual purpose of class, its families and components. Although it is just a textual representation of CC documentation but before doing this a lot of paper work is done to get in depth understanding of classes. All components of families are analyzed separately and included in its class explanation. The decision of using any class and its lower level components was based on its utilization with Six Sigma. Example of such exclusions is not too much explanation of Protection Profile and Security Target document generation using PP and ST classes. Chapter 4 of the thesis covers SS with the scope of its employment that can be of use for strengthening CC. SS has no well defined documentation and boundaries just like a fixed set of documentation in CC V 3.1 so to counter this problem we get help from the objectives of the thesis. We just focus on three areas of SS methodologies, tools and philosophy which are not only the objectives of thesis but also the protocols of Chapter 5. In SS methodologies discussion we tried to cover as many tools of SS as can be used to support quality assurance regardless of the fact that they can be addressed in scope of thesis or not. Although we have used only some of these tools in protocol definition but rest of tools and templates can also be used for CC assurance. Protocols defined in Chapter 6 are dependent on the interpretation of CC and SS in Chapter 4 and chapter 5 respectively. Initially a comparison criterion is defined based on six principles which provide motives of cooperation between CC and SS. CC interpretation in criterion highlights the gaps where SS can contribute and SS interpretation in criterion highlights strengths to fulfill the gaps. In methodologies a CC software development life cycle is given which gives the sequence of steps to be performed for success full implementation of CC. As CC documentation is just a well organized set of security requirements and it does not gives any details and sequence of these requirements this development life cycle can over come the pain of CC developers. DMAIC is suggested as a recovery methodology for process improvement and problem fixing. Successfulness of this methodology is verified from its use in SS now the only need is its adaptation and customization. Metrics defined as a second protocol gives a formal method of security assurance for CC. This metric is the foremost need of CC formal requirements. Authenticity and accuracy of the formula is already established as 40 A Six Sigma Approach to Assure IT Security DPMO we have just transformed quality parameters of SS into Security parameters of CC. Suggested Implementation Assurance formula is a quantitative measure like number of modules, percentage of modules, number of scenarios, number of steps and number of bugs. Judgment and error chances are very less in the given formula which makes very easy to asses the assurance of security. It may possible that the protocols defined above will not be result oriented from the start because they will take time to get mature. But with passage of time and customization of methodologies according to organization needs will serve for the best. Philosophy gives the change in thoughts and distribution of responsibilities to share security improvement liabilities. New roles and responsibilities will make security as important as quality and other functional requirements. 6.1.1 Future work: This thesis tried to draw attention to a completely unexplored field of using SS in security and IT. Our protocols definition scope was limited because of time and scope constraints so there in plenty of work to be done. Here, some of future work is pointed out. • • • • • • Case studies can be performed on the suggested secure software development life cycle and DMAIC methodology. Real time projects data can be used to authenticate the metric. Metric can be presented for trial and survey to software development teams and there results can be analyzed. This report has given number of SS tools in chapter 4 but we use only a few in protocol definition so rest of tools can be exemplified for getting benefit in security assurance. This report has focused to secure application software development but CC has also a role in secure network management so one can work by directly focusing on network security requirements of the CC. SS statistical sampling techniques can be suggested in security auditing for project scope coverage. 6.2 Conclusion: Before starting of the thesis and even in early stages of thesis I was in doubt of the usefulness of SS, its tools and methodologies. But now based on the above preliminary work in this field my conclusions are: • • • The protocols defined here will definitely give an additional method of assuring security other then existing mechanisms being practiced. CC will be feasible for adaptation with support of recommended methodologies and tools. Only tools like the metric can fulfill the semiformal and formal requirements of CC. 41 A Six Sigma Approach to Assure IT Security • Not only SS but also many other quality frame works can be adopted for improving IT security. 42 A Six Sigma Approach to Assure IT Security Appendix A Assurance classes families and components. Class Family PP introduction (APE_INT) Conformance claims (APE_CCL) Security problem definition (APE_SPD) Components APE_INT.1 PP introduction APE_CCL.1 Conformance claims APE_SPD.1 Security problem definition APE_OBJ.1 Security objectives for the operational environment APE_OBJ.2 Security objectives APE_ECD.1 Extended components definition APE_REQ.1 Stated security requirements APE_REQ.2 Derived security requirements ASE_INT.1 ST introduction APE: Protection Profile evaluation Security objectives (APE_OBJ) Extended components definition (APE_ECD) Security requirements (APE_REQ) Class ASE: Security Target evaluation ST introduction (ASE_INT) Conformance claims (ASE_CCL) ASE_CCL.1 Conformance claims ASE_SPD.1 Security problem definition Security problem definition (ASE_SPD) Security objectives (ASE_OBJ) ASE_OBJ.1 Security objectives for the operational environment ASE_OBJ.2 Security 43 A Six Sigma Approach to Assure IT Security objectives ASE_ECD.1 Extended components definition ASE_REQ.1 Stated security requirements ASE_REQ.2 Derived security requirements ASE_TSS.1 TOE summary specification ASE_TSS.2 TOE summary specification with architectural design summary ADV_ARC.1 Security architecture description ADV_FSP.1 Basic functional specification ADV_FSP.2 Securityenforcing functional specification ADV_FSP.4 Complete functional specification Functional specification (ADV_FSP) ADV_FSP.5 Complete semi-formal functional specification with additional error information ADV_FSP.6 Complete semi-formal functional specification with additional formal specification ADV_IMP.1 Implementation representation of the TSF ADV_IMP.2 Implementation of the TSF ADV_INT.1 Well- Extended components definition (ASE_ECD) Security requirements (ASE_REQ) TOE summary specification (ASE_TSS) Class ADV: Development Security Architecture (ADV_ARC) Implementation representation (ADV_IMP) 44 A Six Sigma Approach to Assure IT Security structured subset of TSF internals TSF internals (ADV_INT) ADV_INT.2 Wellstructured internals ADV_INT.3 Minimally complex internals ADV_SPM.1 Formal TOE security policy model ADV_TDS.1 Basic design ADV_TDS.2 Architectural design ADV_TDS.3 Basic modular design ADV_TDS.4 Semiformal modular design ADV_TDS.5 Complete semiformal modular design ADV_TDS.6 Complete semiformal modular design with formal high-level design presentation AGD_OPE.1 Operational user guidance AGD_PRE.1 Preparative procedures ALC_CMC.1 Labeling of the TOE ALC_CMC.2 Use of a CM system CM capabilities (ALC_CMC) ALC_CMC.3 Authorization controls ALC_CMC.4 Production support, acceptance procedures and automation ALC_CMC.5 Advanced support Security policy modeling (ADV_SPM) TOE design (ADV_TDS) Class AGD: Guidance Document Class ALC: Life-cycle support Operational user guidance (AGD_OPE) Preparative procedures (AGD_PRE) 45 A Six Sigma Approach to Assure IT Security CM scope (ALC_CMS) ALC_CMS.1 TOE CM coverage ALC_CMS.2 Parts of the TOE CM coverage ALC_CMS.3 Implementation representation CM coverage ALC_CMS.4 Problem tracking CM coverage ALC_CMS.5 Development tools CM coverage Delivery (ALC_DEL) Development security (ALC_DVS) ALC_DEL.1 Delivery procedures ALC_DVS.1 Identification of security measures ALC_DVS.2 Sufficiency of security measures ALC_FLR.1 Basic flaw remediation ALC_FLR.2 Flaw reporting procedures ALC_FLR.3 Systematic flaw remediation ALC_LCD.1 Developer defined life-cycle model ALC_LCD.2 Measurable life-cycle model ALC_TAT.1 Well-defined development tools ALC_TAT.2 Compliance with implementation standards ALC_TAT.3 Compliance with implementation standards - all parts ATE_COV.1 Evidence of coverage Flaw remediation (ALC_FLR) Life-cycle definition (ALC_LCD) Tools and techniques (ALC_TAT) Class ATE: Tests Coverage (ATE_COV) 46 A Six Sigma Approach to Assure IT Security ATE_COV.2 Analysis of coverage ATE_COV.3 Rigorous analysis of coverage ATE_DPT.1 Testing: basic design ATE_DPT.2 Testing: security enforcing modules ATE_DPT.3 Testing: modular design ATE_DPT.4 Testing: implementation representation ATE_FUN.1 Functional testing ATE_FUN.2 Ordered functional testing ATE_IND.1 Independent testing - conformance ATE_IND.2 Independent testing - sample ATE_IND.3 Independent testing - complete AVA_VAN.1 Vulnerability survey AVA_VAN.2 Vulnerability analysis AVA_VAN.3 Focused vulnerability analysis AVA_VAN.4 Methodically vulnerability analysis AVA_VAN.5 Advanced methodical vulnerability analysis Depth (ATE_DPT) Functional tests (ATE_FUN) Independent testing (ATE_IND) Class AVA: Vulnerability assessment Vulnerability analysis (AVA_VAN) Table 6 Assurance classes families and components. 47 A Six Sigma Approach to Assure IT Security EAL and Assurance components Table 7 EAL and Assurance components. 48 A Six Sigma Approach to Assure IT Security References: Book and Article: (Christopher & Audrey, Managing Information Security) Christopher Alberts & Audrey Dorofee 2002, Managing Information Security Risks: The Octave Approach, Addison Wesley (CNSS, National Information Assurance Acquisition Policy, 2003) Committee on National Security Systems, Jun 2003, National Information Assurance Acquisition Policy, Revised Fact Sheet, at URL: http://www.cnss.gov/Assets/pdf/nstissp_11_fs.pdf (Craig Tonner & Pradeep Patra, Six Sigma, 2003) Craig Tonner & Pradeep Patra, Sep.3 2007, Six Sigma at URL: http://www.isixsigma.com/dictionary/Six_Sigma-85.htm (C R Kothari, Research Methodology: Methods and Techniques, 1985) C R Kothari April 13 1985, Research Methodology: Methods and Techniques, John Wiley & Sons (Asia) Pte Ltd; 2Rev Ed edition (Dave Trimble, How to Measure Success) Dave Trimble, How to Measure Success: Uncovering The Secrets Of Effective Metrics, BPR Online Learning Center Series at URL: http://software.isixsigma.com/offsite.asp?A=Fr&Url=http://www.prosci.com/metrics.htm (Defence Signal Directorate et al, CC Part 1: Introduction and general model, 2006) Defence Signal Directorate Australia, Communications Security Establishment Canada, Director Central Information Security France, The National Security Agency United States, Communications-Electronic Security Group, Sep. 2006 , CC Part 1: Introduction and general model, p 10 at URL: http://www.commoncriteriaportal.org/public/files/CCPART1V3.1R1.pdf (Defence Signal Directorate et al, Common Criteria, 2006) Defence Signal Directorate Australia, Communications Security Establishment Canada, Director Central Information Security France, The National Security Agency United States, CommunicationsElectronic Security Group, Sep. 2006 , Common Criteria for Information Technology Security Evaluation, at URL: http://www.commoncriteriaportal.org/public/consumer/index.php?menu=2 49 A Six Sigma Approach to Assure IT Security (ISO, Information Security Evaluation, 2005) International Organization for Standardization, Jan 1 2005, Information technology -- Security techniques -- Evaluation criteria for IT security, at URL: http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html (Joab Jackson, Symantec: Common Criteria is bad for you, 2007) Joab Jackson, April 05 2007, Symantec: Common Criteria is bad for you, Government Computer News at URL: http://www.gcn.com/online/vol1_no1/44205-1.html (Kerri Simom, DMAIC Versus DEMADV) Kerri Simom, DMAIC Versus DEMADV at URL: http://www.isixsigma.com/library/content/c001211a.asp (Matt Bishop, Computer Security Art and Science, 2002) Matt Bishop Nov. 29 2002, Computer Security Art and science, A 21.8, Addison Wesley (Mike & Fiona, IT Security Assurance, 2006) Mike Nash & Fiona Pattinson 2006, IT Security and Common criteria, TickIT International, IT3Q06, p.3. at URL: http://www.atsec.com/downloads/presentations/TickIT_Journal_3Q06.pdf (NIAP-CCEVS, Validation Report Microsoft Windows 2003 Server, 2005) National Information Assurance Partnership- Common Criteria Evaluation Validation Scheme, Nov. 6 2005, CCEVS Validation Report Microsoft Windows 2003 and XP workstation, CCEVS-VR-05-0131, Version 1.1 at URL: http://www.commoncriteriaportal.org/public/files/epfiles/ST_VID4025-VR.pdf (Paul A. Keller, Six Sigma Demystified: A self teaching guide, 2005, p 50) Paul A. Keller, 2004, Six Sigma Demystified: A self teaching guide, McGraw Hill, p 50 DMAIC Problem Solving (Paul A. Keller, Six Sigma Demystified: A self teaching guide, 2005, p 85) Paul A. Keller, 2004, Six Sigma Demystified: A self teaching guide, McGraw Hill, p 85 Metric Definition (Paul A. Keller, Six Sigma Demystified: A self teaching guide, 2005, p 86) Paul A. Keller, 2004, Six Sigma Demystified: A self teaching guide, McGraw Hill, p 86 FLOW-DOWN FUNCTIONS: BIG Ys AND LITTLE ys (Paul A. Keller, Six Sigma Demystified: A self teaching guide, 2005, p 115) Paul A. Keller, 2004, Six Sigma Demystified: A self teaching guide, McGraw Hill, p 115 Analyze Stage (Paul Saettler, The Evolution of American Educational Technology, 1990) Paul Saettler, Nov. 1990, The Evolution of American Educational Technology, Libraries Unlimited Inc; Revised edition 50 A Six Sigma Approach to Assure IT Security (Sun Microsystems, Solaris 10 03/05 Security Target, 2006) Solaris10 Developed by Sun Microsystems, Nov. 28 2006, Solaris 10 03/05 Security Target, Doc No S10_101, Version 2.3 Definitive, p 11 at URL: http://www.commoncriteriaportal.org/public/files/epfiles/solaris10-sec-e.pdf (Wade H baker & Linda, Is information security under control, 2007) Wade H baker & Linda Wallace January/February 2007, Is information security under control? Investing Quality in Information Security management, IEEE computer society Electronic Reference: (Amber Gravett and David Dean Tuma, Debunking IT Isolation) isixsigma at URL: http://www.isixsigma.com/library/content/c040204b.asp (David L. Hallowell, Six Sigma Software Metric) David L. Hallowell, Six Sigma Software Metric at URL: http://www.isixsigma.com/library/content/c030910a.asp (FMV, CSEC – The Swedish Certification Body for IT Security) Swedish Defence Materiel Administration, May 2002 at URL: http://www.fmv.se/WmTemplates/Page.aspx?id=824 (Isixsigma, Six Sigma Roles and Responsibilities) isixsigma at URL: http://www.isixsigma.com/library/content/roles_responsibilities.asp (Microsoft, SQL injection, 2005) Microsoft MSDN Dec. 5 2005, SQL Injection, at URL: http://msdn2.microsoft.com/en-us/library/ms161953.aspx (Motorola, 2007) Six Sigma Dictionary, 2007 at URL http://www.motorola.com/content.jsp?globalObjectId=3074 (NIAP-CCEVS, 1999) National Information Assurance Partnership, The Common Criteria Evaluation and Validation scheme, 1999 at URL: http://www.niap-ccevs.org/cc-scheme/testing_labs.cfm (Six Sigma SPC, DO-Defect Opportunities) Six Sigma Statistical Process, DO-Defect Opportunities at URL: http://www.sixsigmaspc.com/dictionary/DO-defectopportunity.html (Six Sigma SPC, DPMO-Defect per Million Opportunities) Six Sigma Statistical Process, DPMO-Defect per Million Opportunities at URL: http://www.sixsigmaspc.com/dictionary/DPMO-defectspermillionopportunities.html (Six Sigma SPC, DPO-Defect per Opportunities) Six Sigma Statistical Process, DPODefect per Opportunities at URL: 51 A Six Sigma Approach to Assure IT Security http://www.sixsigmaspc.com/dictionary/DPO-defectsperopportunity.html (Steven B. Lipner, Market Adoption of Common Criteria, 2005) Steven B. Lipner, Lesson Learned in Market Adoption of Common Criteria, 2005 at URL: http://www.ecsec.jp/library/6thICCC/pdf/B2-08.pdf (Stylusinc, Software Development Life cycle) Stylusinc at URL: http://www.stylusinc.com/Common/Concerns/SoftwareDevtPhilosophy.php (Sumit, ITIL and Six Sigma Make a Winning Combination for IT) Sumit Kumar Jha, ITIL and Six Sigma Make a Winning Combination for IT at URL: http://www.isixsigma.com/library/content/c070404a.asp 52