SDL, CLASP & TOUCHPOINTS: A Comparison and Alignment of CLASP with Waterfall Model

Transcription

1 SDL, CLASP & TOUCHPOINTS: A Comparison and Alignment of CLASP with Waterfall Model Nishtha Sankhwar Dept. of Information Technology IIIT Allahabad nishthasankhwar.infosec@gmail.com Anuja Tewari Dept. of Information Technology IIIT Allahabad anujatewari.infosec@gmail.com Dr. Vrijendra Singh Dept. of Information Technology IIIT Allahabad vrijendra.singh@gmail.com Abstract Integrating security in the software development process, right from the start till the very end, not only ensures a secure software but it also saves the organization from spending extra time and expenses on remediation processes along with maintaining a good reputation of organization. Various processes have been devised to introduce the development process to security, but there seems to be a certain contrast in how they address involvement of security in the software development process. This paper helps in bridging this gap by comparing majorly adopted secure software development processes OWASP's CLASP, McGraw's Touchpoints and Microsoft's SDL to show the advantages and disadvantages they hold over each other. Further, among the three, secured one is aligned with the traditional software development processes which provide a framework that could implement security into early stages of development as well as maintain the essence of old and time proved models. Index Terms SDL, CLASP, Touchpoints, Software development, Waterfall Model. I. INTRODUCTION. As much as layered approach for software development is required, software security needs to be designed from the very first phase of development. Among the leading software development processes, few are able to provide greater flexibility; few are able to deal with threat modeling. Unfortunately theses processes are not able to provide sufficient security with flexibility with ample of security best practices being followed, as it is getting demanded by industries for continuously changing security requirements. Hence, there is a need to have an understanding of a development process that could provide greater security and get easily aligned with the traditional development models. an understanding of a development process that could provide greater security and get easily aligned with the traditional development models Security Development Lifecycle (SDL), developed by Microsoft to answer the issues faced by them during various development projects andhence, mostly caters to the need of their development methodology only. It has a more detailcentric approach, as it clearly defines how the activities defined in it will be combined with the phases of the development process, due to which SDL tends to get somewhat rigid and time consuming in its approach for incorporating security in the development process. With these constraints of time and rigidity, come the most appalling constraints of all-cost of the overall project, which tends to be on the higher side, thus rendering this process infeasible for smaller organization. The positives of engaging SDL in the development process are - the awareness activities as well as good guidance provided by SDL, which enables even newer and less experienced members of the development team to understand and integrate security into the development 365 P a g e

2 process.sdl provides a well defined process as to how to measure the progress made by the overall process in the form of matrices. Touchpoints was developed by Cigital, formed from various software security practices applied by experts in the industry to various artifacts while developing software with security in mind. An artifact is a by-product which is produced from a software development phase, from designing to implementation, to the end user contract [10]. All these and many more are the deliverables of the development process, with artifacts having the inclusion of the developed software. Touchpoints includes both constructive and destructive activities with a focus on making penetration testing more of an inside-out approach to testing, rather than an outsideapproach. Providing taxonomy of bugs and their classification, how network security can be handled by using Touchpoints, etc are few examples of how touchpoints has been designed around the concept of direct applicability to a software development process. It fills the gap between how it should be done and how it is done in practice, by simple touchpoints suggested in it. CLASP[14] (Comprehensive, Lightweight Application Security Process) by OWASP, is a set of best practices carefully based on suggestions from security practitioners all around the globe, having 24 activities that are capable of easily being fitted into any software development process being used. CLASP offers high flexibility in the form of such activities that need not be in a particular order of application. CLASP heavily emphasizes on the identification of various roles in a software development process and the resources they may be able to access. By providing a vulnerability lexicon to vulnerability use cases, CLASP provides an excellent source of implementation support resources, which make application of its activities easier for the development team. One of the concerns relatable to CLASP is that the activities suggested in it are rather broad in their coverage. The objective of this paper is to compare and contrast processes from the secure viewpoint of development, i.e., Microsoft SDL, OWASP CLASP (Comprehensive, Lightweight Application Security Process) and McGraw s Touchpoints. Theoretical comparisons are made between these three processes, based on some general criterion as well as on some of the best and most practical practices prevalent in the secure software development industry [6]. Each of these processes has been judged on the advantages that they hold over each other, for example, CLASP being more flexibility and having a higher applicability to any software development process or whether how the awareness regarding security of the development process is being handled by either of these. Such a comparison clearly shows which of these processes is suitable to be selected for which type of software development process (based on rigidity, size of the organization, time allowance for the development process, the phase of development process to which these are being applied to, etc.) II. LITERATURE REVIEW Mike, 2003 [11] have suggested a model( SSE-CMM) for describing the vital attributes for an organization s security engineering process that must be met, with various IT processes and the measurement of their maturity level competently, to achieve good security among other necessary IT requirement compliance. A set of base practices defined in this model allows a developer to integrate security while setting the development objectives. Dr. Raimundas Matulevičius [1] had provided the comparative study between the forefront methodologies prevailing in market for secure software development: Microsoft software development lifecycle(sdl), OWASP s CLASP (Comprehensive, Lightweight Application Security Process) and Gary McGraw s Touchpoints with the six different categories: education, architectural & detailed design, project launched, risk analysis and requirements, implementation and testing, release and deployment. However, this approach clearly shows Microsoft SDL is lacking to cover risk analysis and security requirements while other two pays somewhat attention to it. Further his study continues, in order to choose the process that could perform risk analysis to identify and mitigate the possible threats could prevail while developing the software with the help of security research questionnaire to provide a better view of risk management methods. Conversely approach is limited to present one phase of security development processes, architectural and detailed design phases are not addressed. Bart De Win et al. [2] has performed a comparative study on SDL, CLASP and TOUCHPOINTS on the basis of traditional software development process but as per the today s industry projects as well as security requirements, which are varying from moderate to high at every phase of development, a versatile approach is required to map the differences between the methodologies. Karl Tiirik [3] has written an essay on comparison on SDL and TOUCHPOINTS, briefing over the two processes and finding similarities and differences between them. The essay seems to have been derived from the works of Bart De Win [2] and constituting of a concise summary. Key challenge is to have the elaborated software development 366 P a g e

