Software Development Life Cycle, Dependencies and Critical Success Factors to the Job - Report Example

Security Recommendations Report to the CEO Table of contents Section 1 Table of Contents……………………………………………………………………………….2 Executive Summary……………………………………………………………………….…...3 Background ………………………….………………………………………………………….4 Section 2 Recommendations 2.0. Software Development Life Cycle …………………………….….……………..5 2.1. Security in Conceptual stage…………………………………….……………….6 2.2. Security in application requirements and specifications stage………………..7 2.3. Security in the software Design stage……………………………………..…….8 2.4 Threat risk Modeling……………………………………………………..…………9 2.5. Software security during coding………………………………………………….9 2.6. Security in Testing………………………………………………………………..11 2.7. Securing the Software Development Life Cycle………………………………12 2.8. Securing software vulnerabilities after implementation………………………12 Section 3 Dependencies and critical success factors 3.0. Internal Business Stakeholders………………………...……………………….13 3.1. Software Designers……………………………………………………………....13 3.1. Software Developers…………………………………………………..…………13 3.2. Security administrators………………………………………………..…………14 3.3. Financial resources………………………………………………………………14 3.4 Time and cost of software………………………………………………………..14 3.5. Security methodologies, procedures, standards and policies……………….15 Bibliography…………………………………………………………………………………….17 List of References………………………………………..……………………………………18 Appendices………………………………………………………..……………………………19 Executive summary Insecure software is software that is unable to resist most attacks, unable to tolerate attacks that it is unable to resist and unable to recover quickly from attacks thus violating the security of the software. The purpose of this report is to identify the major areas that may portend software security risks in the software development life cycle (SDLC), which is a collection of procedures and processes in development and maintenance of software applications. The report gives recommendations on how the organization can ensure development of secure software by considering security issues before, during and after software development. The report specifically recommends how security concerns may be addressed at each stage of the software development life cycle. Through use of best standard, practices, industry standards and ensuring observance of security concerns during the entire life cycle process, the report is expected to provide a framework for software developers in the organization to adopt in the process of software development in order to ensure that software vulnerabilities are reduced to the minimum possible levels. The outcome of the work would include production of more secure software and increased client satisfaction. The increased software security will also increase the competitive advantage of Hot source by making software security its core marketing value proposition Background Often, software attacks aim at sabotaging and causing software failure, subverting the software by changing the way the software operates such as by executing malicious logic embedded in the software, modifying or learning the operation of the software and the environment so as to be able to target the software more effectively. This effectively violates the security of the software. Consequently, software attacks affects some other software properties including usability, predictable operability, safety, dependability, interoperability, and performance (Gregory, 2009). Insecure software may be very costly to an organization. Insecure software may result to loss of critical organization data that may expose software users and organizations to financial risks among other risks (Rice, 2008). Various researches indicate that in most cases, software faces critical vulnerabilities and other security issues that are often preventable during the software life cycle development (Jamrich et al, 2010). Hot source software development efforts have been much removed from information security. The disconnection between development results and security at Hot source has increased vulnerabilities for the software thus making it insecure. There is an increase risk of losing clients due to the increased vulnerabilities in the organizations software. Although the organizations software and especially the payroll software is regarded highly by the market, security vulnerabilities pose a serious threat to its ability to hold on to its market share especially with the increase in software testing by third party security specialists. Hot source must therefore determine ways of making the software more secure. The report identifies ways in which security in the software development lifecycle can be helpful in ensuring the integrity of the software. Recommendations 2.0 Software Development Life Cycle (SDLC) Software security should be considered at each stage of software development. Programmers should aim to build secure software into every application that they develop. Greater levels of security should especially be provided for critical applications and more so for applications that process sensitive information such as payroll software. The need to consider security implications at every stage of development is especially critical considering that it is often easier to build security in the process of software development than building security into already completed software (Stewart, 2008). Consequently, in order to bridge the disconnection between software development and information security, the right security related activities should be taken at the right place in the software development life cycle (Gregory, 2009). Software development life cycle includes Conceptual stage Application requirements and specifications stage Application design stage Threat risk modeling Application coding stage Testing NIST 800-64 is a high quality standard developed by the U.S national Institute of Standards and Technology and it recommends security considerations at each stage of the information system development life cycle. 2.1. Security in Conceptual stage Since creation of any ideas begins with the conception of ideas, some notions of security should be taken into account at this stage. Recommendations for addressing security concerns at this stage: Determine what sensitive information would be available in the application. Determine how sensitive information would be protected. Determine how sensitive data will be transmitted out of the application and into the application and whether the information will flow outside the organization. Determine the application users and how they may access the application and its support infrastructure. Who has the administrative access? Determine whether third parties may have access to the application and how this access should be controlled. Determine whether there are any regulatory requirements that the software must meet such as the European Privacy law 95/46/EC, Sarbanes Oxley in the United States, PCI DSS, GLBA, FERC, NERC and HIPAA. Determine whether the application uses any enterprise wide service infrastructure such as single sign on, configuration management, authentication, or access to centrally managed storage. Determine any other applications that depend on this application or the application depend upon. The above processes may require development of a worksheet identifying various conceptual stage activities to assist in identification of security related concerns that may have to be addressed in the early stages of software development. 2.2. Security in application requirements and specifications stage Software security concerns should also be addressed during the development of functional requirements and specifications. Requirements and specifications are used to describe the applications behavior characteristics (Jamrich. 2010).. Recommendations to ensure security of software at this stage: Provision of detailed and exhaustive specifications and requirements so that the developer can develop everything. The requirements should be able to form the kernel of a completely detailed test plan to ensure that each function of the software can be verified and tested without requiring additional information. The developers should ensure that various requirements and specifications are included. These include: Access settings and control mechanism administrative and user roles audit logging workflow configuration management Interfaces to other external and internal systems. Reports Use cases 2.3. Security in the software Design stage The software is designed after completion of the detailed specifications and functions. At this stage, completion of various design elements such as database schema, workflows, input and output fields and records, audit logs, user cases, administrative logs, and integration with other services and systems are performed. The need for ensuring that the software is secure at design and specifications stage is to reduce potential costs attributed to insecure software. Still, considering the “1-10-100 rule” stating that the cost of securing an application after it has been developed costs ten times as much securing it during the design n stage and 100 times if secured after implementation (Gregory, 2009). Recommendations to ensure security of software; Software designers should liaise with individuals who developed the functional requirements and specifications when they discover ambiguities in the requirements and specifications. Review of the design by those who developed functional requirements and specifications should be carried out to ensure that the design reflects the applications requirement and specifications. The applications developers should participate in the review since they would be involved in the developing the software. The resulting design should be harmoniously and accurately depicted so as to be integrated into the overall technology environment. 2.4. Threat risk Modeling Even after building an application that fulfils sound requirements, specifications and design, this is still not enough to guarantee security of the application. Threat risk modeling is aimed at testing whether the software is vulnerable against known threats. Consequently, to ensure software security: Perform threat risk modeling after design of application but just before the coding. 2.5. Software security during coding In order to ensure that software is safe and free of vulnerabilities during coding, software should be coded defensively. Recommendations for ensuring secure coding by avoiding various vulnerabilities Ensure that all input is properly validated to avoid unexpected value inputs from being g passed to the application. Ensure application users are unable o break access control by circumventing the security settings, or by manipulating the application to circumvent role based access. Ensure that application users are unable to manipulate session management and authentication in order to bypass security control. Applications should strip out delimiters and any other data that may be part of a scripting attack and parse all input data to prevent cross-site scripting attacks. Applications should manage buffer overflows by performing proper boundary checking for all inputs thereby preventing unexpectedly long input strings from resulting to unexpected behavior. Application should also be able to reject script injections such as java script and SQL. Application errors should be gracefully handled to ensure that applications do not produce errors statements that may betray information about the software. Data security should be ensured by ensuring encryption and proper data control when appropriate. The software should not abort or malfunction due to a process or user providing malformed data in a particular field. Each and every component of the software environment and its supporting infrastructure should be securely configured to ensure the software is free from vulnerabilities. Use of Safe libraries One of the best practice standards to avoid most of the vulnerabilities such as buffer overflow and script injection is to use source code libraries that have already been tested against the vulnerabilities (McGraw, 2006). 2.6. Security in Testing Testing is used to ensure that the software is free from errors and it was coded properly. Recommendations for security testing Testing should be organized and planned All functional aspects of the software should be tested Application environment should be tested to ensure software is free from security defects. This is done using security testing tools. Scanning tools should b e used to test security for web based applications in order to identify application vulnerabilities that are common and not so common. The two commonly used tools for scanning are the AppScan from IBM/watchfire and WebInspect from HP/SPI dynamics (Gregory, 2009). 2.7. Securing the Software Development Life Cycle The software development life cycle should also be protected to ensure more secure software. Recommendations: Ensure only authorized developers can access the application source code. Allow only a few of the developers to have permission to alter the source code. Protect software development tools from modification and unauthorized access in order to reduce introduction of vulnerabilities from tampering of development tools. Protect software development systems used in developing applications such as the source code repositories and developers work station with as much rigor as is used in protecting application servers. 2.8. Securing software vulnerabilities after implementation Even after all necessary care is taken in the software development life cycle, some vulnerability may still exist. Such vulnerabilities may be identified using various tests and the vulnerabilities may be addressed through software patching. Section 3 Dependencies and critical success factors to the job In order to ensure successful software development there are various critical success factors and dependencies that may have an impact on software development. They include internal business stakeholders, developers and so on. 3.0. Internal business stakeholders Various internal business stakeholders such as the organizations management and other employees may impact on the successful development of secure software. The management is required to provide leadership and resources that may facilitate secure software development. 3.1. Software Designers The designers design the applications after the development of the applications functional requirements and specifications. The software designers may discover that there are ambiguities in the functional requirements and specifications. The software designer consequently liaises with the person who developed the functional requirements and specifications to remove the ambiguities before finishing the design. This ensures that the application design accurately depicts and reflects the specification requirements and it harmoniously and smoothly integrates into the overall technology. 3.2. Developers Developers are crucial in developing the functional specifications and requirements. Software developers ensure that the software meets various minimum security thresholds and standards while developing software codes. The developers also ensure that the software code is secure. 3.3. Security administrators The security administrators are responsible for ensuring that software maintenance was appropriately handled to prevent vulnerabilities resulting from security exposures created by inadequate software maintenance procedures. The security administrator is responsible for ensuring proper maintenance procedures that do not allow uncontrolled insertions of malicious code into the privileged system libraries and applying security patches and updates. This is especially critical as the software development life cycle becomes more of a softer target for introducing vulnerabilities in the software. Security administrators may also include testers who are responsible for testing whether the software meets various security standards that are set by the company as defined by business analysts. The testers in particular test for violation of the set standards. 3.4. Financial Resources Availability or lack of adequate financial resources will impact on the ability of the organization to deliver secure software. Where adequate financing is availed, the organization would be in a better position to provide their clients with a more secure software. 3.5. Time and software cost The time that it may take to complete the software may increase with the increased security concerns. The cost of the software may also increase due to the additional time that the software development project may take. This may affect the pricing of the software and may impact on the sale where there are price sensitive clients. However, the increased costs would be mitigated by the attribute of increased security. 3.6. Recommendation on software security methodologies, procedures, standards and policies Having the appropriate procedures, standards and policies allows the company to define the security levels that all its applications must attain. In particular, they aid organizations to set its bar that each application should achieve concerning the security of software, allow the business analysts to define the required standards as supported by the standards, aid developers and designers to stick within the standards, aid the testers in determining whether violations to standards have occurred. Finally, they also aid the maintenance and deployment engines in ensuring ongoing maintenance with security measures. Recommended policies Secure application development policy. Secure application deployment standards Secure coding standards Application threat modeling methodology Application code review methodology Application portfolio risk assessment methodology Tool integration process methodology among others. The company must also maintain various policies such as the secure application development policy. The policy is a plan of action that guides developer actions and decisions in the SDLC. The policy is intended for application architects, developers, designers, deployment engineers and even those who manage software within client’s organizations. The policy is supposed to be used in conjunction with various standards including Data protection in transit and storage. user session management standards Configuration management. Authorization. authentication data validation logging and auditing error handling and exception standards Bibliography U.S National Institute of Standards and Technology. NIST 800-64. Security Considerations in the Information System Life Cycle. References Gregory, P 2009, CISSP Guide to Security Essentials, Wiley Publishers. Jamrich, P 2010, New perspectives computer concepts, Cengage Learning. McGraw, G 2006, Software security: building security, Addision Wesley. Stewart, M 2008, CISSP: Certified Information Systems Security professional Guide, Wiley publishers. Rice, D 2008, Geekonomics: The real cost of insecure software, Pearson Education Appendices NIST 800-64, Security Considerations and the Information System Development Life Cycle. Developed by National Institute of Standards and Technology. Read More