download : Secure Software Development Life Cycle Document
Secure Software Development Life Cycle
Secure software development life cycle describes phases of the software cycle and the order in which those phases are executed according to business requirements. In order to implement the applications that are required to provide secured processing, the following high level SSDLC model has been carefully adopted within software development team and exercise together with business management.
Security measurement is upmost important to the services provided by e-commerce industries. And so software development team takes serious security measurement of each development phases and integration into standard software development processes. It also helps developers and managers looking for information on existing software development life cycle (SDLC) processes that address security.
The SSDL represents a structured approach toward implementing and performing secure software development. The SSDL approach mirrors the benefits of modern rapid application development efforts. Such efforts engage the stakeholders early on, as well as throughout analysis, design, and development of each software build, which is created in an incremental fashion.
Infrastructure security, such as firewall, DMZ, IDS management, Backup/recoverability and availability plans shall be in place. The focus of the SSDL described is to address secure development processes. No matter how strong the firewall rule sets are or how diligent the infrastructure patching mechanism is, if Web application developers haven't followed secure coding practices, attackers can walk right into the systems through port 80.
The following attack patterns must be applied through the SSDL
1. Define security/software development roles and responsibilities.
2. Understand the security regulations the system has to abide by, as applicable.
3. Define a security policy if none exists.
4. Define documented security requirements and/or attack use cases.
5. Develop and execute test cases for adherence to umbrella security regulations, if applicable. Develop and execute test cases for the security requirements/attack use cases described throughout this article.
6. Define secure coding guidelines, and train software developers and testers on them.
7. Test for adherence to secure coding practices.
8. Participate in threat modeling walkthroughs, and prioritize security tests.
9. Understand and practice secure deployment practices.
10. Maintain a secure system by having a patch management process in place, including evaluating exploitability.
As expanding demand of business practices, the framework of adopted SSDLC model shall be enhanced and adjusted accordingly as long as each phases are executed properly.
Software Development
Software development team exercises the proven software development model framework such as Microsoft’s The Trustworthy Computing Security Development Lifecycle, and the methodology that can leverage robust online applications and services.
The following Microsoft’s technology, servers and applications are utilized by the development team, but not limited to explore different technologies and platforms that can provide the best business solutions.
1. Microsoft .Net framework 2.0 and AJAX library
2. Visual Studio Professional Edition 2005
3. Visual SourceSafe 2005
4. Microsoft Office 2003
5. Microsoft Project 2003
6. Microsoft Visio 2003
7. SQL Server 2000
8. SQL Server 2000 Reporting Services
Requirement Gathering
During the requirement gathering phase, all the business requirements must be gathered and finalized the project scope by project manager, business analyst and stake holders. It is also important to bring in, as earliest as possible, every stake holders who can influence the project scope. The development team shall only involve determining the functionalities that the system should provide, which describes functions the system should perform, business logic that processes data, what data is stored and used by the system, and how the user interface should work.
If the requirements are similar to previous projects or may be exactly the same but different client, the development team can provide instant judgment for project timeframe based on previous project experience, historical data, design and architecture.
Specify Security Needs
As part of Secure Software Development Life Cycle (SSDL) model, it is required to specify security needs for the development during or after business requirements gathering phase. During the specifying security needs, development team shall discuss with a security advisor, infrastructure manager or network administrator (“security buddy”) to consider how security will be integrated into the development process, identify key security objectives, and otherwise maximize software security while minimizing disruption to plans and schedules.
The security advisor assists the team by reviewing requirements, making recommendations, and ensuring that the existing infrastructure and resources to support the project development team. Every application developed by the development team must be compliant with PCI standard and include all the potential security elements in the project to avoid security-related surprise late in the process.
The security specification is geared toward ensuring successful implementation of secure software. It has six primary components:
1. Security guidelines, rules, and regulations
2. Security requirements: attack use cases
3. Architectural and design reviews/threat modeling
4. Secure coding guidelines
5. Black/gray/white box testing
6. Determining exploitability
[Reference to PCI Security Enhancement and Guideline for more detail]
Design & Prototyping
SSDLC design phase involves two major parts; designing interface and designing application architecture. Basically, interface design is a very effective way of understanding all the user interface behavior while designing application architecture provides an overview of high level object models to the development team.
Graphic design team and system analyst shall work together in order to produce an interface design of the application based on the requirements and project scope discussed during the requirement gathering phase.
Prototype model of the application can be produced by using graphic and interface designs. Prototyping is also very beneficial for getting the end-user approval about what the final system would look like. Prototyping shall contain mock-up designs of items such as application screens, database layouts, and system architectures. End users, designers, developers, database managers, and network administrator shall review and refine the prototyped designs in an iterative process until they agree on an acceptable design. Audit, security, and quality assurance personnel should be involved in the review and approval process. Prototyping can enhance the team’s ability to design, test, and establish controls.
In addition to interface design & prototyping stage, use case analysis shall be initiated during this phase. Use case analysis is a technique for developing system specifications and design by analyzing the system from the user's point of view.
The results of use case analysis are:
- The system requirements will describe the system according to how the user will use the system.
- Customers will easily understand the system requirements document, so they can help review it to find errors.
- Designers will add to the system only what the system needs to satisfy its requirements, so the system will be as simple as possible
After finishing use case analysis and prototyping, the next activity is to do a high level design. The application architecture design is produced from the results of requirement gathering phase. This involves various UML methodology activities including the preparation of high-level object models, sequence diagrams, collaboration diagram, and data models. The end goal is to come up with a software architecture that can break the entire system into well-defined subsystems. All the subsystems, their public interfaces, and any subsystem interactions and dependencies are discussed in detail. This is the guiding light for all further design and development of the project. Application architects and senior members of the development team will have to play a vital role during this stage and this is the phase in which their focus lies.
The output of design & prototyping phase should carefully be documented. Detailed documentation enhances the development team’s ability to develop the programs and modify them during implementation phase. The documentation also helps management and QA team ensure final programs are consistent with original goals and specifications.
The whole team shall create initial testing, conversion, implementation, and training plans during the design phase. Additionally, the team shall draft user, operator, and maintenance manuals.
Application Control Standards: Application control standards enhance the security, integrity, and reliability of automated systems by ensuring input, processed, and output information is authorized, accurate, complete, and secure. Controls are usually categorized as preventative, detective, or corrective. Preventative controls are designed to prevent unauthorized or invalid data entries. Detective controls help identify unauthorized or invalid entries. Corrective controls assist in recovering from unwanted occurrences.
The standard shall be in place to ensure end users, network administrators, auditors, and security personnel are appropriately involved during initial project phases.
Input Controls
Automated input controls help ensure users accurately input information, systems properly record input, and systems either reject, or accept and record, input errors for later review and correction. Examples of input controls include:
+ Check Digits – Check digits are numbers produced by mathematical calculations performed on input data such as account numbers. The calculation confirms the accuracy of input by verifying the calculated number against other data in the input data, typically the final digit.
+ Completeness Checks – Completeness checks confirm that blank fields are not input and that cumulative input matches control totals.
+ Duplication Checks – Duplication checks confirm that duplicate information is not input.
+ Limit Checks – Limit checks confirm that a value does not exceed predefined limits.
+ Range Checks – Range checks confirm that a value is within a predefined range of parameters.
+ Reasonableness Checks – Reasonableness checks confirm that a value meets predefined criteria.
+ Sequence Checks – Sequence checks confirm that a value is sequentially input or processed.
+ Validity Checks – Validity checks confirm that a value conforms to valid input criteria.
Processing Controls
Processing controls help ensure systems accurately process and record information and either reject, or process and record, errors for later review and correction. Processing includes merging files, modifying data, updating master files, and performing file maintenance. Examples of processing controls include:
+ Batch Controls – Batch controls verify processed run totals against input control totals. Batches are verified against various items such as total dollars, items, or documents processed.
+ Error Reporting – Error reports identify items or batches that include errors. Items or batches with errors are withheld from processing, posted to a suspense account until corrected, or processed and flagged for later correction.
+ Transaction Logs – Users verify logged transactions against source documents. Administrators use transaction logs to track errors, user actions, resource usage, and unauthorized access.
+ Run-to-Run Totals – Run-to-run totals compiled during input, processing, and output stages are verified against each other.
+ Sequence Checks – Sequence checks identify or reject missing or duplicate entries.
+ Interim Files – Operators revert to automatically created interim files to validate the accuracy, validity, and completeness of processed data.
+ Backup Files – Operators revert to automatically created master-file backups if transaction processing corrupts the master file.
Output Controls
Output controls help ensure systems securely maintain and properly distribute processed information. Examples of output controls include:
+ Batch Logs – Batch logs record batch totals. Recipients of distributed output verify the output against processed batch log totals.
+ Distribution Controls – Distribution controls help ensure output is only distributed to authorized individuals. Automated distribution lists and access restrictions on information stored electronically or spooled to printers are examples of distribution controls.
+ Destruction Controls – Destruction controls help ensure electronically distributed and stored information is destroyed appropriately by overwriting outdated information or demagnetizing (degaussing) disks and tapes.
Implementation & Integration
The development implementation phase involves converting design specifications into executable programs. Effective development standards are included that programmers and other project participants discuss design specifications before programming begins. The procedures help ensure programmers clearly understand program designs and functional requirements.
To avoid programmers using various techniques to develop computer programs, development standards must be in place to address the responsibilities of application and system programmers. While application programmers are responsible for developing and maintaining end-user applications, system programmers are responsible for developing and maintaining internal programs that link application programs, web sites to system software and background service processes.
Web sites and application programs developed by the team are mostly large transaction-oriented programs associated with financial institutions and have been developed using different components and break-down programming techniques. The team primarily practices the concept of “object-oriented programming”. It centers on the development of reusable program modules and classification of data types (numbers, letter, dollars, etc.) and data structures (records, files, tables, etc.). Linking pre-scripted module objects to predefined data-class object reduces development times and makes programs easier to modify.
The most fundamental components are
-Data Object component
-Data Access Layer component
-Business Layer component
-Module Layer component
-User Interface component
Break-down programming technique requires each individual programmer to write and review program modules or components. Completed components are integrated with other components and reviewed again, often by senior developers or system analyst, to ensure the results properly interact.
Development Standard: The applications and web sites always contain sensitive information of credit card data, client profile and financial transaction data. Because of the sensitive nature of business data, development standard shall prohibit a programmer’s access to data, programs, utilities, and systems outside their individual responsibilities. It also establishes standards requiring programmers to document completed programs and development test results thoroughly. Appropriate documentation enhances a programmer’s ability to correct programming error and keep track of modification to the each program modules.
The following two documents are suggested to be produced by each developer after they have implemented their modules.
Development test(Unit test)
Development test ensures the application that it has been integrated successfully into release version and produces high-quality, scalable result. The result of development test can also bring more confidence level to the Management and QA team that the quality of development codes has been tested by the developers.
Change log
The advantages of making change log are to control every modification make to the source codes. If developers are required to make changes to the existing code modules in order to release for next the production turn, QA team will have to retest the application through out the whole QA process cycle. So, the development team will have to consider what the potential impacts are by making changes to the existing code modules and provide the necessary test scenario to the QA team.
In financial-oriented software applications, unnecessary changing to decimal point value can impact the significant amount of company revenue. In order to prevent such unnecessary changes to the existing application, change log will keep records of every single modification made. In addition, change log will also keep track of the every built produced by development team and control the application version.
Coding Standard: The team is using Microsoft .NET framework 2.0, and so coding standards must be documented properly according to Microsoft proven patterns. The document should be distributed among the team and make sure that every team members understand the coding practice and follow the standard patterns. The standardized, yet flexible, coding standards will enhance significantly the development team’s ability to decrease coding defects and increase the security, reliability, and maintainability of application programs. Coding reviewers or examiners shall evaluate the team’s coding standards and related code review procedures. To avoid the hidden security holes in the source codes embedded by the programmers for them to access the applications in production environment, code reviewers also make sure that there are not hidden security holes in the source codes before application is released for production environment.
Security Control
Management shall always maintain an up-to-date inventory list of membership account profile for each applications and web sites in production environment and also statistic report that shows how often member user access to the system and what modules most likely be used. It will help management to hold the security control over each individual member roles and account management.
Version Control
Development version control systems, sometimes referred to as concurrent version systems, assist the development team in tracking different versions of source code during development. Every application system built shall be recorded with related change request form. The frequency of change request form will reflect to the number of application built in order to release to the production environment. The more frequent of the change request, the higher of the built frequency. Management shall look up the frequency of application built as it reflects to the development time, testing time and manpower.
Testing and Quality Assurance
The testing phase requires the team to complete various tests to ensure the accuracy of programmed code, the inclusion of expected functionality, and the interoperability of applications and other network components. Thorough testing is critical to ensuring systems meet the standard and end-user requirements.
Testing phases will be conducted by different teams into each level of development stages. The following diagram will demonstrate how the team conducts the each testing processes.
As preparation for test plan is coming down from top to bottom sequentially according to the software development life cycle, each testing phases shall go up from bottom to top and the quality of the product shall be certified by each team.
Basically, code review and unit test shall be conducted by the development team. System tests, Link testing, security testing and over all testing can be completed by the QA team. When QA team certified that the product is ready for the user acceptance test, then BA, PM and the client shall carry out the UAT. If UAT is completed, and then the client must sign off the approval and so the product can be considered to release into production environment.
The following test phases shall be executed by each appropriate team members.
Testing performs by Client Business Analyst, Project Manager
+Acceptance Testing – End users perform acceptance tests to assess the overall functionality and interoperability of an application.
Testing performs by QA Team
+End-to-End Testing – QA Team performs end-to-end tests to assess the interoperability of an application and other system components such as databases, hardware, software, or communication devices.
+Functional Testing – QA Team performs functional tests to assess the operability of a program against predefined requirements. Functional tests include black box tests, which assess the operational functionality of a feature against predefined expectations, or white box tests, which assess the functionality of a feature’s code.
+Integration Testing – QA Team performs integration tests to assess the interfaces of integrated software components.
+Parallel Testing – QA Team performs parallel tests to compare the output of a new application against a similar, often the original, application.
+Regression Testing – QA Teams retest applications to assess functionality after programmers make code changes to previously tested applications.
+System Testing – QA Teams perform system tests to assess the functionality of an entire system.
Testing performs by Development Team
+Stress Testing – Development Team perform stress tests to assess the maximum limits of an application.
+String Testing – Development Team perform string tests to assess the functionality of related code modules.
+Unit Testing – Development Team perform unit tests to assess the functionality of small modules of code.
As part of secure software development life cycle, the following test scenarios must be carefully checked and tested for secure purpose.
1. Cross Site Scripting (XSS)
2. Injection Flaws
3. Malicious File Execution
4. Insecure Direct Object Reference
5. Cross Site Request Forgery
6. Information Leakage and Improper Error Handling
7. Broken Authentication and Session Management
8. Insecure Cryptographic Storage
9. Insecure Communications
10. Failure to Restrict URL Access
[Reference to the Software Test Case Document for more detail]
Deployment
The deployment phase involves installing approved applications into production environments. Primary tasks include announcing the deployment schedule, training end users, and installing the product. Additionally, the team shall input and verify data, configure and test system and security parameters, and conduct post-deployment reviews. Management should circulate deployment schedules to all affected parties and should notify users of any deployment responsibilities.
Deployment can be performed with the approval of release management. Release management aware of what changes need to be included in the product release, product release request form will be provided with the detail description of change request.
Every product release or update in the production environment, the team must strongly exercise to have backup copy of existing system before new system actually replace it. After a system or an application is deployed in production environment, pre-existing data is manually input or electronically integrated to a new system. Verifying the accuracy of the input data and security configurations is a critical part of the implementation process. It can often run a new system in parallel with an old system until they verify the accuracy and reliability of the new system. Each team should document any programming, procedural, or configuration changes made during the verification process.
Maintenance
The maintenance phase involves making changes to hardware, software, and documentation to support its operational effectiveness. It includes making changes to improve a system’s performance, correct problems, enhance security, or address user requirements. To ensure modifications do not disrupt operations or degrade a system’s performance or security, the team shall establish appropriate change management standards and procedures.
Change management requires establishing baseline versions of products, services, and procedures and ensuring all changes are approved, documented, and disseminated.
Emergency changes may address an issue that would normally be considered routine, however, because of security concerns or processing problems, the changes must be made quickly. Emergency change controls should include the same procedures as routine change controls. Management shall establish abbreviated request, evaluation, and approval procedures to ensure they can implement changes quickly. Detailed evaluations and documentation of emergency changes should be completed as soon as possible after changes are implemented. Management should test routine and, whenever possible, emergency changes prior to implementation and quickly notify affected parties of all changes. If management is unable to thoroughly test emergency modifications before installation, it is critical that deployment team appropriately backup files and programs and have established back-out procedures in place.
Without having appropriate change request form, the development team shall not make any modification to the existing applications.
Maintenance Models
The quick fix model is an ad-hoc approach. Its goal is to identify the problem and then fix it as quickly as possible. Due to time constraints, the model does not pay attention to the long-term affects of the fixes. The advantage of this model is that it gets work done quickly with lower cost. For example, if a system is developed and maintained by only one person, then that person will know the system well enough to make changes in a short time without the need to manage detailed documentation.
The reuse oriented model assumes that existing program components could be reused. The steps for the reuse model are identifying the parts of the old system which have the potential for reuse, fully understanding the system parts, modifying the old system parts according to the new requirements, and integrating the modified parts into the new system.
Reuse Oriented Model
The iterative enhancement model considers that changes made to the system during the software lifetime make up an iterative process. This model was adapted from development to maintenance. The model has three stages. First, the system has to be analyzed. Next, proposed modifications are classified. Finally the changes are implemented. This model is not effective when the documentation of the system is not complete, as the model assumes that a full documentation of the system exists.
Iterative Enhancement Model
Addition to Software Development Life Cycle
Research & Innovation
In order to keep up with fast pace technology trend, the development team must always look into the new technologies, useful applications and tools, and then constantly research on what technologies and methods are adoptable for the growth of business.
Technical discussion and knowledge sharing among the team, and the result from technical research can speed up the development process and overcome the technical burden.
By bringing the innovated ideas into the development team can make smooth of process and enhancement to the existing system and application.
Code Analysis
Code analysis ensures the system that it has been written by following the standard development methodology and certain rules of coding style. If one developer is not available, another developer can simply take over the developing process as long as the codes have standard writing practice.
It is also easy to maintain the source codes, have version control and remove unnecessary files included into the project.
Without having proper in-depth code analysis, the application is also vulnerable to the developers who implement the system.
Code analysis procedure can keep track of application version that how many time system has been deployed and what changes has been made from previous release.
The following list should be carefully checked as part of standard secure coding guideline.
1. Authentication
2. Session Management
3. Access Control
4. Input Validation
5. Encoding
6. Data Protection
7. Using Services Securely
8. Error Handling
9. Logging and Intrusion Detection
10. Secure Configuration and Deployment
[Reference to the Technical Guideline for more detail]
Documentation
Software Documentation
The team should maintain detailed documentation for each application and application system in production. Thorough documentation enhances the team’s ability to understand functional, security, and control features and improves its ability to use and maintain the software. The documentation should contain detailed application descriptions, programming documentation, and operating instructions. Standards should be in place that identify the type and format of required documentation such as system narratives, flowcharts, and any special system coding, internal controls, or file layouts not identified within individual application documentation.
The development team must maintain documentation for developed programs and technical references.
The management team must consider access and change controls when assessing documentation activities. Change controls help ensure the team appropriately approve, test, and record software modifications. Access controls help ensure individuals only have access to sections of documentation directly related to their job functions and applications.
System documentation should include:
System Descriptions – System descriptions provide narrative explanations of operating environments and the interrelated input, processing, and output functions of integrated application systems.
System Documentation – System documentation includes system flowcharts and models that identify the source and type of input information, processing and control actions (automated and manual), and the nature and location of output information.
System File Layouts – System file layouts describe collections of related records generated by individual processing applications. For example, personnel may need system file layouts to describe interim files, such as sorted deposit transaction files, in order to further define master file processing requirements.
Application documentation should include:
Application Descriptions – Application descriptions provide narrative explanations of the purpose of an application and provide overviews of data input, processing, and output functions.
Layouts – Layouts represent the format of stored and displayed information such as database layouts, screen displays, and hardcopy information.
Program Documentation – Program documentation details specific data input, processing, and output instructions, and should include documentation on system security. Program listings/source code and related narrative comments are the most basic items in program documentation and consist of technical programming scripts and non-technical descriptions of the scripts. It is important that developers update the listings and comment documentation when they modify programs. Many software development tools are available that automatically create source listings and narrative descriptions.
Traditionally, designers and developers shall user flowcharts to present pictorial views of the sequencing of procedural programs. Flowcharts provide a practical way to illustrate complex programs and routines.
Programming techniques, such as object-oriented programming, have contributed to the use of dynamic flowcharting products. Maintaining detailed documentation of object-oriented code is particularly important because a primary benefit of the programming technique is the reuse of program objects.
Naming Conventions – Naming conventions are a critical part of program documentation. Software programs are comprised of many lines of code, usually arranged hierarchically into small groups of code (modules, subroutines, or components), that perform individual functions within an application. Programmers should name and document the modules and any related subroutines, databases, or programs that interact with an application. Standardized naming conventions allow programmers to link subroutines into a unified program efficiently and facilitate technicians’ and programmers’ ability to understand and modify programs.
Operator Instructions – The team should establish operator instructions regarding all processing applications. The guidance should explain how to perform particular jobs, including how operators should respond to system requests or interrupts. The documentation should only include information pertinent to the computer operator's function. Program documentation such as source listings, record layouts, and program flowcharts should not be accessible to an operator. Operator instructions should be thorough enough to permit an experienced operator who is unfamiliar with the application to run a program successfully without assistance.
End-User Instructions – Organizations should establish end-user instructions that describe how to use an application. Operation manuals, online help features, and system error messages are forms of instructions that assist individuals in using applications and responding to problems.
download : Secure Software Development Life Cycle Document
Secure Software Development Life Cycle
Secure software development life cycle describes phases of the software cycle and the order in which those phases are executed according to business requirements. In order to implement the applications that are required to provide secured processing, the following high level SSDLC model has been carefully adopted within software development team and exercise together with business management.
Security measurement is upmost important to the services provided by e-commerce industries. And so software development team takes serious security measurement of each development phases and integration into standard software development processes. It also helps developers and managers looking for information on existing software development life cycle (SDLC) processes that address security.
The SSDL represents a structured approach toward implementing and performing secure software development. The SSDL approach mirrors the benefits of modern rapid application development efforts. Such efforts engage the stakeholders early on, as well as throughout analysis, design, and development of each software build, which is created in an incremental fashion.
Infrastructure security, such as firewall, DMZ, IDS management, Backup/recoverability and availability plans shall be in place. The focus of the SSDL described is to address secure development processes. No matter how strong the firewall rule sets are or how diligent the infrastructure patching mechanism is, if Web application developers haven't followed secure coding practices, attackers can walk right into the systems through port 80.
The following attack patterns must be applied through the SSDL
1. Define security/software development roles and responsibilities.
2. Understand the security regulations the system has to abide by, as applicable.
3. Define a security policy if none exists.
4. Define documented security requirements and/or attack use cases.
5. Develop and execute test cases for adherence to umbrella security regulations, if applicable. Develop and execute test cases for the security requirements/attack use cases described throughout this article.
6. Define secure coding guidelines, and train software developers and testers on them.
7. Test for adherence to secure coding practices.
8. Participate in threat modeling walkthroughs, and prioritize security tests.
9. Understand and practice secure deployment practices.
10. Maintain a secure system by having a patch management process in place, including evaluating exploitability.
As expanding demand of business practices, the framework of adopted SSDLC model shall be enhanced and adjusted accordingly as long as each phases are executed properly.
Software Development
Software development team exercises the proven software development model framework such as Microsoft’s The Trustworthy Computing Security Development Lifecycle, and the methodology that can leverage robust online applications and services.
The following Microsoft’s technology, servers and applications are utilized by the development team, but not limited to explore different technologies and platforms that can provide the best business solutions.
1. Microsoft .Net framework 2.0 and AJAX library
2. Visual Studio Professional Edition 2005
3. Visual SourceSafe 2005
4. Microsoft Office 2003
5. Microsoft Project 2003
6. Microsoft Visio 2003
7. SQL Server 2000
8. SQL Server 2000 Reporting Services
Requirement Gathering
During the requirement gathering phase, all the business requirements must be gathered and finalized the project scope by project manager, business analyst and stake holders. It is also important to bring in, as earliest as possible, every stake holders who can influence the project scope. The development team shall only involve determining the functionalities that the system should provide, which describes functions the system should perform, business logic that processes data, what data is stored and used by the system, and how the user interface should work.
If the requirements are similar to previous projects or may be exactly the same but different client, the development team can provide instant judgment for project timeframe based on previous project experience, historical data, design and architecture.
Specify Security Needs
As part of Secure Software Development Life Cycle (SSDL) model, it is required to specify security needs for the development during or after business requirements gathering phase. During the specifying security needs, development team shall discuss with a security advisor, infrastructure manager or network administrator (“security buddy”) to consider how security will be integrated into the development process, identify key security objectives, and otherwise maximize software security while minimizing disruption to plans and schedules.
The security advisor assists the team by reviewing requirements, making recommendations, and ensuring that the existing infrastructure and resources to support the project development team. Every application developed by the development team must be compliant with PCI standard and include all the potential security elements in the project to avoid security-related surprise late in the process.
The security specification is geared toward ensuring successful implementation of secure software. It has six primary components:
1. Security guidelines, rules, and regulations
2. Security requirements: attack use cases
3. Architectural and design reviews/threat modeling
4. Secure coding guidelines
5. Black/gray/white box testing
6. Determining exploitability
[Reference to PCI Security Enhancement and Guideline for more detail]
Design & Prototyping
SSDLC design phase involves two major parts; designing interface and designing application architecture. Basically, interface design is a very effective way of understanding all the user interface behavior while designing application architecture provides an overview of high level object models to the development team.
Graphic design team and system analyst shall work together in order to produce an interface design of the application based on the requirements and project scope discussed during the requirement gathering phase.
Prototype model of the application can be produced by using graphic and interface designs. Prototyping is also very beneficial for getting the end-user approval about what the final system would look like. Prototyping shall contain mock-up designs of items such as application screens, database layouts, and system architectures. End users, designers, developers, database managers, and network administrator shall review and refine the prototyped designs in an iterative process until they agree on an acceptable design. Audit, security, and quality assurance personnel should be involved in the review and approval process. Prototyping can enhance the team’s ability to design, test, and establish controls.
In addition to interface design & prototyping stage, use case analysis shall be initiated during this phase. Use case analysis is a technique for developing system specifications and design by analyzing the system from the user's point of view.
The results of use case analysis are:
- The system requirements will describe the system according to how the user will use the system.
- Customers will easily understand the system requirements document, so they can help review it to find errors.
- Designers will add to the system only what the system needs to satisfy its requirements, so the system will be as simple as possible
After finishing use case analysis and prototyping, the next activity is to do a high level design. The application architecture design is produced from the results of requirement gathering phase. This involves various UML methodology activities including the preparation of high-level object models, sequence diagrams, collaboration diagram, and data models. The end goal is to come up with a software architecture that can break the entire system into well-defined subsystems. All the subsystems, their public interfaces, and any subsystem interactions and dependencies are discussed in detail. This is the guiding light for all further design and development of the project. Application architects and senior members of the development team will have to play a vital role during this stage and this is the phase in which their focus lies.
The output of design & prototyping phase should carefully be documented. Detailed documentation enhances the development team’s ability to develop the programs and modify them during implementation phase. The documentation also helps management and QA team ensure final programs are consistent with original goals and specifications.
The whole team shall create initial testing, conversion, implementation, and training plans during the design phase. Additionally, the team shall draft user, operator, and maintenance manuals.
Application Control Standards: Application control standards enhance the security, integrity, and reliability of automated systems by ensuring input, processed, and output information is authorized, accurate, complete, and secure. Controls are usually categorized as preventative, detective, or corrective. Preventative controls are designed to prevent unauthorized or invalid data entries. Detective controls help identify unauthorized or invalid entries. Corrective controls assist in recovering from unwanted occurrences.
The standard shall be in place to ensure end users, network administrators, auditors, and security personnel are appropriately involved during initial project phases.
Input Controls
Automated input controls help ensure users accurately input information, systems properly record input, and systems either reject, or accept and record, input errors for later review and correction. Examples of input controls include:
+ Check Digits – Check digits are numbers produced by mathematical calculations performed on input data such as account numbers. The calculation confirms the accuracy of input by verifying the calculated number against other data in the input data, typically the final digit.
+ Completeness Checks – Completeness checks confirm that blank fields are not input and that cumulative input matches control totals.
+ Duplication Checks – Duplication checks confirm that duplicate information is not input.
+ Limit Checks – Limit checks confirm that a value does not exceed predefined limits.
+ Range Checks – Range checks confirm that a value is within a predefined range of parameters.
+ Reasonableness Checks – Reasonableness checks confirm that a value meets predefined criteria.
+ Sequence Checks – Sequence checks confirm that a value is sequentially input or processed.
+ Validity Checks – Validity checks confirm that a value conforms to valid input criteria.
Processing Controls
Processing controls help ensure systems accurately process and record information and either reject, or process and record, errors for later review and correction. Processing includes merging files, modifying data, updating master files, and performing file maintenance. Examples of processing controls include:
+ Batch Controls – Batch controls verify processed run totals against input control totals. Batches are verified against various items such as total dollars, items, or documents processed.
+ Error Reporting – Error reports identify items or batches that include errors. Items or batches with errors are withheld from processing, posted to a suspense account until corrected, or processed and flagged for later correction.
+ Transaction Logs – Users verify logged transactions against source documents. Administrators use transaction logs to track errors, user actions, resource usage, and unauthorized access.
+ Run-to-Run Totals – Run-to-run totals compiled during input, processing, and output stages are verified against each other.
+ Sequence Checks – Sequence checks identify or reject missing or duplicate entries.
+ Interim Files – Operators revert to automatically created interim files to validate the accuracy, validity, and completeness of processed data.
+ Backup Files – Operators revert to automatically created master-file backups if transaction processing corrupts the master file.
Output Controls
Output controls help ensure systems securely maintain and properly distribute processed information. Examples of output controls include:
+ Batch Logs – Batch logs record batch totals. Recipients of distributed output verify the output against processed batch log totals.
+ Distribution Controls – Distribution controls help ensure output is only distributed to authorized individuals. Automated distribution lists and access restrictions on information stored electronically or spooled to printers are examples of distribution controls.
+ Destruction Controls – Destruction controls help ensure electronically distributed and stored information is destroyed appropriately by overwriting outdated information or demagnetizing (degaussing) disks and tapes.
Implementation & Integration
The development implementation phase involves converting design specifications into executable programs. Effective development standards are included that programmers and other project participants discuss design specifications before programming begins. The procedures help ensure programmers clearly understand program designs and functional requirements.
To avoid programmers using various techniques to develop computer programs, development standards must be in place to address the responsibilities of application and system programmers. While application programmers are responsible for developing and maintaining end-user applications, system programmers are responsible for developing and maintaining internal programs that link application programs, web sites to system software and background service processes.
Web sites and application programs developed by the team are mostly large transaction-oriented programs associated with financial institutions and have been developed using different components and break-down programming techniques. The team primarily practices the concept of “object-oriented programming”. It centers on the development of reusable program modules and classification of data types (numbers, letter, dollars, etc.) and data structures (records, files, tables, etc.). Linking pre-scripted module objects to predefined data-class object reduces development times and makes programs easier to modify.
The most fundamental components are
-Data Object component
-Data Access Layer component
-Business Layer component
-Module Layer component
-User Interface component
Break-down programming technique requires each individual programmer to write and review program modules or components. Completed components are integrated with other components and reviewed again, often by senior developers or system analyst, to ensure the results properly interact.
Development Standard: The applications and web sites always contain sensitive information of credit card data, client profile and financial transaction data. Because of the sensitive nature of business data, development standard shall prohibit a programmer’s access to data, programs, utilities, and systems outside their individual responsibilities. It also establishes standards requiring programmers to document completed programs and development test results thoroughly. Appropriate documentation enhances a programmer’s ability to correct programming error and keep track of modification to the each program modules.
The following two documents are suggested to be produced by each developer after they have implemented their modules.
Development test(Unit test)
Development test ensures the application that it has been integrated successfully into release version and produces high-quality, scalable result. The result of development test can also bring more confidence level to the Management and QA team that the quality of development codes has been tested by the developers.
Change log
The advantages of making change log are to control every modification make to the source codes. If developers are required to make changes to the existing code modules in order to release for next the production turn, QA team will have to retest the application through out the whole QA process cycle. So, the development team will have to consider what the potential impacts are by making changes to the existing code modules and provide the necessary test scenario to the QA team.
In financial-oriented software applications, unnecessary changing to decimal point value can impact the significant amount of company revenue. In order to prevent such unnecessary changes to the existing application, change log will keep records of every single modification made. In addition, change log will also keep track of the every built produced by development team and control the application version.
Coding Standard: The team is using Microsoft .NET framework 2.0, and so coding standards must be documented properly according to Microsoft proven patterns. The document should be distributed among the team and make sure that every team members understand the coding practice and follow the standard patterns. The standardized, yet flexible, coding standards will enhance significantly the development team’s ability to decrease coding defects and increase the security, reliability, and maintainability of application programs. Coding reviewers or examiners shall evaluate the team’s coding standards and related code review procedures. To avoid the hidden security holes in the source codes embedded by the programmers for them to access the applications in production environment, code reviewers also make sure that there are not hidden security holes in the source codes before application is released for production environment.
Security Control
Management shall always maintain an up-to-date inventory list of membership account profile for each applications and web sites in production environment and also statistic report that shows how often member user access to the system and what modules most likely be used. It will help management to hold the security control over each individual member roles and account management.
Version Control
Development version control systems, sometimes referred to as concurrent version systems, assist the development team in tracking different versions of source code during development. Every application system built shall be recorded with related change request form. The frequency of change request form will reflect to the number of application built in order to release to the production environment. The more frequent of the change request, the higher of the built frequency. Management shall look up the frequency of application built as it reflects to the development time, testing time and manpower.
Testing and Quality Assurance
The testing phase requires the team to complete various tests to ensure the accuracy of programmed code, the inclusion of expected functionality, and the interoperability of applications and other network components. Thorough testing is critical to ensuring systems meet the standard and end-user requirements.
Testing phases will be conducted by different teams into each level of development stages. The following diagram will demonstrate how the team conducts the each testing processes.
As preparation for test plan is coming down from top to bottom sequentially according to the software development life cycle, each testing phases shall go up from bottom to top and the quality of the product shall be certified by each team.
Basically, code review and unit test shall be conducted by the development team. System tests, Link testing, security testing and over all testing can be completed by the QA team. When QA team certified that the product is ready for the user acceptance test, then BA, PM and the client shall carry out the UAT. If UAT is completed, and then the client must sign off the approval and so the product can be considered to release into production environment.
The following test phases shall be executed by each appropriate team members.
Testing performs by Client Business Analyst, Project Manager
+Acceptance Testing – End users perform acceptance tests to assess the overall functionality and interoperability of an application.
Testing performs by QA Team
+End-to-End Testing – QA Team performs end-to-end tests to assess the interoperability of an application and other system components such as databases, hardware, software, or communication devices.
+Functional Testing – QA Team performs functional tests to assess the operability of a program against predefined requirements. Functional tests include black box tests, which assess the operational functionality of a feature against predefined expectations, or white box tests, which assess the functionality of a feature’s code.
+Integration Testing – QA Team performs integration tests to assess the interfaces of integrated software components.
+Parallel Testing – QA Team performs parallel tests to compare the output of a new application against a similar, often the original, application.
+Regression Testing – QA Teams retest applications to assess functionality after programmers make code changes to previously tested applications.
+System Testing – QA Teams perform system tests to assess the functionality of an entire system.
Testing performs by Development Team
+Stress Testing – Development Team perform stress tests to assess the maximum limits of an application.
+String Testing – Development Team perform string tests to assess the functionality of related code modules.
+Unit Testing – Development Team perform unit tests to assess the functionality of small modules of code.
As part of secure software development life cycle, the following test scenarios must be carefully checked and tested for secure purpose.
1. Cross Site Scripting (XSS)
2. Injection Flaws
3. Malicious File Execution
4. Insecure Direct Object Reference
5. Cross Site Request Forgery
6. Information Leakage and Improper Error Handling
7. Broken Authentication and Session Management
8. Insecure Cryptographic Storage
9. Insecure Communications
10. Failure to Restrict URL Access
[Reference to the Software Test Case Document for more detail]
Deployment
The deployment phase involves installing approved applications into production environments. Primary tasks include announcing the deployment schedule, training end users, and installing the product. Additionally, the team shall input and verify data, configure and test system and security parameters, and conduct post-deployment reviews. Management should circulate deployment schedules to all affected parties and should notify users of any deployment responsibilities.
Deployment can be performed with the approval of release management. Release management aware of what changes need to be included in the product release, product release request form will be provided with the detail description of change request.
Every product release or update in the production environment, the team must strongly exercise to have backup copy of existing system before new system actually replace it. After a system or an application is deployed in production environment, pre-existing data is manually input or electronically integrated to a new system. Verifying the accuracy of the input data and security configurations is a critical part of the implementation process. It can often run a new system in parallel with an old system until they verify the accuracy and reliability of the new system. Each team should document any programming, procedural, or configuration changes made during the verification process.
Maintenance
The maintenance phase involves making changes to hardware, software, and documentation to support its operational effectiveness. It includes making changes to improve a system’s performance, correct problems, enhance security, or address user requirements. To ensure modifications do not disrupt operations or degrade a system’s performance or security, the team shall establish appropriate change management standards and procedures.
Change management requires establishing baseline versions of products, services, and procedures and ensuring all changes are approved, documented, and disseminated.
Emergency changes may address an issue that would normally be considered routine, however, because of security concerns or processing problems, the changes must be made quickly. Emergency change controls should include the same procedures as routine change controls. Management shall establish abbreviated request, evaluation, and approval procedures to ensure they can implement changes quickly. Detailed evaluations and documentation of emergency changes should be completed as soon as possible after changes are implemented. Management should test routine and, whenever possible, emergency changes prior to implementation and quickly notify affected parties of all changes. If management is unable to thoroughly test emergency modifications before installation, it is critical that deployment team appropriately backup files and programs and have established back-out procedures in place.
Without having appropriate change request form, the development team shall not make any modification to the existing applications.
Maintenance Models
The quick fix model is an ad-hoc approach. Its goal is to identify the problem and then fix it as quickly as possible. Due to time constraints, the model does not pay attention to the long-term affects of the fixes. The advantage of this model is that it gets work done quickly with lower cost. For example, if a system is developed and maintained by only one person, then that person will know the system well enough to make changes in a short time without the need to manage detailed documentation.
The reuse oriented model assumes that existing program components could be reused. The steps for the reuse model are identifying the parts of the old system which have the potential for reuse, fully understanding the system parts, modifying the old system parts according to the new requirements, and integrating the modified parts into the new system.
Reuse Oriented Model
The iterative enhancement model considers that changes made to the system during the software lifetime make up an iterative process. This model was adapted from development to maintenance. The model has three stages. First, the system has to be analyzed. Next, proposed modifications are classified. Finally the changes are implemented. This model is not effective when the documentation of the system is not complete, as the model assumes that a full documentation of the system exists.
Iterative Enhancement Model
Addition to Software Development Life Cycle
Research & Innovation
In order to keep up with fast pace technology trend, the development team must always look into the new technologies, useful applications and tools, and then constantly research on what technologies and methods are adoptable for the growth of business.
Technical discussion and knowledge sharing among the team, and the result from technical research can speed up the development process and overcome the technical burden.
By bringing the innovated ideas into the development team can make smooth of process and enhancement to the existing system and application.
Code Analysis
Code analysis ensures the system that it has been written by following the standard development methodology and certain rules of coding style. If one developer is not available, another developer can simply take over the developing process as long as the codes have standard writing practice.
It is also easy to maintain the source codes, have version control and remove unnecessary files included into the project.
Without having proper in-depth code analysis, the application is also vulnerable to the developers who implement the system.
Code analysis procedure can keep track of application version that how many time system has been deployed and what changes has been made from previous release.
The following list should be carefully checked as part of standard secure coding guideline.
1. Authentication
2. Session Management
3. Access Control
4. Input Validation
5. Encoding
6. Data Protection
7. Using Services Securely
8. Error Handling
9. Logging and Intrusion Detection
10. Secure Configuration and Deployment
[Reference to the Technical Guideline for more detail]
Documentation
Software Documentation
The team should maintain detailed documentation for each application and application system in production. Thorough documentation enhances the team’s ability to understand functional, security, and control features and improves its ability to use and maintain the software. The documentation should contain detailed application descriptions, programming documentation, and operating instructions. Standards should be in place that identify the type and format of required documentation such as system narratives, flowcharts, and any special system coding, internal controls, or file layouts not identified within individual application documentation.
The development team must maintain documentation for developed programs and technical references.
The management team must consider access and change controls when assessing documentation activities. Change controls help ensure the team appropriately approve, test, and record software modifications. Access controls help ensure individuals only have access to sections of documentation directly related to their job functions and applications.
System documentation should include:
System Descriptions – System descriptions provide narrative explanations of operating environments and the interrelated input, processing, and output functions of integrated application systems.
System Documentation – System documentation includes system flowcharts and models that identify the source and type of input information, processing and control actions (automated and manual), and the nature and location of output information.
System File Layouts – System file layouts describe collections of related records generated by individual processing applications. For example, personnel may need system file layouts to describe interim files, such as sorted deposit transaction files, in order to further define master file processing requirements.
Application documentation should include:
Application Descriptions – Application descriptions provide narrative explanations of the purpose of an application and provide overviews of data input, processing, and output functions.
Layouts – Layouts represent the format of stored and displayed information such as database layouts, screen displays, and hardcopy information.
Program Documentation – Program documentation details specific data input, processing, and output instructions, and should include documentation on system security. Program listings/source code and related narrative comments are the most basic items in program documentation and consist of technical programming scripts and non-technical descriptions of the scripts. It is important that developers update the listings and comment documentation when they modify programs. Many software development tools are available that automatically create source listings and narrative descriptions.
Traditionally, designers and developers shall user flowcharts to present pictorial views of the sequencing of procedural programs. Flowcharts provide a practical way to illustrate complex programs and routines.
Programming techniques, such as object-oriented programming, have contributed to the use of dynamic flowcharting products. Maintaining detailed documentation of object-oriented code is particularly important because a primary benefit of the programming technique is the reuse of program objects.
Naming Conventions – Naming conventions are a critical part of program documentation. Software programs are comprised of many lines of code, usually arranged hierarchically into small groups of code (modules, subroutines, or components), that perform individual functions within an application. Programmers should name and document the modules and any related subroutines, databases, or programs that interact with an application. Standardized naming conventions allow programmers to link subroutines into a unified program efficiently and facilitate technicians’ and programmers’ ability to understand and modify programs.
Operator Instructions – The team should establish operator instructions regarding all processing applications. The guidance should explain how to perform particular jobs, including how operators should respond to system requests or interrupts. The documentation should only include information pertinent to the computer operator's function. Program documentation such as source listings, record layouts, and program flowcharts should not be accessible to an operator. Operator instructions should be thorough enough to permit an experienced operator who is unfamiliar with the application to run a program successfully without assistance.
End-User Instructions – Organizations should establish end-user instructions that describe how to use an application. Operation manuals, online help features, and system error messages are forms of instructions that assist individuals in using applications and responding to problems.
download : Secure Software Development Life Cycle Document
No comments:
Post a Comment