3 process that should address the security between the development phases as well. Planning and developing software with application security in mind from the initial design phases leads to software with fewer bugs related to application security, and less potential for vulnerabilities. Today s forefront software development processes which are playing major roles in the industry are unable to perform Vulnerability and Threat analysis. Microsoft SDL, the oldest structured software development methodology is inflexible with the other platform based applications and software as it only facilitates Microsoft based applications and software.software security Touchpoints is a set of best practices have been adopted by the industries nowadays, though light weighted but needs to be elaborated as per the development requirement specification and misses out on the major activity of education of the team. CLASP proposes a set of activities with a broad coverage with large resource; applicable to any software development process, but it is this broad coverage which may pose a question on its ease of applicability. It is this broad coverage that we are going to try and answer by aligning the CLASP activities with the phases of a development process to make this process easily applicable. III. METHODOLOGY To compare CLASP, SDL & Touchpoints and subsequently understand the basis behind which one of these is best suited to be selected as a secure mean of software development, a set of criterion were defined, both generic in nature as well as based on few best practices. These criterions were selected because of the importance of efficiency (in terms of time and cost of the overall process) [5], the suitability of these processes to organization size for defining the required development team size as per its needs, as well as few best practices required to enable developing a secure software.[6] Identifying the sources for analyzing and contrasting these three processes was the next step.[7][8][9] Since the processes are hierarchical in nature (SDL and Touchpoints) while CLASP is not so and has the possibility of applicability of different activities to many phases of the development process, the activities of these processes had to be realigned as per either of these processes and then compared. This provided us with a better view on how extensively these criterions were being employed by the processes. CLASP process is composed of [14]: CLASP Views CLASP Resources CLASP Views These views are broken down into activities which in turn broken into components to provide brief understanding of CLASP process. Activities defined under it explain how they can be easily embedded into software development lifecycle. Views contains following perspectives: Concept view Role-Based view Activity Assessment view Activity Implementation view Vulnerability View Concept view: provides high-level introduction of CLASP views, best practices, security policies, process components. Role-Based view: explains how roles could be associated with each best practice. Activity-Assessment view: provides assistance to managers to assess the accuracy of the CLASP activities into their project. Activity-Implementation view: It contains the 24 CLASP activities that can be integrated with the software development process. Vulnerability View: CLASP identified 104 problem types that may form as a basis of security vulnerabilities which helps to identify what are the possible conditions in which threat can occur. Vulnerability Use Cases assist project manager to identify attack surface and the associated vulnerabilities in security services CLASP Resources CLASP provides list of resources which are being required to put in focus while planning implementing and performing activities. Following is the abstracted list of resources which is further categories into organization specific architecture and processes. Basic principles of application security Descriptions of core security principles System assessment worksheet Network resources System resources File system and registry Sample road maps IV. ANALYSIS (B) Comparison between SDL, CLASP & Touchpoints 367 P a g e

