White Paper Security in Software Development Life Cycle

White Paper Security in Software Development Life Cycle Trojan Horses: Emmanuel Franklin Jonathan Newland Showanda Smith Anh Cao Information Systems and Technology (IS&T) has become an essential part of everyday life. Today people perform daily activities and transactions through Internet, ATM, and mobile devices for multi-purposes. Because people use software bearing in mind that it is reliable and can be trust upon and the operation they perform is secured. It is a very important to continue to keep these people feel safe and secured when using IS&T and to prevent any exploitable security holes... G e o r g i a S t a t e U n i v e r s i t y

Table of Contents Executive Summary... 3 I. Introduction... 3 II. Security in Software Development Life Cycle... 5 Traditional Waterfall SDLC... 5 Agile Methodology SLDC... 10 SecSDLC Certifications and Credibility:... 13 III. Conclusion... 16 White Paper: SecSDLC 2

Executive Summary Information Systems and Technology (IS&T) has become an essential part of everyday life. Today people perform daily activities and transactions through Internet, ATM, and mobile devices for multi-purposes. Because people use software bearing in mind that it is reliable and can be trust upon and the operation they perform is secured. It is a very important to continue to keep these people feel safe and secured when using IS&T and to prevent any exploitable security holes. Now, security brings value to software in terms of peoples trust. The value provided by secure software is vital because many critical functions are entirely dependent on the software. That is why security in software development is a serious topic, which should be given proper attention during the entire SDLC, right from the beginning. In this White Paper, we would like to discuss a few following topics respectively: an introduction of software development life cycle, security in software development lifecycle, including the traditional waterfall model and the agile methodology. Then we will quickly talk about the different roles and responsibilities, and certifications in Information Security & Technology. Finally, we will conclude with the industry recommendations and best practices for software developers. I. Introduction History of term SDLC: Information Systems and Technology (IS&T) are used by many organizations to make themselves more efficient and run more smoothly. But to manage IS&T is not an easy task. If they are not managed properly, the organization is prone to losses of information. In the 1960s, information systems depended heavily on data processing and mathematical routines. These processes would take lots of time and were not very reliable. There were many mistakes when developing these large systems, and maintaining them was even more difficult. These lethargic processes affected the most important individuals, the end users. They were in need for more, better, and cheaper software and wanted it as fast as they could possibly White Paper: SecSDLC 3

get it. Then a Software Development Life Cycle (SDLC) was introduced and was defined as a methodology for the design and implementation of the information systems. With this methodology, organizations can feel secure knowing that the system they have in place will protect them from any negative situations while also increasing their rate of success with projects. Purpose: With the introduction of the Software Development Life Cycle, it has created a better structure and organization. Software development life cycle was used to identify stakeholders and requirements for implementation of Information Systems. Problems in 1960s: Before software development life cycles companies would hire individuals to write code. This was substantial at first because the programs were not complex and it was the only method that was available at the time. Coders would write code and test the result; afterwards, they would modify code to fix bugs. Not to mention the unprecedented rate of change in business and technology almost made it impossible for software team to determine user requirements and adapt to their changes. More importantly, security neglect has been one of the main factors of why the majority of software projects have failed. For a really long time, security has always been secondary priority in SDLC. Critical security flaws are often recognized before software deployment. And even more unfortunate flaws are recognized after the iteration has been released. Organizations need to incorporate security governance to SDLC methodology of waterfall and agile. This incorporation of security will efficiently reduce potential costs associated with the risk of after employment. An effective security governance regime in the SDLC requires careful security planning, risk assessments, cost benefits analysis, and remediation. Security planning is the most important aspect in security governance. The main objective is to plan ahead and plan well before the incidents occur. White Paper: SecSDLC 4

II. Security in Software Development Life Cycle Traditional Waterfall SDLC Today we will focus on the traditional waterfall software development life cycle with an integration of security to improve the complete outcome of a software development lifecycle. A regular life cycle can consist of seven or more phases. These phases may increase or be broken down when implementing security in the life cycle. There are key drivers to integrating security into the Software Development Life Cycle: Security can decrease the high cost of fixing vulnerabilities. If the vulnerabilities are identified after deployment the cost is higher to resolve the issue. Therefore identifying the vulnerabilities before deployment can be less expensive for the business at large. The consequence a business may face if the system is compromised because of security. A business may lose customer if the system is compromised and their users personal data could be stolen. After a system is deployed and security was not an integrating factor, the business may have to hire a third party vendor to secure the software because the business did not hire skill software designer that were security conscious at the beginning. The outsourcing can become expensive. The lack of security will not have the full view of access required (e.g. internet). The company will lack the resources for the increasing demand of workers and customer to their network. Last but not least as the government increase security requirement and guidelines. It becomes difficult to ensure compliance when the companies do not plan for it. Each phase must be followed in sequence by the developer or software designer. The chart below shows how a traditional waterfall software development life cycle usually works. This cycle has five different stages. We will discus a seven stage traditional SDLC with an integration of security. White Paper: SecSDLC 5

Figure 1: Waterfall phases and Risk Profile How to plan a successful integration of security in a software development life cycle: During a SDLC planning for security will be essential. Security should be incorporated at the beginning of the software development life cycle. Through the use of risk management, the security requirements can be defined from business objectives. The business should ensure all the appropriate securities are implemented in the business requirements. These securities should be in the first phase of the design to ensure they also satisfy the business requirements. Business should ensure the development team and their managers are skilled in the art of developing software that is secure. The technology and processes should all meet the required security standard during implementation. Review of the deployed system should be ongoing to ensure appropriate levels of security are satisfied. Vulnerabilities should be evaluated using risk processes and then the vulnerabilities should be prioritized across software releases. White Paper: SecSDLC 6

Stages of traditional life Cycle: 1. Planning: The purpose of planning is to determine the scope of the project. This process may require studies to be undertaken before setting goals. During the planning the company performs feasible studies. The questions that are ask during these studies: They must ask the economical question. Should we build it? They must ask the operational question. If we build it, will they use it? They must ask the schedule question. Will it be ready in a timely manner? They must ask the technical question. Do they know how to build it? It is critical that security considerations be incorporated into the planning at the earliest stage of any project. 2. Defining Requirements: Defining requirements are the process, when the analyst receives feedback from stakeholders (e.g. end users). The feedback will allow for the creation of clear functions from the specific project goals. This phase allows a look from the end users view for the specific needs in the information systems. During this phase it is critical to consider a security plan to also integrate with the objective. The process will allow the business to ensure that the security policies will align with the objectives. These objectives would include: Creating requirements for access control list and the type of authentications and identity requirement, which are needed, and the different role bases. Business will identify and define the different levels of privacy for the data associated with the system and project. Business should create the criteria for abuse case. The criteria should outline the situation, which constitutes to a misuse of the system. 3. Designing System: Designing the system is when the features and the technical specification are described in detail. To assist with designing a system developers uses various (e.g. process diagram and use cases). Developers may also create prototypes to ensure all the requirements are met. In the designing White Paper: SecSDLC 7

stage there are logical and physical views. The logical view is an abstract view of how the system is suppose to work. The physical view is the actual physical components of the system. This is the second phase of integrating the security aspects into the software development life cycle. At this phase the requirement has been transformed into an actual architecture design and design decision. It allows the specific security controls to be implemented by the design team. Various security mechanisms are inserted at this point such as communication protocols. Security testing scenarios will be designed during this phase for identifying abuse cases that were developed during the planning phase. 4. Implementation: Implementation is to put into action for testing of the information systems. It can be costly if the information systems do not meet all the required needs of the users. Therefore during designing phase of the information systems all requirements and specification must be clearly defined to have a successful implementation. During this third phase of building for security, the system should always be built with security in mind, and software team should ensure needed security technologies and processes are properly in place and ready for integrating and testing. 5. Integrate and Test: During the integration and testing phase, all components are integrated and tested for bugs. Many corporate underfund this phase of the software development life cycle. The actual line of codes should ensure the integrity of the system. The coders should be well trained and have various auditing tool at their use to ensure the security and integrity of their data during the integrating and testing phase of the software development life cycle. 6. Deployment: The deployment phase is when the customer has accepted the information system and using the system for its needed purpose. A company has various ways to commence a deployment of software they are: phase, pilot, direct, and parallel. Phase: Phase is the process where part of the software switch over in phases. With phasing company is able to go back to the original system. Phasing allow nature take it course. The setback with phasing is when the original may become old and inefficient. White Paper: SecSDLC 8