4 After understanding and analyzing SDL, CLASP and Touchpoints based on the resources that were present, it can be deduced that all three of these secure software development processes answer the issue of security in quite different manners. Their overall objective may remain same, i.e. to embed software security while the software IS being developed, the application of it is relatively different to each other. Hence, rather than comparing these processes based on either of them, a set of general and necessary criterion was used to compare them in Table1. Process Table I: Comparing CLASP, SDL & Touchpoints (part II of II) CLASP[9] SDL[7] Touchpoints[8] Criteria Nature Light weight Heavy weight Light weight Applicability Suitability Any software development process Small and large sized organization Software development life cycle phases only (SDLC) Large organization Software development artifacts Small and large sized organization Nature of activities Constructive Constructive Destructive as well as constructive Team education Yes Yes No Application Testing and Assessment Extensively Through Threat Modeling, Code Level Review, Security Tests, but No Verification of security attributes of resources Through Threat Modeling, Code Level Review, Security Tests, but No Verification of security attributes of resources) Evaluation of current state and security requirements Yes (using a global Yes (No global security Table1: security Comparing policy, CLASP, policy SDL &, Touchpoints no identification (Part I of of II) identifying resources resources and trust and trust boundaries, boundaries, user roles are user roles are defined, not defined, mention of mention of operational operational environment,no environment, misuse misuse cases,recognizing cases,recognizing attack surface, documenting attack surface, security requirements) documenting security requirements) Yes (No global security policy, no identification of resources and trust boundaries, user roles are not defined, no mention of operational environment, misuse cases,recognizing attack surface, documenting security requirements) Measurement of security activities Yes Yes Yes 368 P a g e

5 Code Integrity check Separate Privacy requirement evaluation Yes No No No Yes No Nature Nature here depicts the basic characteristic of any process depending upon the team size needed, the flexibility of the process for application, less rigorous development methods, the time and the cost needed to be invested, etc. CLASP and Touchpoints here turn out be holding a large advantage over SDL, since both of these processes are designed that they can be applied to an existing development methodology in use by an organization, where as SDL requires quite a revamp in that methodology, to be of use. Applicability The applicability criteria describes how the activities defined in either of these processes is applicable to any development methodologies. While CLASP has activities which have no certain order to be used when being applied, CLASP is also adaptable to any development methodologies because it does not have mandatory activities. These activities can be imbibed into the process as per their applicability. SDL is strictly phase wise application of its activities. Many organizations have an existing development methodology [12], hence they would prefer integrating a security process that will work with their existing model, rather than something that ll require a complete change. Similarly, Touchpoints has an upper hand over SDL as it focuses on applying secure activities to the artifacts produced during a new or an existing development methodology. Suitability Based on the above mentioned factors of the nature and applicability of these processes, it is quite evident that while CLASP and Touchpoints are more suitable for smaller organizations/projects, which may be restricted financially or size-wise.sdl works through a very rigorous process which may not be adaptable to every type of organization and at any point of time in a development project. Nature of activities Touchpoints encompasses activities that are constructive and also destructive ones. By destructive, we refer to McGraw s definition of these- those activities that handle attacks, exploits, and breaking software. These kinds of things are represented by the Black Hat. [8] White Hats are represented by describing constructive activities as those about designing, defense and functionality. Touchpoints uses Penetration Testing which are destructive in nature aside from using code reviews (constructive) and abuse cases constructive as well as destructive). SDL and CLASP only employ constructive activities such as code reviews, risk analysis, defining security requirements, etc. Team Education Educating or training the team and stakeholders before a project is launched ensures that the overall objective of achieving security while developing a software is maintained throughout the process.sdl and CLASP hold the advantage here, since they offer activities that make sure that the team members are well equipped with the required security knowledge by having security awareness programs.sdl even has methods to measure the knowledge gained by such programs. Touchpoints lacks severely on this front since there are no activities defined in it that put focus on educating the team. Application assessment and testing All the three secure development processes encourage proper assessment and testing of the software being developed, but what makes CLASP attain a point of advantage is that it even considers verifying the security attributes of the resources that are being used for the development, i.e. whether they comply with the global security policy or not, which resources should be accessible to the system and by whom, etc. Evaluation of current state and security requirements One of the major differences between CLASP and the other two secure development process lies in the fact that CLASP standardizes the way, how to use products and the approach by defining a global security policy. [9] and neither SDL nor touchpoints cover this ground. CLASP and SDL both recognize and try to minimize exposure of the attack surface, CLASP also recognizes its entry points and the roles which can access these entry points and resources while Touchpoints performs destructive activities to realize the attack surface but nothing to minimize it. 369 P a g e