Pilot: Pilot is an executable model of the system with all the function. The pilot is great way of getting and verifying the requirements. Direct: Direct is the most dangerous one because a company cannot go back. Direct forces a company to commit to the switch over. Parallel: Parallel is when a company is running the original system and the new at the same time. Parallel give the company a chance to go back if the new system fails. The setbacks with parallel are it s expensive to run two systems. The future for the administrators of the original is unknown. 7. Maintenance: During the maintenance phase of the software development life cycle is when future maintenance is completed on the information systems. The maintenance consist of three different types of maintenance they are corrective, adaptive, and perfective. Corrective maintenance is when the bugs fixed. Adaptive maintenance is the when the system need new coding compatibility issues. Perfective maintenance is when the company tries to improve the software. During the final stage of deployment of the system, maintenance is the most important part of the lifecycle because security threats are constantly evolving and been vigilant is the most important factor. Constant monitoring and various intrusion prevention systems are essential for the integrity of the system and the data, which is processed on the system. The maintenance team should continuously run penetration test and review logs and reports. Advantages and Disadvantage: The advantages with a traditional waterfall software development life cycle with the integration of security are the project is well defined with detail steps to ensure the integrity of the system and the data. There are standard development and designs. Project will be able to adjust to a change in the staff. The time is controlled and there is greater ability to monitor large projects. The disadvantages of traditional software development are there is an increase of time needed for the project. The system must be clearly defined at the beginning because the project is very difficult to make changes. Early errors can cause the project to overrun due to rework on early stages. There is little interaction with the end-users. Per Russell Kay of Computer World White Paper: SecSDLC 9

Another problem is that the waterfall model assumes that the only role for users is in specifying requirements, and that all requirements can be specified in advance. Unfortunately, requirements grow and change throughout the process and beyond, calling for considerable feedback and iterative consultation. Thus many other SDLC models have been developed. Most developers recommend using more than one methodology for a success implementation of an information system. Therefore project that is forever changing use a methodology called agile software development life cycle. Agile Methodology SLDC Security in SDLC does more than just to make end users feel safe and secured when using the software. Security in Agile methodology is to prevent the exploitable security holes as early as possible and to cut down the maintenance cost later after the system had been deployed. This is a critical aspect of agile methodology. Software teams can feel safer when introduce frequently new releases because at each small releases security governance should had been implemented. And, the security governance integrated into the agile is no different than the waterfall model, except it is integrated during every early small iteration time-box releases. Software engineers can implement agile in many different ways. But, iterations are the heartbeat of agile methodology. As mentioned, waterfall failed because of its inflexibility and subject to change. Organizations, who exercised waterfall model, were not inclined to change, to adapt with the evolving stakeholders requirements. In contrast, agile does a great job on focusing on iterations, frequent consultation with the customer, small and frequent releases, and rigorously tested code that directly responded to the stakeholders feedbacks. To further distinguish agile from other software development methodologies, it is important to recognize these two elements that shaped agility dimensions: response extensiveness and response efficiency. Response extensiveness relates to the scope, range, extent, and variety of software team responses. On the other hand, response efficiency relates to resources such as time, cost, and effort associated with software team responses. We had mentioned the differences between agile and waterfall model. But, what is agile methodology really? Where does it come from? And why do we use it? White Paper: SecSDLC 10

Figure 2: Agile Methodology with iteration time-box releases What is Agile? Agile methodology is the conceptual framework to introduce the more effective and efficient ways and best practices to develop software. For decades, the traditional waterfall software development life cycle had been the primary model for software development. However, the traditional waterfall has numerous problems such as maintenance cost, inflexibility, and subject to change. These causes are to slow down the industry s potential growth. Then, agile software development life cycle was introduced largely to address the weaknesses of the planed-based method such as the traditional waterfall software development. Where did agile come? Agile philosophy came from the different ideas of the 17 software engineers, who gathered together in 2001 to write the agile manifesto included with the 12 agile guideline principles, which was today widely known and used in the industry. Here are 12 agile guideline principles we shall follow: 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. White Paper: SecSDLC 11

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 4. Business people and developers must work together daily throughout the project. 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. 7. Working software is the primary measure of progress. 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 9. Continuous attention to technical excellence and good design enhances agility. 10. Simplicity--the art of maximizing the amount of work not done--is essential. 11. The best architectures, requirements, and designs emerge from self-organizing teams. 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Agile methodology was a cooperative common on interests formed by the 17 individual contributions. While these engineers had different point of views in software developments, they possessed greatly magnifying similar goal of improving software development. The two wellknown methods that was used by different individuals at the time and now formally formed into agile framework were Extreme programming (XP) and Scrum. The managerial aspect of software development is the major difference between the two methodologies. EP focuses on hard coding or development process itself by using such technique, pair programming, two programmers sitting at the same desk and coding on the same screen while scrum focuses both management aspects and development processes. Why do we use agile? Furthermore, agile software development life cycle is more than just a set of standard rules, but agile is a philosophy. Agile philosophy was introduced to improve the traditional waterfall software development life cycle and to transform entire software industry as the whole. What make Agile different from the traditional waterfall SDLC are the rapid iterations of small and White Paper: SecSDLC 12

frequent releases to meet the evolving requirements. Agile focuses on direct user involvements during the development process, which explain the evolving requirements. Small and frequent iteration releases ensure security had been taken placed as early; hence to reduce the potential maintenance cost afterward. SecSDLC Certifications and Credibility: Security in SDLC requires a team. Like a software development teams, security team has different roles and responsibilities. Because software security has always been changing, it is important to keep track of these updates and reorganizations for those who keep up-to-date to enhance security policy and guideline to keep safe systems in place and to prevent the security threats such as polymorphic threat a threat that changes its apparent shape overtime, to become a new threat not detectable by techniques looking for a preconfigured signature; or man-in-themiddle threat- which seems to be the most difficult threat to recognize because it performs its attacks behind both end side objects of the attack. There are so many other new threats that security professionals need to keep up with such as the infamous Flame virus or the DNSChanger that shake the entire news world of internet. Imagine that the good guys have to discover and remedy ALL of the exploitable security holes why all the bad guys have to do is to discover ONE and exploit it. This is surely not an easy job for the security professionals. Roles and Responsibilities: A security team of key leadership positions within Information Security includes Chief Information Security Officer (definers), Security Manager, and Security Technician (administers). Chief Information Security Officer (CISO) may or may be not be included as top-level executives. CISO manages and directs an organization s computer information systems security program, implements information security policies, and supervises related Information Technology employees. The typical duties of the CISO are ensure compliance with local, state, White Paper: SecSDLC 13

and federal laws, implements controls to reduce fraud and other vulnerabilities, and train IT and non-it personnel on security and privacy issue. Security Manager oversees daily security operations for the business. The typically include developing and enforcing security policies to ensure a safe environment for employees and visitors. Security managers accomplish objectives identified by the CISO and issues identified by the technicians. They may also guard against property damage. Like CISOs, Security Managers are typically certified in CISSP, CISM, and/or GIAC. I will discuss these certifications, later. Security Technician tasked to configure firewalls, deploy Intrusion Detection and Prevention Systems (IDPSs) implement security software, diagnose and troubleshoot problems, and coordinate with systems and network administrators to ensure that an organization s security technology is properly implemented. Certifications: There are many certifications Information Technology professionals may obtain. The top certifications that we seek are Certified Information Systems Security Professional (CISSP), Certified Information Security Manager (CISM), and Global Information Assurance Certificate (GIAC). A CISSP is an information assurance professional who defines the architecture, design, management and/or controls that assure the security of business environments. The professionals credentials must meet at least two or more of the ten (ISO) 2 CISSP domains listed below: Access Control List (ACL) Telecommunications and Network Security Information Security Governance and Risk Management Software development Security Cryptography Security Architecture and Design White Paper: SecSDLC 14