6 Measurement of security activity performance All the three processes provide activities to identify matrices, their evaluation and their usage ideas, but CLASP combines such security analysis and the security management process by automating the process of security analysis and metrics penetration testing and lends the output in the form of matrices which allows monitoring of work to be done and work done till now. Code Integrity check CLASP ensures the integrity of the developed code by signing the code using the PKI vendor s software signing certificate on the compact archive file which contains the complete installation package for the developed software. Neither SDL nor Touchpoints perform any such activity. Thus CLASP gains a major advantage by ensuring one of major factors of the triad of security, i.e integrity which none of the other process does. Separate Privacy requirement evaluation In the world of technology, privacy is a huge concern for any type of user related to computers in any manner [13]. SDL answers this call for privacy considerations even in the software development process. SDL promotes measuring the collection. In SDL, matrices are collected to understand how effective the awareness program has been and in-process matrices allow assurance of compliance of the process with security requirements. After completion of the process, matrices are collected to provide guidance for future improvements. Touchpoints performs sensitivity of the data that will process from a privacy point of view [1] while neither CLASP nor Touchpoints specifically take privacy up into consideration. (B) Alignment of CLASP into the Waterfall model The paper outlines the schema for embedding CLASP best practices into phases of software development process which introduces security concerns from the starting of any development process. Waterfall is very old and known model but offers high risk and uncertainty when it comes to security implications across iterations of development. The analysis has been performed in which each sub best practice of CLASP is mapped with the corresponding phase of development where it is required and ensures security. Fig.1 and Fig.2 describes clearly how best practices of CLASP are mapped into waterfall model. 370 P a g e

7 Fig.1. Table Alignment of CLASP best practices into Waterfall model (Part I of II) [Best practices are taken from OWASP CLASP [14]] Institute Awareness Security Program [9] Security awareness program for the Institute needs to be aligned with the requirement analysis phase of SDL as it is necessary to educate about inherent security features to each and every member of the project. Project manager should ensure awareness programs and training sessions are being organized throughout the organization which addresses security requirements relating to each phase of development and security issue that might arise while proceeding. So it is crucial to establish requisite exposure to security concerns before making accountability of the issue. Even members who do not come directly in focus of holding accountability for example, Developers should be aware of security concepts and the procedures adopted by organization to implement them. 371 P a g e

8 Fig.2. Table: Alignment of CLASP best practices into Waterfall model (Part II of II) [Best practices are taken from OWASP CLASP [14]] Perform application assessments [9] In assessment, security examination is performed in order to determine the weak entry points for risk that are not discovered in the requirement identification, design and implementation phase. Perform Security analysis of system requirements and design (threat modeling): Threat modeling has been always required to perform in specification and design phase of Waterfall SDL because after comprehending the project; means what to build, it is necessary to identify the inappropriate and unfitting requirements and their resulting impact on the development. To perform security analysis for requirements and design, an expert or security auditor is recommended to execute unbiased assessment from the early stages. After identification of probable risks as well as non pre-assumable risks, are prioritized on the basis of the severity they are offering and inappropriate compensating controls. Perform source-level security review: CLASP withdraws the attention of security auditor to find out the vulnerabilities present in the implementation phase by assessing profiling of threats, architectural assessment and system requirements and 372 P a g e

9 specification. Security review has been aligned to organize at the end of every implementation recurrence and in the testing phase. Identify, implement, and perform security tests: Needs to be aligned with the Testing & verification phase of Waterfall in extent to find out the security issues not discovered or detected during implementation phase. Security tests are driven by the test analyst and tester which act as a defense-indepth procedure to assess risks announced by the real time environment. Verify security attributes of resources: This is aligned with the testing phase. It verifies authorization and access control assigned to each resource used in the system explaining authorization granted by the standard system install should match exactly with the owner of the resource as specified in the security requirement or in the global security policy. Research & assess security posture of technology solutions: Technology solution for development can be of two types, Outsourced or third party and in-house. For the outsourced technological components, it is necessary to first of all identify the posture of technology solution demanded by the system followed by assessing them upon collection for security issues. If the component is not able to address the purpose as it is mentioned in the documentation, vendors are asked to perform application assessment and generate report for the same. Organization itself may perform assessment but vendor should be acknowledged in sack of testing the component. For the in-house, organization should ensure the credibility of the technology solution and diagnose how well solution will perform in the direction of lessen the risk. Capture security requirements [9] Identify global security policy: It is aligned with the requirement analysis phase of development. Organization needs to have a global security policy which sets the baseline security necessities according to the project, project manager or CISO of relevant departments should establish valuable policies if the project is lacking if any and compare the acceptability of global requirements to project which ultimately helps the Specifier to identify security posture of each component that would have been used in the solution as well as its accurateness in accordance with the global standard. Identify resources and trust boundaries: In this phase designer will prepare the architect of system from the outlook of network, identifies what could be the possible location of network components, what are the suitable resources that might be used by the program. Identify user roles & resource capabilities: Identify project roles or responsibilities/ access rights and associated resources that would grant access only to the specified project roles. Corresponding resource mapping with the role should be designed and documented in the specification and design phase. Specify operational environment: An operational environment understanding is necessary to visualize the security influence introduced by the real time environment whenever the product is put into to run. Therefore it is aligned with specification phase to examine the possible implications of security solution with respect to target hosts and network architecture. Detail misuse cases: Risk may arise at any phase of the software development, for possible risk, corresponding mitigation mechanisms are identified, performed and subsequently informed to the stakeholder or end user. Stakeholder should be aware of each and every security risks or issues encounter while development, therefore it needs to validate security requirements at specification, design, implementation and testing phases. Identify attack surface: It is aligned with the design phase of development. Designer should identify possible as well as extrinsic loopholes while designing the solution or configuring the components in the network level design. For each resource and component of the system, access roles need to be assigned and access control list should be maintained throughout the organization. Document security-relevant requirements: For the secure development not only the functional and business level requirements for the system are examined but for security also these requirements should have been reflected. Functional security requirements enumerate fundamental security assistance for each resource present in the system. Businesslevel security requirements will address the desires made by the customers and it would always have been unstructured as the end users are not sufficiently aware about the set of requirements they actually require instead of what they actually demand. It needs to be figure out in the requirement specification phase. Implement secure development practices [9] Apply security principles to design: It needs to be aligned with the design phase. To enhance core security assistance, requirements should be obliged to meet with the application 373 P a g e

10 design and what has been documented in the software requirement specification (SRS). Outsourced components are being analyzed for input validation and syntactic validation. Annotate class designs with security properties: Requirements for any project are not definite; they might change according to the environment or with the varying user needs. Class diagrams or structured annotation for archiving information will help the implementer to review and develop correctly. Every data resource in the system should have security policy and it is aligned back with the SRS document in the design and implementation to determine whether the resource is providing those security services or not. Implement and elaborate resource policies & security technologies: It is aligned with the Implementation phase. The implementer should make certain that all the development guidelines including security guidelines are meeting. Implement interface contracts: Interface contracts are the contentions which are helpful in implementing input validation and error handling and could be prove as a security enhancer tool, if announced diligently in the implementation phase. Integrate security analysis into source management: It is aligned with the implementation phase. Security analysis tools are of two types: Static and Dynamic; Static examines the code entirely without executing the program while dynamic requires execution of code and verifying full functionality as per the design specification. Whatever analysis system is adopting, it is recommended by the security experts to analyze small codes at first followed by taking larger one. Code analysis would be further integrated by introducing a regular source code check. Perform code signing: To ensure code integrity, code signing is performed after building the final product at the phase of maintenance. Build vulnerability remediation procedure [9]: Manage security issue disclosure process: If a tester has encountered with a new or unidentified issues in the release software, then it should be first communicated immediately internally following to the client or stakeholders. Secondly organization should inform outside security investigators, so that others also get aware about the new vulnerabilities and mitigation technologies would have been identified. Address reported security issues: If vulnerability has been identified by the system, a suitable designer expert or chief architect is assigned to the investigation that will ensure about the impact and exposure of the issues and determine mitigation strategies for the same. Define and monitor metrics [9]: Monitor security metrics: Metrics are meant to define security posture of a system which helps designers to figure out regions where improvement is required, assist implementers to enforce changes needs to be executed, able testers to scrutinize the new specimen in accordance with the changed requirements and analyze performance through metrics key indices by deploying the solution. This practice of CLASP is aligned with the design, development, verification and support phases. For design, attack surface metrics are designed which makes sure that the implementation would have been streamline as it is drafted in the design. For implementation, coders are provided with the coding guidelines that need to be followed to secure development. Among verification strategies, input validation metrics are being used to analyze each input to the program. These metrics should be periodically reviewed by analyzing their output. Publish operational security guidelines [9]: Specify database security configuration: Database resources that are used under implementation process demands proper configuration to store them in database. Generally organizations deploy default configuration as provided by the third party vendors but before implementation these; setting should be validated in compliance with the requirements of the resources. If necessary, inaccurate configuration can be tested to identify security risk associated with the database resource. Hence it needs to be aligned with design, development and testing phase. Build operational security guide: Users are the most important asset for any organization, At the time of delivering the software or product to the users, proper documentation on functional security is provided to ensure pragmatic requirements should be taken care of before installation of the system. Implementer builds the documentation guide that addresses resources and their usage, mechanism and polices for default authentication, list of security setting and procedure to use them. 374 P a g e