Operations Security Business Continuity and Disaster Recovery Planning Legal, Regulations, Investigations and Compliance Physical (Environmental) Security This certification requires that an individual have at least five years minimum professional working experience. This exam price ranges from $250 to $600. A CISM must provide evidence of five years of professional experience in the field of information security, at least two years of education, or previous certification, and pass 200- question multiple-choice exam. The exam has critical sections: Information security governance (23 percent) Information risk management (22 percent) Information security program development (17 percent) Information security program management (24 percent) Information management and response (14 percent) These certifications range from $395 to $645. GIAC certifications require the applicant to complete a written practical assignment that tests the applicant s ability to apply skills and knowledge. These assignments are submitted to the SANS for review. Only when the practical assignment is complete can the candidate who wishes to take the exam online. The GIAC certificates are organized into six areas: Forensics Security Administration Management Audit Software Security Legal White Paper: SecSDLC 15

These certifications range from $500 to $700. III. Conclusion In SDLC, both plan-based waterfall and agile methodologies can be effective ways to develop software. Each method has strengths and weaknesses. An examination of project interdependencies and volatility allows managers to determine the best type of methodology for a given situation. Most importantly, security governance is critical in software development. While using either methodologies to develop the software, it is a very important to plan and implement a security governance to prevent any exploitable security holes. Because software security brings value to software in terms of peoples trust, the value provided by secure software is vital because many critical functions are entirely dependent on the software. White Paper: SecSDLC 16

References Barlow, Jordan B.Keith, Mark JeffreyWilson, David W.Schuetzler, Ryan M.Lowry, Paul BenjaminVance, AnthonyGiboney, Justin Scott. "Overview And Guidance On Agile Development In Large Organizations." Communications Of AIS 2011.29 (2011): 25-44. Computer Source. Web. 11 July 2012. Banerjee, C., and S. K. Pandey. "Software Security Rules, SDLC Perspective." (2009): arxiv. Web. 11 July 2012. <http://arxiv.org.ezproxy.gsu.edu/abs/0911.0494>. Danahy, Jack. "The Phasing-In Of Security Governance In The SDLC." Network Security 2008.12 (2008): 15-17. Business Source Complete. Web. 12 July 2012. Dorsey, Paul. "Top 10 Reasons Why Systems Projects Fail." Top 10 Reasons Why Systems Projects Fail. Web. 25 May 2012. <http://www.dulcian.com/papers/ioug/2000/top_10_reasons_systems_projects_fail.htm>. Drewry, Tony. "UWE-CSM - IT System Development Lifecycles." UWE-CSM - IT System Development Lifecycles. N.p., n.d. Web. 3 July 2012. <http://www.cems.uwe.ac.uk/tdrewry/lifecycl.htm>. Hanny, Jonathan. "Building An Application Security Program." Information Security Journal: A Global Perspective 19.6 (2010): 336-342. Computer Source. Web. 14 July 2012. Jack, Danahy. "Security & SDLC: The Phasing-In Of Security Governance In The SDLC." Network Security 2008.(n.d.): 15-17. ScienceDirect. Web. 11 July 2012. <http://www.sciencedirect.com.ezproxy.gsu.edu/science/article/pii/s1353485808701429>. Kay, Russell. "QuickStudy: System Development Life Cycle." Computerworld. 14 May 2002. Web. 24 May 2012. <http://www.computerworld.com/s/article/71151/system_development_life_cycle>. Stephen de, Vries. "Testing: Software Testing For Security." Network Security 2007. (n.d.): 11-15. ScienceDirect. Web. 11 July 2012. <http://www.sciencedirect.com.ezproxy.gsu.edu/science/article/pii/s1353485807700272>. McLean, Ephraim R. "The Traditional System Development Life Cycle." CIS 4620. Georgia State University, Atlanta. 24 May 2012. Lecture. Waterfall Model. "SDLC." Waterfall Model. WordPress, 2 June 2012. Web. 3 July 2012. <http://www.waterfall-model.com/sdlc/>. "What Agile Teams Think Of Agile Principles." Communications Of The ACM 55.4 (2012): 71-76. Business Source Complete. Web. 11 July 2012. White Paper: SecSDLC 17