11 Fig.3. Integration of CLASP best practices into Waterfall model V. CONCLUSION Figue3 depicts a complete picture of how framework will look after integrating CLASP best practices into software development model. Development models embedded with CLASP best practice would empower organizations to address vulnerabilities well and provide security features to enhance authentication, confidentiality, data integrity and authorization. Among all the views provided by the CLASP, Vulnerability view make it differ from the others as SDL and Touchpoints are not able to do vulnerability assessment, only efficient to perform risk assessment. Traditional models like Waterfall, RAD, Iterative, and Incremental are best in their own approach but are not able to perform well in risk mitigation. Hence alignment of sub best practices of CLASP along with development process is a defense in depth approach to deliver secure software. 375 P a g e

12 REFERENCES [1] Dr. Raimundas Matulevičius, A Literature Survey of the Development Processes for Secure Software, [2] Bart De Win, Riccardo Scandariato, Koen Buyens, Johan Gre goire, Wouter Joosen, On the secure software development process: CLASP, SDL and Touchpoints compared, [3] Karl Tiirik, Comparison of SDL and Touchpoints. /essay09.pdf [4] Simplified Implementation of the Microsoft SDL, Microsoft, November 4, [5] Stefan Wagner, Melanie Ruhe, A Systematic Review of Productivity Factors in Software Development, [6] Seven Practical Steps to Delivering More Secure Software, Fortify Software Inc., files/fortify-practical-steps.pdf Microsoft, Security Development Lifecycle best practices, G. McGraw, Software Security: Building Security In, Addison Wesley, 2006 [7] OWASP, Comprehensive, lightweight application security process-best practices, Best_Practice (2006) Wikipedia, Artifact (software development) opment) (2015) [8] Mike Phillips, Using a Capability Maturity Model to Derive Security Requirements, SANS Institute 2003 Jacobson, G. Booch, J. Rumbaugh, The Unified Software Development Process, Addison-Wesley, (1999) Lance J. Hoffman, Computers and Privacy: A Survey, ACM Computing Surveys (CSUR),( June 1969) [9] OWASP CLASP Project _CLASP_Project(2015) [10] Ms. Shikha maheshwari, Dinesh Ch. Jain, A Comparative Analysis of Different types of Models in Software Development Life Cycle Volume 2, Issue 5, May 2012 [11] MARK C. PAULK, Bru CURTIS, and MARY BETH CHRlSSlS, CHARLES V. WEBER, Capability Maturity Model, Version 1.1, July 1993 [12] J.H. Saltzer, M.D. Schroeder, The protection of information in computer systems, Proceedings of the IEEE 63 (9) (1975) [13] Vishwas Massey, K. J. Satao, Evolving a New Software Development Life Cycle Model (SDLC) incorporated with Release Management, [IJEAT,ISSN: , Volume-1, Issue-4], April 2012 [14] Fabian, B., Gürses, S., Heisel, H., Santen, T., & Schmidt, H. (2009). A comparison of security requirements engineering methods Requirements Engineering: Vol 15, Issue 1, (pp 7-40) [15] J.E. Burge and D.C. Brown, An Integrated Approach for Software Design Checking Using Design Rationale, Proc. First Int l Conf. Design Computing and Cognition, J.S. Gero, ed., pp , P a g e